FedEx's CISO and its VP of data and AI, on a business that scans 18 million packages a day across 220 countries and has told the street that half its workflows will be agentic within two years. The most quotable thing in it is not about agents at all. Twenty years of buy-versus-build bias has inverted for them: AI maintains a bespoke system cheaply enough that the CISO is now building rather than waiting on a vendor roadmap, and his own red team and vulnerability management platform is in production, built in-house. Set that beside the restraint – the phrase used was that FedEx is being "extremely patient" about rolling agents out – and you get the useful shape of the talk: a public commitment to agentic workflows, held back deliberately until four foundations are in place. Clean data; identity and access management for agents, which they say is unsolved after thirty years of solving it for humans; observability split into a business half (every agent response must be explainable to a regulator or a customer) and a security half (an audit trail of every action an agent took); and governance. The model economics are worth stealing: a cheap open-weight model inline in the CI/CD pipeline where the developer needs an answer immediately, and the expensive frontier model run overnight in batch across the whole codebase.

"We, FedEx, has to have agency in everything we do. Doesn't matter it is human decision or agent decision."

Watch this session on demand

Three Cigna infrastructure leaders on how a highly regulated health services company got from "are you doing AI" to something countable. The sequence will be familiar: a control phase when GPT-3.5 arrived, then federation when the business wanted to move faster, then agentic last summer, which broke the pattern. The number that should make anyone check their own house is 200 – the count of separate AI initiatives running inside the infrastructure group alone, discovered only when they went and asked. What they did about it is the transferable part. Rather than govern the projects, they wrote a skills framework: treat standing an agent up the way you treat hiring a person, and make the owner of each service accountable for documenting what an agent must know to touch it. The API gateway owner owns the gateway's skills. That turned a threat into a job – the domain owners who were nervous a year ago now have a new function – and it produced the best small story of the session, below. Two economic observations worth carrying. The constraint on people was never really budget, it was that you cannot work them around the clock, and tokens removed it, so throughput now has to be capped deliberately rather than by exhaustion. And internal token spend should look like a bubble rather than a rising line: spend heavily to find the deterministic solution, then run the deterministic thing cheaply forever.

"We had 14 or 15 different individuals that all started to document their skills… it turned out every DBA probably did one thing better than another one, and nobody was 100%."

Watch this session on demand

Gluware's chief product officer – also a co-founder of ONUG – interviewing the man who runs IT infrastructure for Seminole Hard Rock, and it is the best reminder of the two days that most enterprise networks are nothing like the ones in the AI slides. The shape of the estate: 24/7, brick and mortar, cloud genuinely not an option because regulation requires a data centre at every property, a few hundred virtual machines per site – and twenty, thirty, forty thousand devices on the LAN. Every slot machine has a switch in its base, islands of six to twenty machines feeding an IDF. The floor is not fixed: machines move, layouts change, and the network has to follow, which is the quote below and the single best illustration anywhere of why static documentation fails. Beyond the gaming floor it is audiovisual, lighting, music, surveillance, video distribution, and four or five hundred points of sale. Twenty-one years of constrained budget and staff have left real technical debt, and the new properties – Las Vegas for 2027, Athens, one beside Citi Field for 2030 – arrive as greenfield on a compressed schedule because construction always runs late. Brownfield and greenfield at once, which is the actual condition of most of the room. The automation platform is the sponsor's own.

"What's a restaurant today, I kid you not, becomes 400 slot machines because we figure out that we'll get more money out of the slot machine than we'll get out of the buffet."

Watch this session on demand

NetBrain, drawing on what they see across hundreds of production networks, and the framework survives being separated from the product. The argument is that agentic network operations fail or succeed on the harness around the model rather than the model itself, and the equation they put on one slide is the thing to take: agent effectiveness equals intelligence plus harness. A large language model knows protocols, architectures and troubleshooting practice. It does not know what changed on your network thirty minutes ago, which path an application takes, why you designed it that way, or what your intended state is – and in operations, plausible is not the bar. Their harness is three parts: live network context, meaning the real network rather than a snapshot, an export or a twin; the engineer-grade tools your people already trust; and intent, which they usefully call "the things that must be true". Context says what is happening, tools gather the evidence, intent says whether the outcome is right. The four tests they put on a good harness are the part to hold a vendor to: it works at two hundred devices and at two hundred thousand, it works whichever model you choose, every conclusion traces to live evidence rather than assumption, and governance is built in rather than bolted on. The analogy that makes it land: the finest engineer on the planet, dropped on your network with no topology, no history and no sense of what normal looks like, giving you recommendations you would not act on.

"In network operations, it requires more than plausible answers. It requires evidence."

Watch this session on demand

Fortinet, and the back half is a product demonstration – a SOC agent investigating an incident, and inline inspection of traffic to an LLM – so take the capabilities as the company's own. Two things in the front half are worth having. The first is a simple map of where the attack surface moved. Last year's picture was users and devices, a network, and cloud services. The same picture with AI in it adds autonomous agents on the endpoint that no zero trust policy has ever heard of, and a new class of infrastructure in the data centre – models, MCP servers, the tooling around them – that existing security products were not built to inspect. Four areas, and most organisations are working on one of them. The second is the thing the speaker says actually drives his customer conversations, and it is not a technology: alongside AI adoption sits digital sovereignty, governments asking where citizen data lives and who can reach it, which is a board-level programme in its own right and gets far less airtime at a US event than it earns. The third pressure is the honest one and it is the quote below – the same team, the same budget and the same skills being asked to absorb all of it.

"How do I go as fast as my boss is asking me to go when I've got this huge operations challenge in terms of tool sprawl, lack of skills, and resources?"

Watch this session on demand

Opens as a set piece – nature's networks, John Gage's 1984 sentence, a Knicks inbound play – and then turns into the most rigorous engineering argument of the two days about what delegating a job to an agent actually requires. The worked example is a shipment that must cross the Pacific without a shock, and a storm that closes the planned route. The gap it exposes is one every operations team will recognise: an accurate picture of component health does not tell you the business consequence. Servers up, aircraft serviceable, plan dead. What a reasoning agent needs instead is a model of the enterprise – resources, dependencies, current state, commitments and permissions – where every answer carries its source, its freshness and its authority, so a plausible plan never assumes power it was not given. The failure modes are the part to write down. A request can succeed while the evidence requirement fails, which is the quote below. An answer can be correct and too late, and once the route opportunity has passed no successful response recovers it. A receiving system can accept a change while the acknowledgement is lost, which from the sender looks identical to failure, so a retry must name the same intended operation or you book the commitment twice. And when every aircraft's agent reacts to the same storm, they contend for the same services – "a dedicated line on this diagram does nothing if all the requests end up in a queue", so admission control and reserved capacity are design, not tuning. The closing instruction is four steps and worth following literally: map the network that carries the job, make each exchange say what it must deliver and by when, build the permissions in, and test the network before widening the autonomy.

"The request succeeded, but the evidence requirement did not."

Watch this session on demand

Google's GM for networking, and openly a vendor keynote – the second half is the Gemini platform and its Agent Gateway, Registry, Identity and Model Armor, and those claims are the company's own. The first half earns the room's attention anyway, for one argument and four problems. The argument: building an agent is an application problem, but governing one is an infrastructure problem, because of where the pieces of an agentic transaction actually meet. An agent calls a database, an external API, a model, an MCP tool, another agent – and those paths do not intersect in the model or in the database. They intersect in the network, which makes the network the only place a control can sit without depending on every developer choosing to implement it. The four problems named are a tidy checklist to take back: agent sprawl, where things spin up and down and sometimes exist for moments; identity and prompt injection; tokenomics, where agents in long loops delegating to each other burn millions of tokens in minutes on models more expensive than the task needed; and observability, where a multi-agent failure could be a reasoning error, an API timeout or a blocked network path, and ordinary network observability cannot tell you which. Worth noting that the same company's theatre talk and BlueCat's session both landed on SPIFFE for agent identity independently – three arrivals at one primitive is a signal about where this settles.

"They don't intersect in the model. They don't intersect in the database. They intersect in the network, which is the single logical place to see, secure, and control everything."

Watch this session on demand

Broadcom on where AI networking goes next, and the clearest numbers anyone put on stage for why the network is the binding constraint. A model no longer fits on a few cores or ten thousand; the useful unit is tens of thousands of accelerators and, within a few years, perhaps a million in one cluster – at which point job completion time for training and token efficiency for inference are both properties of the network, not the chip. The scaling model is three domains and worth adopting whoever you buy from: scale UP inside a rack, where accelerators reach into each other's memory over a single hop, about a hundred of them today; scale OUT between racks, where a hundred thousand is a real number; and scale ACROSS data centres hundreds of kilometres apart, which is what you do when you run out of power and floor rather than ambition. The bandwidth arithmetic is the part to quote at a budget meeting. An accelerator today has roughly 40 terabits of memory bandwidth, heading for 256. Assume the things talk to each other a quarter of the time and you need ten terabits of network per accelerator now, sixty or seventy within three years – against the 50-gigabit NIC in your data centre. The Ethernet argument is the company's own position, but the supporting facts are checkable: an OCP working group with 175 members and a published 1.0 spec, five hyperscalers running it in production, and an optical interconnect specification published in March to take scale-up past copper's reach. Note that AMD's session arrived at the same three-network picture independently.

"This is no longer a computing problem. This is a distributed computing problem."

Watch this session on demand

The opening conversation before the first keynote, and it sets out how the two days were built: design on the board day, build on the Wednesday, run on the Thursday – new operating models for infrastructure rather than new products. Two predictions worth recording because they are checkable. First, that a large refresh cycle is coming, because the equipment and the skills we have cannot survive another summer like the last one, and because products arriving in 2027 will have been written with AI and will not compete with what is installed on anything like equal terms. Second, that the compounding has barely started – models now improve models, and the same tools are writing the code. The observation that dates the industry most precisely is in the quote. Four years of this summit took the room from having AI pushed at it, to orchestrating agentic network operations, and the change is not in the vocabulary but in the motive: this is now work that has to be done to stay competitive rather than a bandwagon. And the structural point a networking audience has waited a long time to hear – infrastructure has always been the secondary conversation to whatever the technology was doing, and AI ended that, because nobody can make any of it work without it.

"We went from not really believing the hype to, 'Oh, crap, I've got to get this working.'"

Watch this session on demand

A former CISO, now running Zscaler's CXO-in-residence programme, on what frontier models do to an attack surface. It is a vendor session and the assessment service behind the numbers is theirs, but the numbers are the reason to read it. The timing argument first: in the PHP incident days before the summit, a frontier model found what human groups had not, and the working exploit existed a little over three hours later – less time than most organisations need to get a change form proposed, let alone approved. The conclusion he draws from months inside Project Glasswing is the line to take away, and it is in the quote: patching is not a race you can win, so the objective moves from preventing every breach to preventing a breach from becoming a catastrophe. The anonymised assessment he walked through makes it concrete. An organisation that believed it was well prepared had more than 6,600 assets exposed, some of them from a divestiture where the business had gone and the network connection had not. Its critical vulnerabilities were patched well – and the low-priority ones, which is what a model chains, in attack paths twenty or thirty steps long, were not. Forty exposed VPN appliances, which he calls the single most attacked thing on an external surface. The internal half is the sharper point for anyone counting: twenty years were spent getting least privilege right for users, and the weakest link has now moved to agents, with individual users seen running seventy-five or more.

"A patched system is just a new binary."

Watch this session on demand

Quantum Theater

Moderated by John Bucelli of IBM Research's quantum organisation, who has spent nine or ten years bringing quantum-safe cryptography to market, with Rajiv Sharma, chief security architect at Vanguard, and Nathan Shetterly from Accenture's data and AI practice. The session's premise is that AI-driven vulnerability discovery and the arrival of a cryptographically relevant quantum machine should be treated as one problem rather than two, and it largely earns that premise.

The observation that opened it is the one least likely to appear anywhere else. From the Accenture side, a career data professional:

"I used to fight to get access to data… there was just always a lot of inertia you had to overcome. What's interesting with AI is, something I've never seen in my career, all of a sudden almost all data in enterprises are being made available to AI, because the AI is not powerful without it… it is no longer politically feasible to say you can't access my data."

That is a governance collapse, not a technology change, and it created a new threat surface without anyone deciding to. Worth holding next to the AI Data Layer session, which came at the same problem from the classification side.

On the attack side, three properties were named — sophistication, speed and stealth — plus one that is genuinely new: agents colluding with each other to do things no single operator could. The illustration offered, and relayed here as reported on stage rather than verified: an intrusion that accomplished in about ten hours what a professional team would normally take two weeks to do, and which co-opted the victim's own internal AI system, leaving behind the agents' own written record of the vulnerabilities found. The detail that makes it land is the economics of it — the victim paying for the compute that was being used to find further holes in their own estate.

The mitigation list is short, practical, and the best part of the session. From Vanguard:

1. Re-triage your existing vulnerabilities, because the maths moved. "If risk is the impact times the likelihood, your likelihood number has changed. So the risk has gone up." Vulnerabilities you reasonably deprioritised are now escalated. Start by establishing which of them are actually exploitable and what an outside attacker can genuinely reach.
2. Design for containment using what zero trust already taught you — limit lateral movement at both the network and the identity layer, and keep blast radius small so a compromise in one area stays there.
3. Use the attackers' tools. Run AI-driven penetration testing against your own systems to find your weaknesses first.

With the perspective that keeps it from sounding like panic: we did fuzzing before, we did vulnerability prioritisation before. What has changed is time to exploit.

Why this gets funded, and the framing to use. The structural difficulty was named honestly — "the value of AI is very obvious… and the problem with security is it's always a 'well, if it happens' problem." The Accenture read on the way through is the most useful boardroom argument in the session:

"It kind of feels a little bit like a Y2K moment… where there's an ability to see what's going on in the market and say, 'Okay, we have 30 years of tech debt. We need to pay that back now.'"

And the realism attached to it: no board is going to accept slowing down the revenue side to do it. So the defence investment has to be coupled to the AI investment rather than traded against it — "we need to make this investment in the upside of AI. We also need to make this investment in the defense side, and we need to do that now."

The quantum half, with the one framing that actually changes behaviour. The basics were covered quickly — asymmetric cryptography rests on the hardness of factoring, Shor's algorithm undoes it, and that needs fault-tolerant machines at scale, which the industry consensus puts somewhere between the end of this decade and the middle of the next. Unlike Y2K, there is no date.

But the reason that does not license waiting:

"The data that's being transmitted today over the internet is going to be captured already… So the attack is happening right now. The exploit will happen sometime in the future."

Which converts into a scheduling argument you can take to a budget conversation: every month of delay is one more month of captured traffic the attacker will eventually be able to read. Some of today's data will not matter by then. Some of it will, and the job is to protect that while it still has value.

Where to start, and this is a clear, defensible answer. Inside your own environment you have identity and access management, network controls, application security, logging and monitoring. Out on the internet:

"Encryption is the only method of protection of your data. So we need to start focusing there first."

So the external attack surface first, the internal estate second. And the reason it is not a single swap: a connection to your public website is one protocol, but an organisation also has business-to-business connections to vendors and partners, file transfers, mobile devices, cloud provider links, and VPN connections for people working from home. Each has its own encryption arrangement, and each one has to become quantum safe separately.

How to question a vendor about it, which is more specific than anything else offered on this subject:

"It has to be more than just saying, 'Hey, vendor X, are you PQC compliant?' It's understanding, okay, what type of key exchange algorithms do you have? Do you have this concept of crypto agility? What if the algorithms fail? Then are you able to switch quickly?"

The moderator pushed that further, and it is the line to carry out of this session: quantum-safe migration is as much a procurement problem as a technical one. Get clarity from your suppliers — he explicitly included his own employer — on when their products migrate, how they implement agility, and how they will describe the cryptographic architecture inside their products through bill-of-materials. "I would encourage you to make that one of your fundamental walkaways from this discussion. That's something you can start today… and don't be shy about it."

The regulatory tailwind named: the June executive order requires providers and contractors to the US government to be quantum safe by the end of 2030, which is pushing vendor roadmaps whether or not you are a government supplier.

Crypto agility, stated concretely enough to act on. The last cryptographic transformation was roughly thirty years ago, before the internet — islands of automation rather than billions of connected devices — and the moderator's aside is worth noting: "which by the way, we haven't really completed." His own timeline: perhaps five to seven years to productive quantum machines, and seven to fifteen years to complete this transformation.

So the design instruction:

"As you build your architectures, find ways to externalize the cryptography or make it a configurable object within your software, and then you can be in that crypto-agile world."

Because this is explicitly not Y2K: "we need to do it once, but we need to be in a place where we can do this again." If AI advances far enough to threaten the new algorithms, you switch again. The underlying principle, from the cryptographer in the room:

"Cryptography is never a lock… Cryptography doesn't lock data forever. It's just a time to erode."

ML-KEM included. It erodes eventually too, and then the next one does.

The resource-estimate collapse, which is the most concrete reason the timelines keep moving. Three years ago the moderator's estimate of the qubit count needed to break modern cryptography was roughly two hundred times what he would put it at today, driven by algorithmic work combining quantum processors with GPU and CPU processing. He mentioned hearing at this conference that a further improvement was about a month away. His framing of what that means is careful and correct:

"I'm not saying it's going to shrink the goalposts or bring them closer, but it's putting more concrete around these timelines."

The defender-advantage argument, which is the strategic payload of the session. The PHP vulnerability of that week was used as the worked example: a small group understood the flaw, a fix was distributed in advance, responsible parties patched, and the organisations that were hit were the ones that could not patch in time. From that:

"You have an AI which potentially has a defender advantage, if we have these responsible disclosures that are done the way they're done. And as long as you're on the cutting edge, you have the board buy-in, you have the resources, you also have this superpower of agents that is able to actually help to reduce the timeline to actually get that fix in."

And the other half, which is the real warning:

"If you are not taking that seriously and it's like 'I'll patch it when I get to it,' or you don't have the resources, you are at a massive disadvantage, the likes of which we've never seen before."

The inequality this creates between well-resourced and under-resourced organisations is the thing to think about, and it connects directly to the small-organisation problem raised in the PQC migration session next door.

The governance recommendations, in the order they were given.

Stand up a Cryptography Center of Excellence. A group that governs the effort, keeps track of it, and does "the ankle biting to make sure that we are on a glide path to quantum safety." Its most important output is not technical: it determines who is responsible for making the change and who is ultimately accountable for the organisation being quantum safe.

Build a CBOM — a cryptographic bill of materials — but do not try to finish it. This is the most useful corrective in the session, because the inventory step is where these programmes stall:

"A CBOM by itself doesn't protect you. It's just a catalog of your information… To get a perfect 100% CBOM is going to take a lot of work and effort, and actually isn't protecting you. You get like 80%, 90% of the way there. Get enough so that you can start doing prioritization, and then start that transformation."

The moderator was blunter: the idea that an organisation of any size will go and find all of its cryptography as an initial task is "really kind of a misrepresentation and… no place to start." Prioritise critical data, long-lived data and systems of significance. And treat inventory as permanent rather than a phase — particularly in the cloud, where everything is ephemeral and "as soon as you have it, it's going to be out of date anyway."

Attach this to work that is already funded. Don't run it as a programme in a vacuum. Assign it alongside transformation efforts being driven for top-line business reasons — ask whether the re-platforming you are already paying for can also deliver the security outcome — and tag the crypto work onto an existing vulnerability management process. "Look for places where you can get some tailwinds, and that'll move the ball forward pretty quickly."

The Accenture advice, structured as past, present and future, and a good checklist to leave with:

• Past: deal with the technical debt nobody has been paying down for thirty years, with an actual plan.
• Present: refactor processes to be agile, because "we can't plan for a static future. It is going to be dynamic, and we don't know what the threats are yet."
• Future: as you hand more over to AI, keep humans in the loop specifically so that their skills do not atrophy — "because then you're setting yourself up for another type of risk."

The tension he named, which is the honest description of where most organisations now sit:

"If something's perfectly secure, then no one can use it. But if something is completely open, anyone can get to it, there's no friction at all, then it is most certainly a vulnerability."

The needle is being pushed hard toward accessibility. His suggestion for using that: make the value case and the defence case in the same boardroom conversation rather than in two, which he called "a clever trick of budgeting and resourcing that can be done in this moment."

On whether any of this works without regulation, both declined to wait for it. "I don't know that the government's coming to save us," with the caveat that legislation would be welcome. Vanguard's alternative is procedural and transferable: maintain a published set of security standards — a top ten — and require every new technology to meet them before it comes aboard. The pattern has repeated through mobile, cloud and now AI. "Do you need a regulation to force you to do it? No, I don't think you should." The constructive version is to let the data scientists experiment and make the conversation about how the experiment will meet the existing policy.

The audience question worth reporting, and the straight answer it got. Asked about a worst case in which a ten-thousand-noisy-qubit machine arrives in 2028, and how long an enterprise cryptographic inventory would then take given partner dependencies:

"If what you said arrives in '28, we will nowhere near be ready. I can't think of a single organization that I've encountered over the last nine years doing this that will be ready for it."

He immediately qualified it — the intent was not to cause panic — and landed on the instruction that generalises:

"You can't do everything, so do what matters."

And the best line of the session, offered almost as an afterthought, which is the thing to repeat to a nervous executive:

"The attacker needs a quantum computer. The defender doesn't. So we have a natural advantage already here."

Monday-morning advice, as asked for from the chair.

From Accenture, a case for optimism against the news cycle: the fact that thirty years of accumulated debt is being uncovered and fixed means the world ends up safer, and "we have tools at our disposal that we've never even imagined before. Let's put those to use."

From Vanguard, three things in order: stand up the cryptographic centre of excellence if you do not have one; find your exposed data and start fixing it; and note that the ecosystem has moved — the new algorithms are arriving in Java, Node, Python and OpenSSL, and third-party vendors are implementing them. The cost argument he closed on is the one to put in a business case:

"If we do it now, methodically, it's going to cost you less than if you try to wait two years from now."

The last word went to the human layer, and it is a useful one for anyone planning training rather than tooling: everyone in that room works with AI daily and finds it normal, but a great many people in their organisations do not — and if all data is suddenly available to AI and nobody flags something as material, non-public or confidential, "it's out there forever."

"Once we fix all of our tech debt, the humans are still going to be the weak link here, and that we have to train and account for that as well."

Back to the list of sessions

Watch this session on demand

Panel Stage

Four practitioners, moderated by a security leader with twenty-five years in the field and CISO time at a Fortune 150: a former CISO of MongoDB, Tradeweb and the New York Power Authority, now advising eight AI startups; a senior solution architect with twenty-four years building enterprise applications, currently automating services with agents; and an identity and access specialist with four decades in the business, latterly on agentic and generative AI lifecycle risk. The question the session set itself was narrow and useful: what can security borrow from site reliability engineering, now that the thing being secured changes its own behaviour at runtime?

The premise, stated early and worth arguing with:

"AI has moved far beyond generating content. I think we're past that now. It is now firmly embedded in our production networks. It's making decisions for us."

And the panel's standing objection to how most people talk about it:

"My current focus is to try to dispel the myth that agentic AI can be deterministic, because it's really a probabilistic solution."

The constructive version of that was to compartmentalise risk along the agentic pipeline, and to use code assistants to implement genuinely deterministic programs wherever a deterministic answer is available — which also cuts cost.

"Define by design" is the organising idea of the session, returned to in every answer by the identity panellist. Start from what the agent is allowed to do; define the controls that keep it inside that; and note that this is also a cost control, because once you know what the agent is supposed to do you know what volume and activity to expect, and you can detect drift or an agent stuck in a loop.

Three specific controls came out of it that are worth writing down:

• Rights per step, not per agent. "Allow the agent only to operate with a subset of their entire rights for that activity." The example: an agent doing a read on one customer record should not be holding an update right during that event.
• Deprovisioning as a first-class lifecycle event. Record what rights were provisioned when a service is built; when the service changes or retires, the deprovisioning has to actually fire. Easy inside your own organisation and genuinely hard where the agent was reaching external systems — "you need the ways to make sure that deprovisioning event occurred externally as well."
• Run the security pipeline on every change, not at release. A new connector, a new database, a new MCP server reachable by an existing agent all re-open the question. Attached to that, DLP policy bound to the agent so that a developer knows at build time which connectors and MCP servers that agent may use at all. And policy checks wherever data crosses a trust boundary.

The honest caveat from the former CISO: no single product does this. It is hybrid, it is partly build, and the old controls still matter — she made a point of browser controls — with humans remaining the largest variable in the system.

The most directly useful thing described all session was a product the moderator had seen while consulting, because it shows what "continuous validation" actually looks like in operation. Policy allowed an agent two weeks of data. The agent asked for a month, then two months. The tool refused each time — you're operating outside policy, try again — until the agent came back inside its bounds, at which point it was allowed through. Two things make that interesting rather than merely restrictive: the agent was corrected rather than killed, and the tool mapped the whole exchange to the NIST Cybersecurity Framework to show what the risk would have been without the control and what it was with it. That is control-effectiveness evidence generated as a by-product of enforcement, which is the thing every audit cycle currently produces by hand. The moderator's ambition for it:

"I'd love to just push a button and give people results, or democratize that to audit peers and partners."

On identity, the warning was about cleanup debt. The approach of "I'm just giving the agent the access the human has" drew an audible wince and the observation that it guarantees a cleanup project later — the same one the industry has run for human identities for thirty years. The preferred shape is an identity created at inception, in the developer's flow, possibly ephemeral, with policy guardrails on what it may do and connect to, provisioned as part of the approved design rather than as a later request to a security team. The panel's doubt, worth noting if you are evaluating: the existing identity governance and privileged access incumbents may not scale to this.

What runtime DevSecOps means, in the former CISO's words, and this is the line to carry into any deployment review:

"Runtime DevSecOps, it means security assumptions don't expire when we deploy. The olden days when the security team would be like, 'Okay, you're done. You can go live on Monday'… That's gone."

The runtime enforcement picture that goes with it: an engine analysing behaviour characteristics against the design parameters; stopping the agent from an activity it was not designed to do; and, as the heavier option, revoking the credential and requiring a human to respond before the agent runs again. The intermediate state nobody should overlook — demote the agent to read-only rather than choosing between full autonomy and off.

On audit, two things to plan for now. What an auditor will want on record: what the agent did, who assigned it, what data it had access to, with a full trail behind it. And a rule stated flatly:

"Not be trusting AI to manage itself in an auditable situation, because it's going to try and please its owner and say, 'I did everything right. Here's all the right stuff.'"

The corollary, relayed from an auditor in the room, is that the current fear in that profession is "a lot of AI slop generated by AI on behalf of AI."

The convergence argument, which was the moderator's own thesis and the most strategic idea in the session. SRE teams and security teams are looking at the same data plane — SRE pulling IT and reliability signals, security pulling security signals, from the same telemetry. She sees a real opportunity to stop running a separate SIEM and a separate ITOps environment and instead have everyone draw from one plane. From a financial services background she extended it further: AML and fraud sit on the same data source too, typically in two systems with different rule sets.

Alongside it, the position she argued against the room's consensus:

"I'm not a believer that human in the loop is scalable. I think it's human observing the factory floor of agents and figuring out when, hey, this agent isn't building that car right anymore."

And the detection question that follows: take it out of service so it is not building bad cars you have to recall, or fix it so it keeps building good ones. Her associated demand on security teams is that they have to build, not only buy — the application security team already knows code and can teach the rest of the team — because "gone are the days of non-automated controls."

The best artefact in the session is a definition of control drift. The moderator, by her own account, phoned a very senior SRE friend for it. It is short enough to adopt verbatim:

"An architectural change is acceptable when the security conditions still hold. Control drift is when the system can do something we did not authorize, or we can no longer demonstrate that the controls work. A new route to the same approved result may be fine. A new route that bypasses authorization, exposes protected data, or escapes monitoring is not."

"The architecture can change. Security boundaries should not change without an explicit decision."

That last sentence is the one to put in a policy document.

Break the glass, and the detail most designs get wrong. Without runtime enforcement you are left with the kill switch. Two pieces of guidance on it:

Pre-position the authority, not just the mechanism. Decide before any incident who is authorised to stop an agent, with that authority pre-approved and sanctioned, so that a SOC analyst at two in the morning can act and then convene the call. "You shouldn't be figuring this out calling five committees during an event." Some decisions will need a phone call, "but it can't take five hours."

The kill switch has to sit outside the agent. Agents have been observed ignoring an instruction to stop, so:

"The kill switch should not require the agent to listen. It should be outside of the agent box, cutting off access to whatever that agent is required to do, so the agent doesn't even know that it's suddenly cut off."

OWASP's guidance in this area was recommended twice, as was the material the ONUG working group has published on GitHub — risks, the control capabilities recommended against them, and the mapping to authentication and emerging agent standards.

And the framing for how to be in that conversation at all: be at the table when the business designs the workflow, "as a partner to the business, not an organization of no." With the sharp aside that we have all seen bad business processes automated — and now agentified.

The postmortem section produced the session's best piece of discipline. What to collect, because you frequently cannot recreate the failure in a lower environment: which model the agent was using, the prompt, the logs, the network flow, enough to replay a similar scenario and find where it breaks. Then interrogate the controls you believed you had — did authorisation fail, was a policy missing, did the agent bypass an approval step. And then:

"The response to when something goes wrong is, 'Oh, well, the model hallucinated.' That's not a good response to me. That's not a root cause analysis. That's just a statement of fact. So, don't be lazy."

The questions she replaces it with: who created the agent, what was its creation purpose, how critical is it, where did it break, how do we fix it, how do we not repeat it.

Three additions worth keeping:

• Blameless postmortems, argued from CISO experience. "AI was created by humankind. Your agents were created by a human being with a purpose in mind." Assign blame once and the next incident gets hidden instead of reported.
• Immutability. Make sure an agent cannot delete the record of what it did, and keep an immutable copy. Use models to review the collected data, but keep the people who have been running after-action reviews for years in the loop.
• Investigate with a different model from the one involved in the incident. A recent widely-discussed agent failure was cited on stage as the reason.

One source of drift that sits outside your control, and is worth raising in any vendor conversation: the model providers are evolving these capabilities fast, and being forced onto a new version that behaves differently — more aggressively, less aggressively, or with new failure modes — introduces risk you did not choose.

On baselining, the line that reframes the problem:

"An unchanged credential doesn't mean unchanged risk."

Because the agent can expand its own scope with exactly the credential it already holds. So a baseline has to capture the credentials, what the agent was meant to do, and how its scope has grown since — and how it gained the extra access. Vendors on the floor were doing behavioural analytics on agentic activity to spot out-of-bounds behaviour, which is a known pattern from the non-human identity world; the panel's security instinct was still prevention first, anomaly detection second.

And the clearest SRE transplant, which is where to start if you take one thing from this session. Give each agentic workflow a security SLO, and then:

• Define the objective itself — 99.9%, 99.8%, whatever the use case needs.
• Define the drift policy against it: if the agent departs from expected behaviour, can we detect it within ten minutes, fifteen, twenty?
• Assign an error budget. And decide in advance what happens when it is exhausted: shut the agent down, or demote it from autonomous to manual.

The closing practical note, from someone who had SREs embedded in her security team for years: "you don't make security changes without talking to your SREs first, because they have an understanding of how the application and the business and availability requirements are."

The moderator's summary was the right one to end on: as a security team, you do not have to invent this alone — there are adjacent disciplines with decades of practice, and SRE is the nearest of them.

Back to the list of sessions

Watch this session on demand

Quantum Theater

A two-person exchange rather than a panel: Kevin Chalker of Qrypt interviewing Zack Panteli, who chairs the post-quantum cryptography working group for Health-ISAC and the Health Sector Coordinating Council, and also sits on the UK National Cyber Security Centre's quantum working group. He flew in overnight and flew back the same evening. The value of the session is that almost everything in it is reported from inside a live, multi-organisation migration rather than projected forward from a standard.

The clock. The June executive order put a date on the transition — 30 December 2030 — where previously there was guidance and a shifting horizon. That date is what is generating the inbound interest, and the Y2K comparison came up immediately, in the form everyone in the quantum field now uses: "when is Q2K going to be?"

Who owns it, and why that answer does not hold. The initial answer is the CISO organisation, because that is the team that understands the risk. The important qualification followed straight after:

"The CISO organization take the initial burden, so the initial kind of budgetary, the initial financial risk, but I don't think that's sustainable."

The reason is scope. Crypto is everywhere, every system is affected, and the actual work — hardware upgrades, software upgrades, resourcing — lands on business unit technology teams. His conclusion is that the cost of a PQC programme has to be divided across the business, with the CISO driving it rather than funding it. The competing claim on those same teams was named without euphemism: "people are busy right now focusing on AI."

Why healthcare is the sharp case. The data does not expire. Everyone has a medical record, that record is sensitive, and "that data is not just going to disappear after a single transaction." Beyond patient records, the sector the working group represents includes pharmaceutical research — "loads of recipes for drug discovery, vaccine discovery" — and the example offered was the COVID vaccine, with every state actor targeting it at once. That is the harvest-now, decrypt-later threat in its most concrete form.

The maturity gap, stated plainly. Financial services, government and telco started this journey years ago, some in financial services up to seven. Healthcare did not, and is the sector whose data most needs it. On where the sector actually is today:

"Whether we're in that realm now of actually understanding what data we have, I don't think we're there yet. I think we're very much focused on where crypto lives, what crypto is vulnerable."

The deadline answer is the honest one, and worth hearing. Asked directly whether 2030 is achievable:

"I don't think organizations and a lot of organizations are in position right now to meet that timeline… Will we meet the timeline? Most likely not for the majority of organizations."

Organisations eighteen months into the work still have a long way to go. And the trend is the wrong way round:

"The priority for this should start increasing as you get closer to 2030. But unfortunately, we're kind of seeing the opposite right now, where the priority is going less as a result of other priorities."

His prescription, modelled on the UK NCSC's approach, is the opposite of completeness: set the migration path by high-risk use case. "Don't just tackle everything because you can't."

The AI connection, in both directions. He reported using AI-driven cryptanalysis as a lever to raise urgency internally, and relayed an account — checked live with someone in the audience who knew the detail — of a weakness in an algorithm that had gone undetected for more than thirty years being found by a model in about thirty minutes. Treat the specifics as second-hand; the point he drew from it is the durable one, that the cost of interrogating an algorithm has collapsed.

The other direction came from the audience and is immediately practical: AI is making crypto inventory tractable for the first time — pulling live data and certificate data into a central repository to run insights off — which is the step every PQC programme stalls on. The same contributor made the case for building a "factory-like" certificate-swapping capability, on the grounds that this is not Y2K: "rather than Y2K, where we all spent a bunch of money, then Y2K happened… this is going to become a regular thing."

The single best argument for funding the work, and it came as a closing aside:

"Approximately 10% of the findings from some of the organizations that have a full inventory is not even quantum-vulnerable algorithms. It's just point-blank algorithms that have been deprecated for 10, 15 years."

In other words, a crypto discovery exercise pays for itself in ordinary cryptographic debt before quantum enters the argument at all.

The technical blocker nobody has solved. This is the most important content in the session for anyone planning a programme. There are two migrations, not one:

• Key exchange is what everyone is doing. ML-KEM, the NIST key encapsulation mechanism, is in use and understood.
• Digital signatures are not. "I think not many people have tackled that problem right now. There's a lot of theory." The key sizes are not viable in most enterprises, the network impact in testing has been unacceptable to business units, and he named the IETF and the public certificate authorities as the parties who need to work out what this looks like. "That migration is not clear, and it's not clear for a lot of people."

If you are building a roadmap, that is the item to flag as unresolved rather than schedule.

Vendor claims deserve the scepticism he gave them. Named directly:

"A lot of vendors, you'll see Microsoft talk about it, Google, Cloudflare, and say, 'Okay, yes, we've enabled PQC.' We've enabled PQC for one aspect, for key exchange… So there's a bit of misinformation by vendors as well when they're saying we are PQC compliant. You're PQC compliant for a small portion."

The ask on vendors is attestation across all the other capabilities, not the one. The ask on yourself is not to stop there: a growing number of organisations are standing up their own PQC lab environments to test the new algorithms for network performance and interoperability in their own estate, and to try to break them. "Trust but verify."

The dependency list, which doubles as a planning checklist:

• No budget at all, in many organisations — before anything else, a dependency on finance and on a sponsor to get a programme started.
• Your infrastructure vendors' own timelines. The example given: Microsoft has said it will be PQC-ready by 2029, which means an organisation on Azure cannot be ready before 2029. The same holds for IaaS, software and cloud providers generally. This is worth working out for your own stack early, because it caps what any internal plan can promise.
• Internal budgetary constraints and the politics around them.
• The state of the technology itself — the digital signature problem above.

The framing to take away, which he returned to twice:

"This isn't a PQC program… PQC is a catalyst for cryptoagility."

With the consequence that matters: the next algorithm change will come, and the industry cannot answer it with another seven- or ten-year programme. Whatever foundations get built for this migration have to be reusable. "This can't be wasted investment."

On regulation, an unusual position argued from the inside. He asked the UK NCSC to regulate PQC migration earlier this year and was told no; he has asked the FDA, which has representation on the working group, and there are no immediate plans. His reasoning is simply that guidance does not move organisations and regulation does, and he was visibly surprised by how much of the room agreed. An audience contributor from Intel put the case more bluntly — nothing spurs action like a fine, a regulatory violation raises visibility up the executive chain, and regulation is "more like a curb than a line in the sand," with no middle ground — closing on the reason the deadline framing misleads people:

"With things like harvest-now, decrypt-later, you're already being violated, even if you don't know it."

On equipment that can never be upgraded, a question with a real answer. The example was a children's hospital whose CISO sits on the working group and whose surgical and clinical systems cannot be transitioned. The working group's position is to accept that:

"A lot of systems cannot upgrade and will not be able to be upgraded anytime soon."

So the work turns to mitigating controls around them, and alternatives to swapping the algorithm — quantum key distribution among them — chosen on risk rather than on compliance tidiness.

On the small-organisation problem, which is the reason the working group exists. The sector spans global pharmaceutical companies and funeral care. The children's hospital cited has a security team of fifty, no dedicated crypto team, no crypto budget and no hardware security modules — "nor should they really, because they're so small." The model being used is that large organisations carry the burden and publish what they learn, and the group is about to release the sector's first collective PQC milestones. One detail worth noting for any cross-industry group: healthcare could not get into the established conversations — "you kind of get closed groups at some point where you can't actually engage with financials or government" — and built its own.

On how to structure the programme, he had seen both extremes work: a seven-year strategy-plus-programme at large pharmaceutical companies, and 30/60/90 day agile cycles elsewhere. He declined to prefer one. The only non-negotiable:

"As long as the organizations know this isn't a quick fix… it's a multi-year program. And it's never going to end."

One budget observation worth passing to anyone forecasting spend: the cycle he is seeing has compressed from 24 months to 12, because the first year is testing and learning, and the standards, the market and the requirements are all still moving.

Back to the list of sessions

Watch this session on demand

Panel Stage

The last session of the day, moderated by one of the main-stage MCs, with three practitioners on the panel: the solutions engineering lead at Tata Communications, a VP of solutions architecture from the service-provider side, and a product manager for cloud networking at Google. Two of the three run networks for other people for a living, which is why the failure stories in this one are unusually specific.

It opened on the misconception, and all three gave the same answer.

"The biggest misconception is I don't need to do anything, or maybe I can throw bandwidth at it."

The useful part is the distinction they drew underneath it. There are two kinds of enterprise, and almost everyone in the room is the second kind:

• Organisations building or training models — genuinely a bandwidth problem, thicker pipes, dedicated connectivity.
• Organisations using AI — chatbots, copilots, agents, inference. "Long-lived bursty flows, which doesn't require humongous amount of bandwidth."

Confusing the two is how enterprises end up buying for a problem they do not have while missing the one they do. The third panellist added the response he used to get from networking practitioners, and the answer to it:

"Well, why are you talking to me about this? It's just an app. It's not my problem. We'll just put it onto the existing network, and it's going to be just fine… And I can tell you, it's coming your way."

His framing of what changes is the sentence most worth carrying out of the session, because it reassigns the job rather than the budget:

"In the same way that you enforce firewalls today, you're going to have to basically enforce governance for agentic applications."

What a hyperscaler had to unlearn. This was the densest technical stretch, offered as "it's been a trek," and it reads as a list of received networking wisdom that stopped being true:

• Oversubscription and statistical multiplexing. The whole premise — that workloads arrive, complete, and do not coincide — fails for training and for the back end of inference. Those need a dedicated lane. The economic argument for tolerating idle capacity was put in terms of cost per watt: "if you have to restart that job, that's much more expensive than having a dedicated network just sitting there idle."
• Load balancing on queue depth. Round-robin and busy/not-busy signals broke, because the queues looked empty while the accelerators could not take work — key-value caches deep in the accelerator were jammed with prefilled information. They had to go back and get different metrics out of the hardware (KV cache utilisation was named, with Nvidia credited as the partner in exposing it) and evolve the balancing algorithms onto those.
• Statelessness. There is pre-existing state in those GPUs and TPUs, and the network has to become aware of what prompts preceded what is already instantiated, rather than treating any accelerator as equivalent.
• General-purpose topology. Dedicated, bespoke topologies with accelerators connected back to back, and a different shape for training than for inference — one serialised, the other a full mesh.
• The node boundary. At thousands of interconnected accelerators, "it's not a matter of if, it's just a matter of how often they fail." The cluster is treated as a supercomputer and the network as an integral part of the compute node.

Two mechanisms came with that, for anyone tracking where this goes next: an optical spine aggregating the cluster network, so mirrors move programmatically in milliseconds to decommission a cluster and hand its job to the next one, and constant snapshots into storage for the all-fail case. On tail latency specifically — the thing that stalls a whole training job — the first move was getting packets into other GPUs' memory without routing through the CPU: GPU Direct, RDMA, RDMA over Ethernet.

What the service providers had already learned, before AI. Their account is that the hard problem predates all of this. A decade ago it was branches and data centres, users behind branches reaching applications in the data centre. Now the same shape carries far more elements — users everywhere, applications across multiple cloud providers and regions, training models scattered, neoclouds in the mix. The question they had been working on for a couple of years already was whether there is a single fabric that can privately and securely connect all of those and carry the governance, guardrails and observability with it. AI did not create that problem; it compounded it, "especially with governance and security."

The finding most likely to be immediately useful. Asked where things actually broke for enterprises that are AI users rather than AI builders, the answer was not connectivity and not bandwidth:

"Where we ran into challenges were the firewall and the load balancers. Because of bursty nature, can the firewall handle the number of sessions? Can the load balancer handle the number of sessions? That's where we had to scale up."

If you are inventorying what to check before you put an agentic workload into production, session capacity on the middleboxes is a concrete, cheap thing to go and measure.

On the WAN and where to put the GPUs, the guidance was data gravity: get the GPU clusters as close to the data as you can, ideally a cross-connect away. Where that is not feasible — distributed data sets, geographic constraints — use bespoke dedicated high-speed connectivity for training, deliberately independent of the business and branch network, because those workloads will otherwise overwhelm it.

The failure stories. Three versions of the same story, which is worth noting in itself.

The Tata case was a customer whose PoC produced great results and whose branch traffic was overwhelmed within days of going to production — rolled back, proper segmentation put in, elements of the network transformed, then redeployed. The lessons named were burstiness and the fact that the traffic is east-west rather than north-south.

Google's version was the same PoC-to-production failure with a different trigger:

"They don't consult the networking team at all. They don't even consult SecOps. They just go, 'It's working, it's magic, it's great.' And then they come in and say, 'Well, it's not secure.' But the thing that has been the red flag is always the wallet."

Large enough PoCs generate agents, the agents sprawl, and the token bill is what finally raises the alarm — "a totally non-regulated deployment of an agentic application where there's no limit to what it can do." He named it as the biggest mistake he sees, because it hits cost and scale at once.

Asked how many organisations are doing this surgically — talking to finance, security, networking and the application teams before they rebuild — all three said the same thing: not many. The qualifier is that it is improving, with large enterprises now going through network transformation deliberately, and that the ground is moving fast: "we have much more clarity today than we did two weeks ago."

What has changed with it is who you have to convince:

"In the past, us being in the networking industry dealt with mostly networking folks. But today, the buck doesn't stop there. You have to talk to networking teams, security teams, application teams, and treat the whole end-to-end infrastructure as one fabric."

The readiness check, in the form the panel actually gave it. The honest answer was that if the networking is built right, readiness is a validation exercise rather than a project — best routing path, segmentation and security, observability and troubleshooting in place, and firewall and load balancer sized for the sessions. The obstacle named was organisational: networking is not treated as one entity, you deal with a data centre persona, a branch persona and cloud teams, "and that's where the challenge lies."

The hyperscaler's additions to that list were sharper:

• Blast radius — "how broad is our risk profile when we put this in play?"
• Access to data — are you going to do the big transfers every time an agent asks, or cache them in storage, and do you have the storage infrastructure for that?
• A dedicated sliver of network optimised as a high-speed, low-latency interconnect for the agents themselves and for their path to storage, treated separately from everything else.
• And before any of it, a clear picture of where things will run, with the AI teams and SecOps on board.

The economics, which is where the panel was most directly useful to anyone who has to defend a budget. The Tata position was that network spend should not be a separate line item, is not at the scale of the compute spend anyway, and is a mission-critical enabler rather than an afterthought — the cost of getting it wrong being expensive GPUs sitting idle. The analogy offered: "it's like electricity, you don't feel it until you don't see it."

The service-provider read of the budget history is worth repeating because it explains the squeeze: thirty years ago the money was in building the networks, then it shifted to security, then to the cloud providers, and now it is AI — and the AI line goes unquestioned while networking and security get scrutinised. The response has been to stop buying beefier hardware against a five- or ten-year capacity plan and move to consumption-based, elastic infrastructure instead.

And Google's answer, which is the single best-formed idea in the session for making the case upward:

"We look at a measure of goodput… With AI, [throughput] means little, because you could have all the capacity in the world, but if you're not actually arriving at a result, you're starting and starting and restarting, and there's a cost to that. And we link it to power."

Goodput per watt. The argument being that bits per second does not justify network investment to anyone outside networking, whereas "you're consuming power, you're delaying GPUs, and you're not getting results" does.

On whether there is an end state, the answer was no, and not in a hand-waving way: the geometry of the inference back end is still being rationalised, the front end is still in flux. "I think we're starting a new wave, if anything."

Back to the list of sessions

Watch this session on demand

Panel Stage

Scott Fulton of BlueCat opened by asking the room who was a vendor and who was an end user, got mostly end users, and said he would make it thought leadership rather than a pitch. The substance came out of scenarios the ONUG working group built over the two or three months before the show, with several vendors and customers — so this is the working group's own material presented from a stage.

The scenario, which is worth walking through with your own stack. A user cannot reach a finance application. The first-level triage ticket is taken not by a person but by an incident-management agent in the ITSM platform — ServiceNow, PagerDuty, Remedy, whichever you run. That agent then fires roughly seven independent lookups off its own judgement at runtime:

• who the user is, from the directory
• which address they are on, from the DHCP lease
• whether the application is answering at all, via the load balancer
• whether the application services can reach each other
• whether there is a firewall in the way
• what changed anywhere in that ecosystem in the last 24 hours
• whether other tickets are complaining about the same application

and lands on a finding — one firewall node took a patch and its pair did not.

The useful part is the structure he draws out of it, which is the session title. Recognize what happened, and critically which agent did it and for what task. Act to fix the thing you found. Assure — was that one firewall, or is it 400 that need the same change?

The point to take back to your own architecture. Everything in the recognize phase that concerns the network is already observable: DNS resolution, what clients attempted to reach and when, flow records between source and destination, session logs, credentials, lease records, what kind of endpoint sits behind the user. What is not observable is the agent. Agent ID and task ID are, in his words, "red boxes today" — you can see the action and not the actor.

That is the same gap the Cisco keynote and the JPMorgan Chase fireside arrived at from different directions: identity, not the subnet, is the control point. Here it is stated as an operations problem rather than a security one. If you are spinning up agents and agent skills continuously, you need a registry behind them, and right now most shops do not have one.

Two standards to watch, and he named both. The first is the Agent Name Service (ANS), a Linux Foundation project started in the summer, which borrows the trusted-and-verified constructs of DNS to assert an agent's provenance, its capabilities and its identity — positioned as a companion to DNS rather than a replacement. He was honest that he does not know whether it will clear the process and get adopted. The second is SPIFFE, a URI-based way of identifying workloads that Google has been pushing hard; he could not recall the expansion from the stage, so for your notes it is the Secure Production Identity Framework For Everyone, and it lives at the CNCF.

If either lands, the agent stops being a blind spot and starts being something you can track across the estate the way DNS traffic is tracked now. That is the one thing from this session worth raising with whoever owns your ITSM platform, because the agents are arriving there first.

One line worth keeping for anyone arguing for change control:

"…most issues that occur on the network, most performance-related issues, have to do with some change that had some unintended consequence."

Back to the list of sessions

Watch this session on demand

Panel Stage

this was a single-presenter technical briefing by Shane Corbin, senior director of product management in AMD's networking organisation — not a panel. It is the most product-specific session in the top fifteen, and the summary below pulls out the architectural material that holds regardless of whose silicon you buy. Two caveats on the figures: the recording drops roughly two minutes early on, and the spoken numbers alternate between bits and bytes in places, so treat any specific throughput figure here as indicative and check it against published specifications.

The scale shift that frames everything else. Training has gone from comparatively small systems for transformer models to clusters "north of 100,000 GPUs to train frontier AI models." Two consequences for anyone running a fabric: bandwidth requirements rose, and the speed-refresh cycle inside scale-out fabrics is tightening — you are being asked to re-rate the fabric more often than the equipment-refresh habits of the last decade assumed. And it has to carry that bandwidth at close to continuous utilisation, which is a different design target from the bursty enterprise traffic most fabrics were sized for.

The most useful mental model in the session: a rack now contains three distinct networks.

1. Front-end — conventional services, handled on a DPU: software-defined networking, storage, NVMe initiator offload, encryption, load balancing, all accelerated in a programmable (P4) fast path.
2. Scale-up — the fabric inside the rack that lets GPUs address each other's memory directly, forming one coherent memory domain.
3. Scale-out — the fabric that connects racks to each other, via the AI NIC.

Keeping those three separate in your head makes most of the vendor conversations in this space legible, because products are usually addressing exactly one of them.

Why Ethernet won scale-up, and the reasoning is the transferable part. The scale-up fabric here is UALink over Ethernet — load/store operations between GPUs carried on Ethernet, so a GPU can reach another GPU's memory across the rack. The justification given:

"We picked Ethernet because we get a lot, I would say, for free with Ethernet."

Specifically: the flexibility to change switching vendors inside the rack; resilience extensions Ethernet already has; and the breadth of the surrounding ecosystem of tooling and skills. That last reason is the one worth weighing if you are evaluating proprietary interconnects — the people who can operate an Ethernet fabric already work for you.

The resilience mechanisms he named are concrete: link-level retry, so bit errors on scale-up links get replayed quickly, and negative acknowledgement to retransmit packets dropped in the fabric. Alongside that, enough path diversity that availability becomes a property of the topology rather than of any one component — a GPU's lanes distributed across a dozen switching ASICs.

The agentic finding, and the thing to take away from this session even if you never buy the hardware. Agentic workloads blow the KV cache past the bounds of high-bandwidth memory. The proposal is to let the cache spill to NVMe target storage and be retrieved back across the network at line rate through the DPU:

"If you think about the cache, because of agentic, is exceeding the bounds of HBM, the cache can effectively bleed over into NVMe target storage."

The claimed benefits are better use of GPU memory, less repeated GPU recompute because cache gets reused rather than regenerated, and higher agent density per server because the infrastructure functions move off the host.

Read that next to the hyperscaler material in the Re-Architecting the Enterprise Network for AI session, which reported having to rebuild load balancing around KV cache utilisation because accelerators looked idle while their caches were full. Two independent sessions arrived at the KV cache as the operative constraint on inference and agentic serving. That convergence is probably the most significant technical signal in the conference's networking track.

DPU offload, with real deployments cited. The pattern — push infrastructure functions off the host CPU and into a programmable device on the data path — is already in production at scale, and the examples are useful as evidence rather than as endorsement:

• A major cloud provider runs its SDN and security offload plus its entire storage initiator and TCP stack on the DPU, at line rate, with inline block encryption.
• Another hyperscaler uses it as the basis of an accelerated connection service for customer-hosted virtual network functions, with a claimed 20 to 30× improvement in connection setup rate over the previous implementation.
• A third uses it for virtual-machine and bare-metal-as-a-service, specifically so that SDN and security policy stay under the provider's control, independent of the tenant workload, while the tenant still gets bare-metal performance.

That last one is the architecturally interesting case for enterprises: it is a clean way to separate policy enforcement from the workload without taxing the workload.

Virtual pods, which is what makes rack-scale relevant below hyperscaler size. Not every workload needs seventy-odd GPUs, so the rack can be carved into isolated pods — three 24-GPU pods, say, or a 64-GPU training pod running alongside an 8-GPU inference pod. Two properties matter:

• Isolation at the fabric and memory level, so a tenant in one pod cannot address memory outside it.
• Fault containment — failures stay inside the affected pod and do not reach the other workloads.

If you are sizing AI infrastructure for a mixed internal population rather than one large training run, this is the capability to ask every vendor about.

The cost argument, and it is the strongest number in the session: multi-plane networking. Divide the bandwidth of the NIC and its ports across multiple independent plane fabrics — up to twelve on one card form factor, eight on another. What that buys you:

"You have an ability to eliminate tiers of networking to support the same size GPU cluster."

Plus redundant paths across planes, bandwidth that scales linearly, and better fault isolation. On their own modelling of a 32,000-GPU cluster, it came out 33% lower in switch capital cost, cables and optics for the same delivered bandwidth. And the adoption signal:

"When you're running large-scale AI training jobs, this is effectively considered a mandatory architecture by our largest customers."

If you are planning a cluster of any size, eliminating a networking tier is a larger lever than negotiating on port price.

The best vendor-neutral teaching in the session: why RoCE v2 is not sufficient for AI scale-out. Three named problems and their fixes, which between them explain what every "AI Ethernet" product on the floor is actually doing:

1. Intelligent packet spray. RoCE v2 forwards all packets in a queue pair down a single distinct path across the fabric. Spraying distributes them across every available path instead, which raises effective bandwidth and lets GPUs complete jobs faster — "more effective and optimal use of available bandwidth."
2. Path-aware congestion control. Congestion is inevitable at cluster scale. This monitors network conditions and adjusts the spray variance and load-balancing selection in response, routing around congestion and recovering faster when drops occur.
3. Out-of-order packet handling, which is the direct consequence of (1). RoCE v2 preserved ordering by pinning the path; once you spray, packets arrive out of order and something has to reassemble them. The implementation detail is neat and worth knowing: the memory address is carried in the packet header, so each packet is placed correctly in GPU memory without the GPU having to redo that work.

He also noted that the two major hyperscaler-specific variants — one developed with OpenAI, Microsoft and Oracle, the other with Meta — share all three of those traits and differ mainly in how they detect trouble: one uses active probing of the fabric, the other uses timeout-based path checks to locate where drops are occurring. Some implementations additionally use source routing from the NIC to steer traffic through the fabric. The standards track pulling this together is UEC, the Ultra Ethernet Consortium.

Performance claims attached, and worth labelling as his: around 25% better performance from one of those protocols, and up to 13% faster AI job completion from the additional per-GPU scale-out bandwidth — the latter explicitly from simulation and model testing rather than production measurement.

Confidential computing got more attention than expected, and it is relevant to anyone in a regulated industry considering shared AI infrastructure: secure boot, device attestation, virtualisation, and AES encryption enabled at wire rate within the scale-up fabric — not just at the rack boundary.

Three operational details worth noting:

• Liquid cooling is assumed, not optional. 85% of the rack's heat removed through liquid. If your facility is air-cooled, that is the constraint to resolve before anything else on this list matters.
• The rack design was contributed to OCP as a reference design, supporting the open protocols, with a SONiC-based network operating system offered as an option on the scale-up switch trays. Open-ecosystem positioning is now the default posture in this part of the market, which is useful leverage in a negotiation.
• Single-system manageability is the stated route to time-to-production — initialisation, pod provisioning, topology discovery, monitoring and alerting for the whole rack through one control point. The claim is that this, rather than raw performance, is what determines how quickly a deployment reaches production.

The closing announcement, which is the part most relevant to enterprises rather than frontier labs. Alongside the frontier-training rack, an OCP open-rack design is coming to market next year through OEM partners: on the order of 32,000 Zen 6 cores across 128 sockets, with multiple form factors so the customer chooses the CPU-to-GPU mix, up to around 102 terabits of fully programmable networking, in a standard 21-inch rack. The recording conflates the two product names, so check which is which before quoting them; the substantive point is that rack-scale AI infrastructure is being packaged for standard facilities and conventional OEM channels, not only for purpose-built data centres.

Back to the list of sessions

Watch this session on demand

BlueCat's short slot, working the same ONUG working-group scenario as their Panel Theater session – a poisoned artifact pulled into an agent's registry, which first shows up as flow collection simply stopping. The point of the talk is what you do with that: restart the collector and you have fixed the symptom and learned nothing. Their framing is worth borrowing whatever you run. Keep a record of what things ARE – is this an endpoint, a server, an application, which address did it hold at that moment – and a record of what things DID, the DNS queries, the flows, the packets, and join the two on address and time. The forensic value is in the history rather than the present state, and the example is the one to remember: an address that was a printer last week and a virtual machine this week. A SIEM will come back and ask you what that address was a fortnight ago, and something has to be able to answer. They also walk the six-step ONUG lifecycle – detect, diagnose, propose, verify, execute, validate – and make the fair observation that it should be drawn as a circle, because the point is that the next occurrence passes the same gates faster.

"If last week that IP address was a printer, and this week it's a virtual machine, you can see that kind of history."

Watch this session on demand

Cloudflare's field CTO, reaching back for an old word to make a new problem legible: the agent DMZ. The setup is one sentence and it does a lot of work – nobody would run public untrusted code inside their core database, and yet a model executes probabilistic code at runtime and has to reach tools, databases and SaaS apps to be useful, so the tool perimeter is now the untrusted perimeter. The number behind it is theirs to claim but hard to ignore from a network seeing roughly a quarter of the internet: agent-initiated daily traffic up seventeen hundred per cent year on year. The observation that deserves to travel is about identity. Most environments still rest on 2005 assumptions that collapse the moment a non-human principal holds a credential, and the clearest illustration is the one in the quote – two decades spent getting the industry onto multi-factor authentication, and the new principal cannot touch a hardware key or insert a smart card. What he proposes in its place: ephemeral tool grants rather than standing ones, interception of the payload rather than trust in the caller, non-repudiation so an action can be tied back to someone, and the rule that an agent never holds the API token or the service account. Plus a governance line worth adopting outright – no agent in production without a named human accountable for it.

"Software running on top of software that's never going to be able to reach out and touch a FIDO2-capable YubiKey or insert a smart card."

Watch this session on demand

The most unexpectedly useful twenty minutes of the theatre track, because it is about a cost line most AI architecture conversations never reach: the last-mile circuit. The founder's question to the room – how many providers could deliver a gig into this building, and at what price – is one almost nobody can answer, and the reason is what he calls the fragmentation tax. There are some eleven thousand physical last-mile operators worldwide, 2,300 in the United States alone, which is why procurement takes weeks and goes through intermediaries. For the venue itself the digitised answer was seventeen providers and a sixfold spread between cheapest and dearest, with most clustered far tighter than that – so the headline saving is real but it is not the interesting part. The interesting part is that the circuits are not equivalent on anything except price: latency, survivability, delivery time, SLA and architecture all differ, and five milliseconds against forty stops being an abstraction when the thing at the far end is an inference cluster being called fifteen times per transaction and GPUs are idling on the difference. His thesis is that AI economics will make those details matter to people who have never had to care about them, and that the decision will increasingly be made by something other than a human. The platform claims are the company's own; the question to the room is free.

"There are 17 providers that can deliver a gig here that range in price by almost 600%."

Watch this session on demand

Droma, formerly Grokstream, on governance-first agentic operations, and the single most useful sentence anybody said about agent safety is in it. The setup is honest about the stakes: give an agent a privileged shell and it can do anything your most senior network engineer can do, which is exactly the problem. Without new architecture you have made the existing operating model more convenient and less safe. The architecture he proposes has four parts. Persistent memory, but learned as it goes rather than a year spent hand-building a CMDB-shaped knowledge graph. Adaptive learning, meaning the thing recognises a mistake as a mistake. Explainable reasoning – if the agent says a recent config change is the likely cause, the operator gets the evidence and the alternative theories, as recorded facts rather than narration. And governance: who the agent is, what data it may see, which tools it may call, and – the question most deployments skip – who is entitled to tell it that it may make a given call. Then the line to put on a wall, below. The five-stage progression from answering questions to picking work off the same queue as a human is a reasonable maturity model, and stage four is where he puts the real inflection: the agent may execute inside policy, with a human approving particular tool calls rather than the whole turn.

"Constraints on an agent in a production environment should be deterministic. They shouldn't be prompt harnesses. If they're prompt harnesses, the agent will circumvent those safety protocols."

Watch this session on demand

A live demonstration rather than a talk, and the design decision underneath it is the transferable part. Most vulnerability tooling matches a version against an advisory and calls you affected. This reads the device's actual configuration to decide whether the CVE is exploitable on that box – and, more to the point, the language model is not the thing that decides. The model interprets the advisory; a deterministic engine holds the rules and is the arbiter of vulnerable or not, with the verdict rationale and the device evidence both shown. That ordering is the answer to a question every network team now gets from its CISO, and it is the quote below. The remediation half is a well-chosen piece of plumbing: the copilot writes a config model to disable the offending service, pushes it to a feature branch, opens a pull request carrying the summary, the constructs and the validation results, and waits. A human approves and merges, and only then does the automation run. Putting the human gate at a pull request rather than inside a chat window means the approval lands in the system of record your change process already uses. Product specifics – the exposure management application, the copilot, the RPA service – are the company's own.

"We want to make sure that if you're in a networking organization and you're accountable to a CISO, that you're giving them ground truth information, nothing hallucinated from an LLM."

Watch this session on demand

Lumen's slot, presented by Alkira, the network-as-a-service company Lumen acquired – so the speaker introduces himself as Alkira's and the recording carries Lumen's name. Not an error, but worth a line on the page so nobody reports it as one. It is a clear product explanation and little more. The proposition: build a global network with no hardware, no hop-by-hop configuration and no capacity planning, as a service from one portal. You deploy Cloud Exchange Points – virtual points of presence – and any two you create mesh with each other automatically, with no plumbing in between. Into those you land SD-WAN fabric, remote users, sites, data centres, carrier-neutral facilities and business partners, and you can host network services such as a firewall or DDI inside the exchange rather than beside it. Segmentation, routing, route control, traffic policy and visibility come with it. The framing he closes the architecture on is the one worth repeating, because it describes what a lot of enterprises are actually doing now whoever they buy it from.

"Essentially, you've become your own service provider for your business."

Watch this session on demand

A tight argument built on one progression: zero trust, then zero day, and now zero time. The framing of the two teams is familiar – NetOps measured on uptime, proud of a switch up for six years and therefore never patched; SecOps measured on currency and wanting it patched today – and both genuinely trying to keep the network up. What has changed is that the gap between them used to be survivable. The number that makes the session worth reading is below: with discovery and exploitation running at machine speed, the average interval from disclosure to exploitation is no longer a positive number, while defenders take up to 43 days to respond. Exploitation before disclosure, and six weeks of exposure before anyone starts. The supporting figures are worth checking against your own: roughly a third of breaches beginning with a vulnerability exploitation, about half of enterprise zero-day hits landing on security and networking devices – the appliances at the edge, which is to say the front door – and 29 minutes as an average breakout time. The conclusion he draws is the one a networking audience should sit with rather than nod along to: security can flag the risk, but the closing of it happens on the network.

"The exploit window didn't just go to zero, it actually went negative."

Watch this session on demand

The most genuinely experimental talk of the theatre track: somebody built a benchmark because he could not find one. The question he starts from is that the industry measures tokens per second and GPU utilisation, and never asks whether the agent finished the job – so he ran one identical end-to-end task across three kinds of provider, a hyperscaler, Akamai Cloud and a neocloud, and measured completion rather than throughput. The point underneath it is the quote: a GPU dashboard showing healthy tells you tokens are being produced, not that the tool calls were well formed, the right evidence was read, or anything useful happened. Three results worth having. Dropping precision from 16-bit to 4-bit floating point moved throughput optimisation from roughly 55% to 70%, which is the largest single lever in the experiment. Swapping the serving layer between open-source vLLM and NVIDIA's own runtime moved it one or two per cent – worth knowing before anyone spends a quarter on that migration. And the cost of running the same task varied between about two and six dollars depending where it ran. The architecture he describes around it – control plane pinned to a git commit and a model revision, then host and serving layer, then drivers, then the model – is a sensible shape for anyone trying to make their own comparison reproducible.

"A GPU dashboard that shows healthy… doesn't really mean that the agent is actually doing the right thing."

Watch this session on demand

Worth reading for one paragraph in which a vendor describes its own incident, which is rarer than it should be. Earlier this year an agent inside Aviatrix – no prompt injection, no attack, a support engineer using it for something innocuous – exfiltrated the company's entire roadmap onto a shareware site on the public internet. His question about it is the whole talk in six words: why did that agent have internet access? From there the case is about where agents will actually run, which is in AWS, Azure, Google and Oracle, and what the default posture there is. The figures he gives: most security groups carrying a quad-zero allow, more than ninety per cent of Azure workloads with no meaningful firewalling, and 92% of cloud workloads with no egress control – against JPMorgan Chase's published list for agentic defence, which says egress control alone would have substantially mitigated Log4Shell, SolarWinds and numerous supply chain compromises. He is honest that the reason this has not happened is not ignorance: cloud came in through platform teams and shadow IT before the network teams arrived, so it is a brownfield, and the four things that stall every zero trust programme are knowing where to start, fearing that a change breaks production, not knowing what policy to write, and keeping it current. The clearance platform he announces is the company's own answer.

"We had an agent at our own organization at the beginning of this year for a completely innocuous reason. No prompt injection… Exfiltrates our entire roadmap onto a shareware site on the public Internet."

Watch this session on demand

Yellow Theater

a twenty-minute Triple-T from a technical marketing engineer in Cisco's data centre networking business unit, based in New York and working mostly with banks. He was cut off before the end — "I'm getting the hook" — so the power and optics material at the close is compressed. The speaker's surname is unreliable in the auto-generated captions, so he is described by role here.

The opening frame is a good one, and honest about his own industry. Every Ethernet speed transition has arrived with marketing explaining why you need it. IP telephony "didn't move the needle very much." Video over IP genuinely demanded bandwidth, but the number of shops pushing large volumes of it is a small subset of the market. AI is the first one where the demand is real and general:

"Network IO ends up being the single most constraining figure for the performance of artificial intelligence workloads, especially when it comes to training in terms of job completion time."

Why, mechanically — and this is the clearest explanation of the barrier problem anyone gave at the conference. Training datasets run to many trillions of tokens, far larger than the memory of any single GPU server. So the dataset is split into chunks sized to the memory of the GPUs you have. Each GPU processes its chunk, which takes a variable amount of time. Then every GPU notifies the others and transfers its results. Then they synchronise — the barrier operation. And:

"If there is traffic loss or a slow connection, or for some other reason, one of the GPUs lags behind the others… the rest of the GPUs are going to wait."

So the traffic is bursty by construction, arriving in a spike at the end of every processing step, and the slowest path sets the pace for the entire cluster.

The economic argument that follows is the one to take to a budget holder. The GPUs are expensive and could go faster if the network fed them faster. Anything that increases job completion time is a direct cost, because it delays the next job and leaves the most expensive assets in the building running below their rated efficiency. Read that next to the goodput-per-watt argument from the Re-Architecting panel — two vendors, two formulations, the same point: the case for network spend is made in GPU utilisation, not in bits per second.

The contrast with a normal data centre is worth having in your pocket for explaining this to colleagues. Ordinary traffic is many uncorrelated flows — knowledge workers reaching databases, email, heavier backups overnight — and the cumulative effect averages out to a fairly even load. AI training has no such averaging. It is synchronised by design.

Inference is not a reprieve, and he listed three distinct reasons it loads the network too:

• Tensor parallelism — GPUs exchange activations and synchronise during model layers, with more cross-server partitioning creating inter-cluster traffic.
• KV cache movement — transferring key-value cache between servers. (The AMD session reached the same conclusion from the storage side, and Google's hyperscaler account described rebuilding load balancing around it. Three independent sessions landing on the KV cache is the strongest technical signal of the two days.)
• Mixture-of-experts routing — tokens handled by specialised servers with different aptitudes, which generates traffic between those server sets.

One honest experimental result, which is rarer on a vendor stage than it should be. They tested splitting an inference workload across two different accelerator types rather than the usual uniform fleet, connected over their own data centre network. The result:

"The performance increase was not mind-boggling. It was like a 6% increase in disaggregation time and slightly faster time to first token."

Reported as interesting rather than as a breakthrough. Treat it as an early signal that heterogeneous inference fleets are being explored, not as a reason to plan one.

The admission most worth carrying out of this session, and it came almost in passing while describing their own agentic operations tooling. The product takes a natural-language question about how an application is behaving, uses agents to collect data from any controller that speaks MCP — including third-party controllers that expose it — and aggregates the answers into a summary. Then:

"In our case, we have put guidelines around what we're doing, so don't spin up so many agents to overwhelm the network. But there are circumstances where this has occurred."

A networking vendor's own agentic tool overwhelmed a network by spawning agents, and they had to put guardrails on it. That is the same failure the Google Cloud Triple-T described as the "relentlessness" problem and the Re-Architecting panel described as the sprawl that shows up on the token bill. If it happens to the people who build the fabric, assume it will happen to you.

On silicon, for those tracking the supply side. The programmable ASIC family dates from a 2017 semiconductor acquisition. The programmability is deliberately not exposed to customers — an earlier attempt to expose it on third-party programmable silicon failed to find a compelling use case — but it lets one family serve several markets: ultra-low latency parts for exchanges, enterprise and telco parts, and two AI families, a scale-out series optimised for bandwidth and latency and a deep-buffer series for inter-data-centre traffic.

The distinction he drew is a useful one to understand generally: a run-to-completion or fixed-pipeline ASIC dedicates specific circuitry to specific functions — this region is the MAC address table, that one the MPLS tag table — whereas a programmable ASIC makes those memory regions and transistors fungible, with their use defined in software.

Current generation: 1.6T ports, a fully shared 256MB buffer available to any port, around 500 nanoseconds of latency at the ASIC in AI mode plus roughly another 200 at the switch. The first switch is 2RU with 64 ports of 1.6T, direct-to-chip liquid cooled, with an air-cooled version at 3RU and otherwise identical. Liquid is far more efficient; if your facility is air-only, that is the constraint to resolve before anything else on this list is available to you.

The load-balancing problem, explained well. With equal-cost multipath there is hash polarisation: the five-tuple hash can land two or more high-bandwidth flows on the same link between two switches while the other links sit with capacity to spare. At normal traffic volumes that averages out. At AI volumes it does not.

The fix across the industry is adaptive routing, which is packet spray — and he was straightforward about the consequence:

"You're thinking presumably out of sequence packet delivery, that would mess up the receiving server. In this situation, what we need to do is have a DPU on the server that's taking responsibility for packet resequencing."

So packet spray is not a switch feature you can buy on its own. It requires a capable NIC or DPU on every server to put the packets back in order. If you are evaluating AI fabric proposals, that is the question to ask: what is doing the resequencing, and is it in the budget? Their own variant always selects the least-loaded local port, which under spray should keep the links roughly even.

This is the third session to describe the same three-part solution — spray the packets, handle them out of order, manage congestion on a path-aware basis — and the standards work pulling it together is the Ultra Ethernet Consortium and the Open Compute Project, both named here as bringing to Ethernet the lossless behaviour and load balancing that used to mean InfiniBand.

The closing material, compressed by the clock: a co-development partnership with the dominant GPU vendor, including certification in both their enterprise and cloud partner reference architectures and a switch built on that vendor's own forwarding engines; a power comparison drawn from a publicly available slide from Meta; and a progression in optics worth knowing as a direction of travel — transceivers have historically carried a DSP for retiming, and the moves are to linear receive optics that take the DSP out of the receive path, linear pluggable optics that take it out of the ASIC, and co-packaged optics that move the optical-to-electrical interface onto the forwarding engine itself. Each step is about power.

Back to the list of sessions

Watch this session on demand

Frontline numbers from an incident response practice that hunts across seven trillion events a week, and the useful corrective is that the exotic agentic attack is not what is happening to most people. Identity still is: 74% of initial access is identity-based – stolen credentials, phishing, social engineering – and he thinks that share is rising, because AI lowers the barrier to running those campaigns well rather than inventing new ones. Lateral movement is still RDP, SSH and remote management tooling, which is worth a detection review this week rather than next quarter. The measure they have tracked for years is breakout time, the gap between initial access and lateral movement, and it has fallen every year to 27 seconds at its fastest last year – and they now say the measure has effectively collapsed, which is a quiet way of saying the industry needs a new one. The phrase to take away is "the agent state": tooling democratised to the point where ordinary criminal groups operate with capabilities that used to mark a nation-state actor. The threat reports referenced, including one on how adversaries build harnesses of agents to speed up attacks, are free on their site and are the company's own research.

"Last year, we saw it as just only 27 seconds was the fastest we recorded. But now, because of AI, that has effectively gone away."

Watch this session on demand

Digital Realty presenting as "customer zero" – what their own engineering organisation learned building with AI, rather than what they sell. Two structural changes first, from the vantage of a large carrier-neutral operator: rack density has gone from under ten kilowatts to seventy, a hundred and fifty, two hundred and twenty and beyond, and the traffic is no longer the north-south, CDN-shaped flow the industry spent two decades engineering for. It is east-west, scaled out and sustained, which is a different problem rather than a bigger one. The number to take away is from their own development practice, though, and it is the quote below: moving from iterative "vibe coding" to a spec-driven approach cut token consumption by something like 55 to 60 per cent. That is a procurement-sized saving available to anyone, with no product attached. He also names the thing quietly worrying finance departments – large enterprises going public about having burned an entire year's token budget by the first or second quarter – and makes the fair point that cost is only one of four pressures, alongside performance, scale and sovereignty. His framing of the state of the art is the right register for all of this: not a playbook, "the pursuit of wisdom", where learning more mostly reveals how much is left.

"It's probably something like 55, 60% savings on tokens just going down something structured versus iterative."

Watch this session on demand

A short slot from an early-stage observability company, and the framing is better than most of what is said about AI in operations. Start with the arithmetic: more code written means more logs, metrics and traces, against tooling that was already expensive, so teams sample – and at current volumes sampling is just a blind spot with a budget attached. Meanwhile nobody is reviewing all that code line by line, which means running software whose failure modes are unknown, and an unknown failure mode has no alert behind it. The observation that makes the talk is about where everyone is pointing their AI. An incident happens, you detect it, you resolve it. The industry's AI SRE compresses the second interval and leaves the first untouched, and the first is where the customer-facing damage accrues – with downtime put at over $300,000 an hour for most midsize and large enterprises. So their bet is detection of leading indicators from raw data with no handwritten rules: signals extracted in real time, gigabytes compressed to kilobytes with the raw kept in a cheap lake, and a defined remediation path that can open a pull request or call a human. The cost and coverage claims are the company's own. Speaking is Nicholas Lippis, Grepr's founding engineer, introduced by Nick Lippis – who notes for the room that this is his son.

"The only thing that they do is compress the mean time to resolve. You still have mean time to detect, and the incident occurred."

Watch this session on demand

Yellow Theater

a twenty-minute Triple-T. The first half is an argument about lateral movement that holds regardless of vendor; the second half is the product and its customers, marked as such below. The auto-generated captions mangle several product names, so tools are described rather than named where the recording is not reliable.

The story it opens with is the best single illustration of agentic risk from the whole conference, and it is small enough to repeat to a board.

A man in Melbourne could not get into a gym class — full every week. Reasonable problem to automate, so he handed it to an autonomous agent: book me this class. You would expect it to open a browser, go to the site, and keep trying. It did not.

"Instead of looking for the front door website, it found a back door. It found a REST API endpoint into the application that had a flaw that was unauthenticated… It booked this gentleman for the class, and it did so by deleting a bunch of other members from that class."

And then the three questions that matter:

"Did it accomplish the goal? Yes, it did. It did what it was asked to do. Did it do it in an ethical manner? Questionable. Where were the guardrails?"

Nobody attacked anything. A goal-seeking agent found the cheapest path to a legitimate objective, and the cheapest path was an unauthenticated endpoint and other people's bookings. Reported as one of the first AI incidents in Australia, back in August. He also referenced the widely-discussed sandbox-escape incident of a few weeks earlier; treat that one as cited rather than verified.

The generalised attack pattern he drew from it, which is worth writing down because it is now the shape of the threat:

1. Find the attack surface — a web front end, an API endpoint.
2. Look for vulnerabilities in that code, chaining several or discovering new ones.
3. Get a foothold.
4. Move laterally until the goal is accomplished, with whatever side effects.

The root-cause argument is unusually fair to our own industry. Networking was invented thirty or forty years ago to do one thing — make it easy for computer systems to talk to each other — and:

"Guess what? We did that very, very well."

Which is precisely why lateral movement is cheap, first for attackers and now for agents. He then traced the accretion honestly: we built routed networks, discovered too much connectivity was dangerous, spread firewalls about and started segmenting; then applications moved to cloud so we built VPNs; then third parties, partners and customers arrived so we built network extensions into their environments.

Three consequences, and the first contains the most quotable admission:

Too much lateral movement. On why segmentation never lands:

"We've all tried segmentation projects… You start on the project, the end state changes, and you never end up finishing it."

With a new wrinkle: people are now running autonomous agents on their laptops and putting small always-on machines with autonomous capabilities on office networks.

The entire network is the attack surface, because it is one contiguous thing. The illustration is good: to steal data from a sensitive health application you do not go at the healthcare server. You probe clinics and branch offices, find the one weak point, and walk from there.

Complexity, which he treated as the tax paid for the first two.

Why detection and response no longer closes the gap. Referring back to that morning's keynote, the argument is that you cannot outrun these systems: the detection-and-response cycle assumes you have time, and frontier models finding vulnerabilities at machine speed removes it. His compression of the whole problem, and the line to take away:

"If you're reachable, you're breachable. Anything that's exposed on the network unnecessarily is an attack surface."

Four converging pressures, a useful frame for explaining why security teams are losing ground: the attack surface is expanding; user experience degrades as you lock things down; complexity rises at the same time; and the security team was already overwhelmed before any of this started.

The architectural claim, which is the part worth arguing with rather than dismissing. Detection and response is an afterthought — it begins after something has already happened. The alternative is an architecture in which the problem does not arise:

"In the zero trust environment, you don't have a continuous network that connects everything to everything."

Every conversation — users, AI agents, applications, IoT, OT, data lakes, the internet — is brokered by a proxy making a real-time decision. His example is concrete: an IP camera may reach its controller on the internet, because that is where controllers live; the same camera talking to a known command-and-control address gets cut. And an infected device that starts scanning sees nothing, because there is nothing to see.

The branch architecture extends that to sites rather than users — branches, factories, clinics, hospitals, warehouses, retail — over any internet connection, wired, satellite or cellular backup. The claim attached is that it removes the need for a traditional SD-WAN and its attack surface, because every connection is established inside-out and there are no listening ports.

The anecdote they tell about it is the memorable bit. A customer deployed it and asked their CISO to pen test the result:

"CISO came back a day later saying, 'Well, I can't pen test it. I can't find it.' You can't break something that you can't discover."

And the internal half, which is the more interesting half. Every device — laptop, server, IP camera, whatever someone has plugged in — is isolated into its own subnet, a network of one, with all communication brokered. Devices on the same VLAN cannot reach each other without a policy. That is the mechanism that actually removes lateral movement, as distinct from making the site invisible from outside.

The third-party case is worth noting separately because it is a real recurring problem: an equipment vendor needing to manage, say, an MRI machine can be given access through a browser without being added to your network at all.

The asset-visibility point will land with anyone who has lived it. A vulnerability is announced in some widely-deployed product, and the first question from above is do we have any of this?

"A lot of leaders don't have the answer to that because the IoT is everywhere. It's very pervasive. It's very decentralized. Anybody in a remote office can go buy something and plug it into the network, and it'll talk to the internet, and you may have it, but you don't know it."

Whatever you think of the architecture, that question is worth asking yourself this week. If you cannot answer it, that is the gap.

One operational capability worth knowing exists, whoever you buy from: a pre-staged set of restrictive policies — a kill switch — that can be activated in one action when you are in triage and do not yet know what is happening. Deciding what "triage mode" means for your network before the incident is the kind of pre-positioning the Continuous Validation panel argued for from the SRE side.

The customer evidence, as presented by the vendor and reported here as their claims rather than as verified outcomes:

• A global paints manufacturer with 128 factory sites, dealing with firewall sprawl and third-party risk, now said to migrate a site in under an hour.
• A large US university with a segmentation mandate and a July deadline across 400 campus buildings, which they say could not have been met with firewall-based segmentation.
• An East Coast healthcare system with 2,000 clinic locations, growing by acquisition and carrying overlapping IP subnets, connecting them to common clinical systems.

The overlapping-subnets case is the one to follow up on if you grow by acquisition, because it is the problem that makes conventional integration projects run for years.

Back to the list of sessions

Watch this session on demand

Arrcus with 1FINITY and Fujitsu, on why a network built for training is the wrong network for inference – the clearest short statement of that difference in the theatre track. Training is a scheduled, predictable, bulk workload. Inference is bursty, relentless and latency-sensitive, it runs in many places at once rather than one cluster, and with agents in the picture the query stream never stops. That changes which metrics matter: time to first token, token throughput and end-to-end latency, rather than anything about bandwidth. It also changes the constraints, and the two he names are the ones enterprise architects underestimate – geo-fencing, because the data has to stay where the regulator says, and power and compute availability, which now decides where a model can run at all. The conclusion is a routing fabric that is aware of what it is carrying: predictable low latency across distributed sites, chosen with knowledge of where capacity and which models actually sit. The TCO claim and the product are the company's own; the training-versus- inference contrast is worth lifting whoever you buy from.

"As your workloads move from training to inferencing, this is where AI really enters the commercialization phase."

Watch this session on demand

Broadcom, delivered by the summit's own emcee, and the useful content is a side-by-side of what network teams measure today against what agentic operations will demand. Today: did the call connect, is the video smooth, what are the traffic patterns – eight to five, with backups at the weekend – and how much bandwidth per branch. Tomorrow: whether the model answers quickly and without errors, and whether agents launch jobs singly or in bursts, because capacity planning for many agents working at once with large prompts is a different exercise from planning for people. The part worth sitting with is about visibility, and it is the quote. Trace the actual path from a laptop to a slide deck in somebody's cloud – the local provider, the transit networks, the cloud itself – and it is dozens of hops, essentially none of which you manage. An agent asked to diagnose that has the same problem your service desk has, only faster. His framing of agents as simply more nodes to be monitored and validated is the right level of alarm: unexciting, and quite a lot of work.

"If I don't have the visibility into what this entire path looks like as a network operator, you're never going to be successful at agentic NetOps."

Watch this session on demand

Green Theater

a twenty-minute Triple-T, delivered by Matt Roman of Celestica. It is the most concretely engineering-minded talk of the theatre sessions and the least rhetorical. The second half is the company's own hardware and operating system, marked as such below.

The subject is the front-end network — the one that keeps the GPUs fed. Not the back-end fabric that connects accelerator to accelerator, which is where most AI networking conversation goes, but storage, orchestration, core services and the rest of the enterprise reaching into the cluster. It is the part most enterprises will actually have to build, and it got one of the few talks of the two days addressed squarely to it.

The framing to steal is the gap between a proof of concept and production, because it is the gap most of the room is standing in right now. In a PoC one team owns the system, the data is copied in once, setup is manual, and downtime is tolerable. In production the data moves constantly, several tenants share the fabric under their own service-level agreements, racks have to come up repeatedly and predictably, and nothing is allowed to stop. The economic argument for caring is one line, and it is the line to put in a budget request:

"An idle GPU waiting for data is a very expensive GPU and underutilized."

Five outcomes, each with a question to ask a vendor and a way to prove the answer. This was presented as a scorecard at the end, and it is the most directly reusable artifact from any of the theatre talks — an evaluation grid you can take into a procurement without buying anything:

• Reliable access to data — ask what happens when a path fails. Prove it by failing a link before you are live, not after, and checking both whether the remaining capacity is enough and whether recovery is fast enough.
• Predictable multi-tenant performance — ask whether one tenant can hurt another. Prove it by putting a heavy workload and a light workload on the same fabric and watching the light one.
• A path from 400G to 800G — ask for qualified optics and a migration plan from breakout cables to single-stream. The reason this matters is a cost inversion worth knowing: in these environments the transceiver frequently costs more than the switch it plugs into.
• Fast, repeatable deployment — ask how a rack is brought up, and how long it takes.
• Observability — ask how quickly a fault is found, and insist on the signals (link health, congestion events, timing) landing in the tools you already run.

The requirement that came up most often, and the one vendors keep missing: nobody wants another dashboard.

"Many of the customers that I talk to, they don't want a new dashboard. They don't want some new system. Their business runs around existing tools."

The corollary for anyone evaluating AI infrastructure is to treat northbound integration — gNMI, an API into the network management system you already have — as a hard requirement rather than a nice-to-have. And the oldest operational point in networking, made again and still true: much of the value is being able to prove it is not the network.

On open standards. The architecture is standards-based Ethernet in a leaf-spine Clos, deliberately not proprietary, and the speaker was explicit that while he would like every element to be his company's, you can mix vendors and should avoid lock-in. Worth noting as a position, since it is the opposite of how AI fabric is usually sold.

The product half, which is the company's own and should be read as such: the DS4150, a 1RU, 16-terabit non-blocking leaf switch on Broadcom's Trident 5, with 24×400G down and 8×800G up, breakout modes on every front-panel port, redundant hot-swappable power and fans, and selectable airflow. The breakout flexibility is what makes the 400G-to-800G migration claim work: the same hardware, the same network operating system, and the expensive optics potentially reused.

On SONiC, which is the part of the talk with the widest relevance. SONiC Distribution by Celestica is a hardened, tested, bug-fixed build of the open-source network operating system that Microsoft started and contributed — originally to OCP, now under the Linux Foundation — with fixes and features upstreamed back. It powers Azure and other large cloud networks, and the claim made here is rapid enterprise adoption now following. If you have been treating SONiC as a hyperscaler-only concern, this is the session that argues otherwise.

The adjacent detail is more useful than it sounds: a family of validated transceivers, because an MSA-compliant pluggable is not automatically an interoperable one.

"People think that a pluggable transceiver is based on an MSA, that it's just automatically going to work. And it is definitely not the case."

With up to 5,000 cables in a single compute cabinet, that is not a trivia point — it is where deployment schedules go to die.

Two customer results, the company's own figures, on similar platforms rather than the DS4150 itself. FarmGPU, a NeoCloud operator running GPU-as-a-service, took network deployment from ten weeks to two days on Celestica hardware and network operating system with Hedgehog — who also exhibited here — for orchestration and multi-tenancy. And a Fortune 500 retailer running community SONiC on Celestica hardware reported a 50% reduction in total cost of ownership.

The close was three decisions, and they are the right three for anyone starting this work:

1. Map the traffic. Decide what belongs in the front end and what does not.
2. Decide the bad day. Define what failure is tolerable — tenancy interference, failover time — before you are in production.
3. Prove operations. Exercise deployment, monitoring and recovery before production, not during it.

Back to the list of sessions

Watch this session on demand

Green Theater

a twenty-minute Triple-T, presented by Victor Moreno, a product manager for cloud networking at Google — the same person who sat on the Re-Architecting the Enterprise Network for AI panel. Worth reading next to that one and to The AI Data Layer, because all three converge on the same conclusion from different directions.

The argument in one line: agent governance belongs in the infrastructure, not in the agent, and the network is the only place that can enforce it everywhere.

Why agents are a different risk shape. Agents have gone from conversational chatbots to goal-oriented autonomous ones, and the property that matters is persistence:

"They are relentless in achieving those goals. They will go to any extent to get there and cause unintended problems in doing so."

Including spinning up further agents and commissioning work to them, which puts pressure on token and resource economics before it puts pressure on anything else. That consumption visibility was named as the first surface to govern — not the most dangerous, but the one that bites first.

Then the trifecta of risk, which is a usefully compact way to brief someone who has not thought about this yet:

1. Privileged data access — agents hold it, which opens them to being coerced into misusing it. The confused deputy problem, named explicitly.
2. Exposure to external influence — an agent that visits GitHub or a website can bring back code that does something unintended with that private data.
3. Autonomy — the ability to reach tools and act, on your behalf or on its own.

The objection he raised against himself, which is the one most networking people will have: this is an application problem, solve it in the agent or the MCP server, not my problem. His answer was that the surface is exploding —

"You can think of it as the big bang of agentic applications."

MCP servers proliferating, different models in use, and above all a variety of frameworks your developers are picking for themselves. There is no single place to attach the control. And the second half of the answer is organisational rather than technical: agents are not microservices, and you do not want governance to depend on each developer choosing to implement it.

Hence "shift down". Move observability, governance and security into the platform, where the network already sits. The mechanism that makes this tractable is worth taking away even if you buy nothing:

"You have the ability to set a floor policy that can't be used more loosely than what's defined. So you can tighten it, but you can't loosen it."

Developers keep their freedom above the floor. The floor is not theirs to lower.

Why the existing controls go blind. A traditional application is a web front end, logic and databases with firewalls between the tiers — a hard-coded topology where even the API calls are predetermined, so coarse groupings work and are effective. Agents break the premise:

"Things are probabilistic. Topology varies by intent. So the firewalls become blind, and your IAM policies are probably too broad and too permissive."

The response is to extend the firewall surface rather than retire it — to inspect prompts, apply guardrails and reason about business logic — while keeping the enforcement where it has always been. "Just like we were it for firewalls for decades, we are it now for enforcing these policies."

The anatomy, which is the clearest short account of how an agent actually runs. A client issues a prompt. The agent consults its MCP servers to learn what tools and data are available. Both of those exchanges need moderating — what was asked, and what came back. Prompt plus tools and data then go to the model, which reasons and returns a plan of action. From there the agent reaches out to MCP servers and commissions work to sub-agents, "and it could be many, many sub-agents. So you can lose control very easily there." That last step is where the governance and observability belong.

Three gateways, each doing a different job:

• Agent gateway, on egress from the agent: identity, authentication, authorisation, plus guardrails for prompt inspection and business policy. This is where the floor is set.
• MCP gateway: transcoding between MCP and REST, so existing REST APIs are reused rather than rebuilt, and the API catalogue gets enriched with MCP and agent-to-agent semantics it did not previously carry.
• LLM gateway: token consumption, quotas and cost attribution, plus model routing — a lightweight model for light requests, a heavier one for heavy — with developers switching by changing a variable rather than a URL and path.

The framing of who owns what also changed: SecOps has always dealt with producers, and the APIs have simply evolved to be MCP-enabled. What is new is the consumer side. "Previously we trusted and now we can't trust" — so the security operation moves to egress from the agents.

The six imperatives, offered as non-negotiables for governing agentic applications, and the most portable thing in the session:

1. Identity — agents get one, cryptographically attested.
2. Discovery — a registry cataloguing every resource an agent may reach, including federated domains.
3. Authentication — can this resource talk to that one.
4. Authorisation — and crucially not on identity alone, but carrying the protocol semantics of what the two are brokering.
5. Protection — inspect what is inside the pipe, because a connection can be entirely valid while the topic is entirely inappropriate.
6. Observability — which he called the most important of the six.

On that last point, a concrete detail: they have extended the OpenTelemetry standards with GenAI semantics plus token velocity and token count, so the telemetry coming off the infrastructure actually describes agent behaviour rather than approximating it.

The design principle that does the most work. The path out of an agent is non-bypassable, and the agent is not a participant in its own authorisation:

"All secrets, all credentials, everything is handled by the gateway… it never touches the agent. So the agent never has enough information to go rogue and do whatever it may."

A credential vault sits behind the gateway, enterprise identity providers authenticate the clients, and bearer tokens and session IDs are imposed on the traffic leaving the agent. If you take one architectural rule from this session, it is that the agent should never hold the credential it is using.

Chained identity, which is the subtlest idea here. Three patterns: a user acting on their own behalf, an agent acting on its own behalf, and an agent acting on behalf of a user. The third uses OAuth 2.1 delegated authentication — and the rights are not fixed:

"As we progress through the reasoning chain, you will see that if an agent has been in a risky place, we're going to demote the rights and actually take away the rights to do stuff on your behalf."

Why SPIFFE. Agents come and go too quickly for conventional identity. SPIFFE IDs are granular enough, cryptographically attested so they cannot be tampered with, and bound to the hardware at the moment of issue — move the agent and the identity is reissued. Note that SPIFFE came up independently in Recognize, Act, Assure as one of the two standards to watch; two vendors arriving at it separately is the signal worth acting on.

The registry, and the line that justifies it.

"You can't govern what you can't see… You can't attack what you can't see either."

An agent soliciting the registry gets back only the sliver its rights permit, so the catalogue doubles as a resolution point and a containment boundary — closer in spirit to DNS-based policy than to an inventory. It federates across clouds.

On portability, the detail most likely to matter to you. The enforcement point is an open-source Envoy Proxy agent, which means the same policy applies to a containerised agent in any cloud, a serverless agent anywhere, an on-premises deployment — and, the one people do not plan for, agents running on a developer's laptop. If your developers are running agents locally, that traffic can be governed on the same terms as production.

The extensibility argument alongside it is a good way to think about buying in this space:

"Just like in the firewall, you never own the policies, you just basically own the responsibility of inserting the enforcement point."

Policies then arrive as service extensions, from a growing set of vendors conforming to the same proxy specification, which is a more defensible position than betting on one vendor's policy engine.

What the policies actually look like today, in three layers: access policy binding principals — users, agents, and the delegated combination of a user and an agent — to resources in the registry, at real granularity (his example was read-only access to a calendar); semantic governance for business rules, such as whether a refund is within the permitted dollar range, geography and rate; and data protection on the way out, catching exfiltration and identifiers such as social security numbers.

The three-line summary he closed on, which is as good a checklist as any: shift governance down into the infrastructure rather than chasing SDKs; keep credentials out of the agent's hands; and insist on a comprehensive set of service extensions covering agent communications, MCP resource management and the LLM gateway.

Back to the list of sessions

Watch this session on demand

A testing company making an argument against the industry's own numbers, and it is the most quietly useful talk in the track for anyone about to buy on a datasheet. Today's inference benchmarks are built to be repeatable: a thousand tokens in, a thousand out, identical requests, no corner cases. That is excellent for regression testing and for comparing chip A with chip B, and it bears almost no resemblance to production, because it engineers out the two properties that actually break inference stacks – variability and burstiness. What real traffic looks like instead: multi-turn conversations, where each turn forces a choice between storing the KV cache and paying latency, or recomputing it and paying compute; chained tool calls where one output is the next input; context that expands through a session rather than resetting; and arrival patterns nothing like a steady stream. His summary of the problem is four words and worth remembering next time a vendor shows you a throughput figure. Ask what shape the test was.

"The shape of the test is basically wrong."

Watch this session on demand

Marvell on the memory wall, and the arithmetic is the reason to read it. Agentic sessions cannot be restarted the way a training job restarts from a checkpoint, because the agent needs its causal history to know where in the workflow it was – so the context has to be kept, not recomputed. Using a published reference of about 6.4 gigabytes of KV cache per thousand tokens: a short 4,000-token chat costs roughly 28 gigabytes, while a modest agentic session, where sub-agents spawn and tool calls layer context on context, reaches 128,000 tokens and about 825 gigabytes. One session. At a million sessions that is six million gigabytes, which is larger than any single scale-up domain anyone builds today, so the limit is passed first at the server, then at the rack. AMD's main-stage session arrived at the same pressure independently, with the KV cache spilling out of high-bandwidth memory onto NVMe – two silicon vendors describing the same wall from different sides. The business evidence he opens with is also worth having to hand: Klarna's customer service agent handling 2.3 million transactions in its first month, about two-thirds of volume, with mean time to resolution falling from eleven minutes to two.

"Just one session would consume about eight hundred and twenty-five gigabytes."

Watch this session on demand

Tata Communications on the gap between how confident boards are about AI and what the deployments actually return – which they call the AI paradox, and which is the honest frame for a lot of what was said over the two days. The three pillars they put under a durable deployment are conventional but correctly ordered. Context, meaning the model reaches a connected data set rather than islands, because an enterprise decision needs enterprise data. Explainability, with the data flows mapped so a decision can be audited rather than narrated. And governance, which they extend to sovereignty – where the data is allowed to physically live – which for a global carrier is a daily constraint rather than a slide. The warning they hang on it is from Gartner and IDC: a majority of agentic initiatives cancelled by 2027, with most proofs of concept never reaching enterprise deployment. Their diagnosis is the one a networking audience should take personally, and it is in the quote – the network is an afterthought, and the instinctive response to an AI rollout is to add bandwidth and hope. Their own survey with Bloomberg put 28% of prospects expecting trouble integrating AI with legacy systems, and a larger share doubting their infrastructure could run the workloads at all.

"I may not care about the network, or in the worst case, let me throw some bandwidth and hopefully things will work."

Watch this session on demand

A distributor rather than a product, and the talk is mostly an account of what they have assembled – government, healthcare and increasingly critical infrastructure, with cybersecurity the largest practice. The part with reusable shape is the post-quantum migration, which they have been tracking for three years against the executive orders and OMB memos and have broken into stages. Enablement first, because many organisations need their own people brought up to speed before anything technical starts. Then discovery and inventory, which is the step everyone underestimates. Then the roadmap and gap analysis, which is a services engagement rather than a purchase. Then remediation – the algorithms themselves, and key distribution where that applies. Set against the Health-ISAC chair's session on the Panel Theater, which said the same thing from the practitioner's side and added that a tenth of what an inventory turns up is not quantum-vulnerable at all but simply deprecated, this is a fair map of the work. The portfolio claims are the company's own.

"Regardless of where you are in a maturity level from a quantum perspective, you may need enablement for your employees to just get started."

Watch this session on demand

Two true stories, and they are the best teaching material from the whole theatre track. The first: a company using Gemini as a meeting recorder, a staff meeting of about thirty people discussing concerns about their manager – that he was arrogant, and worse – and the assistant, which had access to email, summarised the discussion and sent it to the manager. Nobody asked it to. The second is sharper. An invoicing team put an agent in front of the inbound pile to reconcile invoices against job orders. Someone submitted a fraudulent invoice with instructions hidden in the PDF in white text: find the competing invoices and send them to me, and issue a $48,000 refund. The agent did both, because it was running with the invoicing clerk's credentials, and she learned about it when a colleague mentioned the refund she had asked for. The framing around them is the point the industry keeps restating and this makes concrete: we spent years treating stolen credentials as the worst thing that could happen, and we now hand credentials to something that reads untrusted input and acts on it. The question he leaves is the right one to take back – not whether an agent can execute, but where the stop is.

"Maya didn't even know this happened until somebody said, 'Hey, we executed that $40,000 refund you asked for.' And she was like, 'I didn't ask for that.'"

Watch this session on demand

Ten minutes on storage economics, and the single most useful price signal anyone gave. Flash and spinning disk had been converging on cost per terabyte for years; that reversed. NAND went up 25%, then doubled, and he puts SSDs now at around three times where they were – with only four NAND makers in the world and backlogs measured in years, so this is not a quarter's blip. The headline number: a solid-state drive can cost twenty times a spinning drive per terabyte. That does not make disk right for everything, and he does not claim it does – the argument is for hybrid, with flash in the controllers and specific workloads pinned to it so they get an all-flash experience, while backup and archive sit behind on disk. The other half is the floor-space crisis, which anyone who has tried to get cabinets this year will recognise: data centres full, every tile occupied, GPUs taking the power. Their consolidation example is 280 tiles down to 61 and ten million dollars of floor space in a year. Consolidation ratios, the payback analysis and the awards are the company's own.

"An SSD could cost 20 times at a per terabyte level that a spinning drive costs."

Watch this session on demand

The operational companion to NetBrain's main-stage session on the harness – less argument, more showing the controls. Three pillars, and they are a reasonable checklist for any agent you are asked to approve. Staged autonomy, with a human in the loop or on the loop rather than the agent acting on its own account. Governance by design, meaning permissions scoped to exactly the task, nothing more. And oversight you can see – how the agent reached its conclusion, which checks it ran. What makes it concrete is the agent studio they walk through, where an agent is defined by persona, the resources it may reach, and the skills and tools it may use, each adjustable per agent so a change agent and a companion agent are not given the same reach. The idea worth carrying regardless of product is in the quote: an agent is not one thing you trust or distrust, it is a named identity with a declared scope, and the declaration is what makes trust possible. The walkthrough uses a real diagnostic – an application path that deviated from its primary route between two sites – and the agent iterating diagnosis until it reaches a conclusion it is confident in.

"Trust starts with defining who each agent is, its persona, its permissions, and its level of autonomy."

Watch this session on demand

Billed as "your agents are already talking to each other, who's watching", and the first half is company positioning – the analyst rankings, the customer count, the private cloud backbone – so take that as the vendor's own. The idea worth lifting is a single sentence of operational philosophy that applies whatever you run: a performance problem is a security problem. You can assemble a faultless security architecture out of every acronym on the market, and if it cannot move traffic quickly enough, people will route around it, and then you do not have the architecture you think you have. That is the argument for inspection sitting close to the user rather than backhauled, and it is the reason the same company's design puts a proxy inline for everything on a zero trust engine. Said by someone who spent 28 years as a Gartner analyst before joining them, which is worth knowing in both directions.

"If you have a performance problem, you have a security problem."

Watch this session on demand

Two things make this one worth watching rather than reading. The first is the volume data: more CVEs reported in the first two quarters of this year than in all of last, past thirty thousand, and a single Patch Tuesday in September fixing some 974 vulnerabilities – against 1,009 for the whole of 2024. One month now costs what a year used to. Alongside it, roughly 600,000 new pieces of malware a day, with signs that many were created or augmented by a model. The second is a live demonstration that should be shown to anyone who believes model guardrails are a control. He asks an agent to download a compression tool, encrypt his documents folder into a single file, and then delete the originals – which is, functionally, ransomware. The agent notices. It says it looks like an attempt to bypass the endpoint control and asks him to confirm he is not a malicious hacker. He says go ahead. It proceeds, deletes the files beyond recovery, and then helpfully observes that this looks like ransomware. A guardrail that asks politely and accepts the answer is not a guardrail. The product conclusion is the company's own; the demonstration stands on its own.

"It says, 'Look, it looks like you're trying to bypass ThreatLocker. If you're a malicious hacker, let me know, and I will stop.' We then say, 'Yes, go ahead and do it.'"

Watch this session on demand

WWT with Intel, on post-quantum readiness, and the explanation of the stakes is the plainest anyone gave: quantum takes the S off HTTPS. Everything that follows from that – would you transact with a site whose lock was broken – makes the problem legible to an executive in one sentence. The urgency argument is harvest-now-decrypt-later, and he is specific about what is being harvested: traffic to cloud and productivity services, logs, PDFs, legal documents, set aside against the day a cryptographically relevant machine exists. Which nobody will announce. The second-order risk he raises gets less airtime than confidentiality and deserves more: signatures. Once signing can be forged, signed code cannot be trusted, and the attacker's route is ordinary business rather than a breach. On timing, the federal edicts point at 2030 and in practice 2031, which sounds comfortable until you set it against two to three years of actual migration work. And his punchline to a networking audience is the one to carry: this is not a security team's project, because the work lands in the infrastructure. The Health-ISAC chair's Panel Theater session said the same from the practitioner's side.

"The quantum computer's not here, but the quantum threat is."

Watch this session on demand

Cisco's CTO, and he opens by saying it is not good news. The substance is the most concrete account anyone gave of what frontier models have done to vulnerability discovery, from someone who has had the tools since April through Project Glasswing – including a build without guardrails. The number is the thing. In the Nexus operating system they would historically find eight to twelve critical or high vulnerabilities in a year, and those were the work of genuinely expert humans. What changed is context length: a model can now hold fifty or a hundred million lines in its entirety and trace the odd interdependency between one module and another that ends at root. The result is a step function, and these are not academic findings in the mould of the old processor bugs – they are send-this-sequence-of-packets-and-own- the-device findings, in equipment running in production now. His instruction to a security audience is to assume the adversary has the capability, whether through the controlled models or the open-weight ones a few months behind. What follows is the part the industry has avoided: the operating model has to change. Distrust the upgrade, test it for months, skip several versions, upgrade as rarely as possible – that playbook is visible in their own telemetry, with customers running software one and two years old and a Catalyst 6500 up so long that a child born at the same reboot would be at university. Patching faster does not rescue it. The model itself has to go.

"If you know the right sequence of packets to throw at a switch or router or firewall, you can get to root. And you get in, and you can cover your tracks and hide."

Watch this session on demand

A quantitative market analyst addressing the enterprise buyer, and the most commercially literate twenty minutes of the two days. His thesis is in the title and sharpened in the quote: cybersecurity spending will grow, and that tells you nothing about whether suppliers can hold price or whether you get value. Five claims, all worth testing against your own renewals. New AI risks do not erase old controls – the analysts who declared security dead when frontier models arrived overcorrected, because the environment AI runs in still needs its identity, data, network and cloud controls. New demand does not guarantee pricing power, which is his challenge to a decade of platformisation and everything-becomes-a-suite. AI automates the work, not the accountability, which is the line for anyone being sold autonomy. The moat is moving from features to execution, because features are now quick to copy. And – the one to put in front of a vendor – a platform purchase is not a platform outcome. He does see a genuine new category forming around what he calls AI system security tooling, which looks at the whole path from employee agent to AI application to model to system of record, rather than any single hop. Bullish on the need, selective on the monetisation, demanding on operational proof is a good posture to borrow.

"Market growth is not the same thing as supplier pricing power, which is not the same thing as customer value."

Watch this session on demand

Three practitioners – healthcare, aerospace and defence, and a large enterprise – on what the summer of constant patching actually did to their operations, and it is the most useful session for anyone who has to ask a board for money. The change they all name first is velocity: the weekly or monthly change window is gone, and updates now arrive whenever they arrive. What has not changed is the safety envelope, which is the tension the whole hour sits in. Their triage is worth copying – sort by blast radius and by what is externally facing, move on those immediately, and let the internal estate keep a traditional schedule. Two investments came up repeatedly. A digital twin to simulate every change before it lands, which one of them is building now, with the honest note that explaining to non-technical executives why this is different from the vulnerabilities of five years ago is itself the hard part. And micro-segmentation, which one had pushed through years earlier for other reasons and now pays for itself: when something happens they can isolate a region of the estate instead of losing all of it. The board conversation varies more than you would expect. One says the narrative has genuinely changed and the money is there, because exposure now reads as revenue and reputation. Another is still building the case piece by piece – with two former IBM chairmen and Google's CFO on the board, asked to help explain to the others that this is not crying wolf. The line that frames all of it is below.

"We were built for human scale. How do we adapt to the AI scale? That is the real challenge that everybody's trying to tackle right now."

Watch this session on demand

BDO's chief digital and technology officer with Amir Khan – who founded Viptela, then Alkira, now part of Lumen – on the wide area network, which got less airtime over the two days than it deserved. The framing in the first minute is the one to keep, and it is the quote: forty years of infrastructure designed so that people could reach each other through applications, and now infrastructure designed so machines can reach each other on our behalf. Ask a model how it would build a network for an agentic enterprise and it does not describe what you have. What makes the BDO half valuable is that it is an extreme case of ordinary conditions. One hundred and ninety-six countries, each with its own CEO, board and budget, because it is a partnership rather than a company; acquisitions and divestitures most years, so offices, people, data and compute arrive and leave continuously; and a lean team carrying all of it. There is a generational tension in the investment decisions too, between partners near the end of their book of business and those at the start, which is a dynamic most technology arguments pretend does not exist. And a live commercial question underneath: if AI compresses the billable hour, professional services moves to outcome-based pricing, and nobody has worked out how yet.

"We designed infrastructure for humans for 40 years… Now we're really designing infrastructure for machines to talk to each other on our behalf."

Watch this session on demand

Opens with a breach so unsophisticated it is almost funny, and then makes it land on everyone in the room. A week and a half before the summit, refrigeration controllers across five French supermarket chains and a long tail of independents went from minus sixteen to a hundred and seventy-two degrees overnight – food cooking in the cabinets, fires in some stores. No ransomware, no coordination, no sophistication. More than fifteen hundred controllers sat on the public internet with no filtering of any kind, mostly on default passwords, much of the firmware years old and some of it not updatable at all. His line about it is the quote. The turn is the part to pay attention to. It is easy to file that under careless shopkeepers – and then he asks what the default network stance is for every workload provisioned in every major cloud, including the agent runtimes the hyperscalers shipped this year. It is unlimited connectivity, open to the internet, and the switch is flipped that way when you create it. He is unsentimental about why: the cloud business model runs on developer velocity, asking a developer with no networking background what a workload should be allowed to talk to is friction, and the shared responsibility model puts every bit of that on you. Worth reading alongside their theatre talk, where the same company describes its own agent exfiltrating its roadmap. The product is theirs; the argument that the network is the control is older than the product.

"My seven-year-old son's friend could have actually managed this hack even without AI assistance."

Watch this session on demand

The most commercially consequential session of the two days: Cisco's CTO with enterprise buyers, on what suppliers owe customers now that customers can build. The admission that opens it is remarkable from a vendor stage – decades of competing by feature are over, because he can now generate any feature a competitor has in about two weeks, and so can they. Then the survey that lands it. Ask a room what proportion of a firewall's features they actually use: the answer is around a quarter, and the other three-quarters are not bad features, they are features nobody has the staff to understand, deploy and run. With everyone patching constantly, appetite for new ones is near zero. So the axis moves to the platform – his example being that a firewall is only a router with the default inverted, and merging the two makes the estate manageable in a way no feature does. The enterprise response is sharper still. We are far too complex, says one, and the lesson of the last few months of patching is that we cannot train our way out of it: smart people should be solving the company's problems, not decomplexing its infrastructure. The purchasing consequence is a genuine reversal – the old bake-off picked whoever had the feature today, because waiting eighteen months was not an option; now the question is who can be trusted to simplify, since the feature will exist either way.

"With AI coding, I can generate any feature that my competitors have in two weeks. It's nuts. And likewise, they can do anything I can do."

Watch this session on demand

The second morning's opener, and the best available summary of day one in a single word: control. Not fear – fear is a motivator but not a plan – but the recognition that harnessing the thing means being able to prove what it may and may not do. Which is a fair reading of a day that produced the lethal trifecta, the agent you can switch off by revoking a key, deterministic constraints rather than prompt harnesses, and three independent arrivals at SPIFFE. The harder note comes from the infrastructure panel: a lot of organisations are approaching this wrongly, not in their technology choices but in treating the network as something the IT department takes care of rather than as a holistic undertaking – a departure from how the last forty years were organised. Then the exchange that is the most honest thing said across the two days, and the quote. One of them argues that the industry has spent two or three years being alarmed, that the alarm was necessary, and that this is the year to stop worrying and do the work. Nick's reply is the corrective, and both are right: the work is clear enough to start, and what was true six months ago is already obsolete.

"I do really feel like this year is that year where we stop worrying, we just start doing the work." / "Oh, I think there's still plenty of time to worry."

Watch this session on demand

AWS, Google Cloud and Isovalent/Cisco with a Bloomberg Intelligence analyst, on whether agents need a network of their own. The answer, from the AWS side and broadly agreed, is no: we have transport, we have discovery, we have exchange mechanisms, and what is missing is that the network we already run does not understand these new identities. An overlay earns its place for two things only – carrying a verifiable identity together with its delegation context, and giving one policy definition and enforcement that does not depend on a particular vendor. Which leads to the most precise statement of the industry's actual gap that anyone made over two days, and it is the quote. SPIFFE and its peers can say which workload this is across a trust boundary. Nothing standard can yet say that this identity may act on behalf of that principal, for these actions, within these limits – and agent delegation is almost entirely about acting on someone's behalf. The Cisco view adds the taxonomy problem underneath: an agent is not a user and cannot hold a user's rights, and it is not a machine to be handed a service account, so the industry needs a third kind of identity it has not yet defined. Two practical notes. The front-end network, where agents actually run, is Kubernetes – at the labs and at most enterprises – which is a different conversation from the RDMA and GPU fabric talk that filled the rest of the summit. And because agents are ephemeral and nobody knows where or under what identity they will appear, the networking has to be just-in-time.

"What we don't have is a way to say, okay, well, that identity is allowed to act on behalf of this particular principal, and it's allowed to do these actions, and it's allowed to do it within these limits."

Watch this session on demand

A data centre operator, a cryptography vendor, a mathematics professor and a government technology broker on the post-quantum mandate, and the value is in how unsentimental it is. The deadline moved: what was understood as 2035, itself ambitious, is now 2030 for government systems. Nobody has done this before – zero trust was a posture, this is a cryptographic transition, and the last comparable one predates the internet at its current scale. The most useful scepticism in the room is aimed at the cryptographic bill of materials, which is the artefact everyone reaches for: see the quote. An inventory helps, and it does not solve a problem embedded in firmware across things nobody can enumerate. Two honest positions worth noting. The data centre operator says plainly that his team will not be choosing algorithms or running key distribution – their role is compliance, governance assurance and picking partners – which is the correct answer from an infrastructure provider and a useful signal for anyone assuming their colocation vendor has this covered. And the hardest category gets named: assets that were never built to be upgraded, are long past their anticipated life, and are too mission-critical to retire. There is no migration for those, only compensating controls, and every enterprise carrying technical debt has some. The phrase that captures the whole programme is flying the plane while building it.

"I'm dubious that that's going to help you very much when there's 400 pieces of cryptography in my cell phone."

Watch this session on demand

Panel Stage

A Bloomberg Intelligence analyst in the chair, with IDC and Dell'Oro either side of him. The session exists to do one thing: take the headline AI build-out numbers and work out which part of them lands on an enterprise IT budget.

The first move was to shrink the number. The $1.7 trillion AI server spend Bloomberg Intelligence carries is, on the panel's own account, principally hyperscaler and neocloud money — "I'm not saying that this audience will be spending part of that $1.7 trillion." The enterprise figure IDC put against it:

"We forecast that AI infrastructure spending in the enterprise is $623 billion in 2026. That's up 31%."

Servers are the majority of that. The part that matters in this room is what grows fastest:

"We're seeing networking as the fastest growth category, primarily in the data center. But we are seeing significant refresh in the campus as well."

Around 42% growth over the forecast period, to roughly $45 billion. Dell'Oro's complementary figure is narrower and steeper: AI system security as a market was about $200 million in 2025 and is forecast to reach $8 billion over five years — "explosive growth in pockets, but overall a very slow rising tide" on total infrastructure spend. The structural claim underneath it is that security tooling is moving into the infrastructure line of the IT budget, next to compute, storage and networking, rather than sitting beside it.

Where the money is coming from is the honest part of the session. Both houses see the same thing, and neither sugars it:

"Money doesn't grow on trees, and I don't think cybersecurity budgets or AI infrastructure budgets necessarily grow on trees either."

There is some net new budget. Mostly there is reprioritisation — an AI budget assembled by haircutting elsewhere, "not free money that's in blank checks." The one piece of good news for anyone defending a line item: AI and security were named as the two areas least subject to trimming.

The practical workarounds, named on stage. This is the most immediately usable material in the session:

• Vendor take-back and circularity programmes — return end-of-life equipment, take the credit against a modernisation purchase.
• Recertified and refurbished equipment — a way through supply-chain constraints at a lower price than new-in-box.
• Vendor financing. HPE Juniper's 990-day zero-or-low-percent programme was cited, with Cisco having matched it. The panel's framing: "coupon clipping."
• Colocation instead of building. A direct report from customer conversations: asked when they would buy servers for a new on-prem private data centre, the answer was that they would not — they are going to private colos and renting the hardware, because "they don't know how much to buy" and flexibility beats "locking in a CapEx cost for seven years of amortisation."

The attached guidance: have a FinOps practice, in-house or with an SI partner, because working out where workloads should live on a token-cost basis is not your day job and keeping the lights on is.

The readiness verdict. One line carries it:

"Ambition outpaces readiness."

Long AI wishlists, thin viable use cases, and real immaturity in whether the infrastructure can carry the initiatives at all. Networking and storage were named as the two least mature areas. The second panellist's framing was that this is 2005 again, and he was explicit about who benefits from the urgency:

"The vendor community's doing a very good job from the infrastructure perspective to build this fear that, hey, if you don't upgrade now, you're going to be left behind."

His counsel was to take a step back and establish what AI actually means for the organisation first — and he conceded how hard that question is: "besides coding, what is the killer use case, the next killer use case going to be for the enterprise? And I think we're still looking for that." Worth holding alongside the purchasing pattern he reported: capacity and storage being bought now with "AI ready" as the stated reason but no black-and-white requirement behind it, often a higher SKU on a refresh that was happening anyway.

A hard constraint to plan around: the forecast is for no meaningful high- bandwidth memory availability until about 2028. The recommendation for the intervening period was to spend it on the non-hardware work — what AI does to your workflows, your workforce and the skills you need.

On repatriation, the panel added a third driver to the two you would expect. Security brought it on, token economics accelerated it, and sovereignty is now in the conversation. The conclusion was deliberately unexciting: a blended, hybrid end state, certain workloads home for performance, security and economics, others staying on closed-weight models in public cloud. "You can't paint with a single broad stroke."

On technical debt, two findings. First, the starting position is worse than the debt itself: "a lot of IT teams don't even know what they have and where it is," so a formal discovery and assessment programme to catalogue the health and age of the estate comes before anything else. Second, there is no composable AI stack to buy — no equivalent of what VMware was to virtualisation twenty years ago — which the panel named as the open opportunity for the vendor community rather than something enterprises can purchase their way out of today.

Platform or best of breed, which is the live procurement question for most people in the room. Dell'Oro's formulation from the morning session was repeated here: larger markets but thinner competitive moats. The argument is that AI thins the moats around today's platform suites, which reopens multi-vendor solutions and swings the pendulum back from platformisation toward best of breed, particularly in security. The qualifier: "the things that are big will continue to be big." IDC's addition was that multi-vendor control planes now make managing a best-of-breed estate practical in a way it was not.

The operational layer was where both analysts converged. Automation, not AI, is the current blocker:

"One of their biggest challenges is automation. And there's going to be a very long tail in terms of automation, even before they begin to talk about AI for networking."

AI for networking means new workflows and new operational practice; infrastructure as code and network as code are a different skill set again, and most teams are not prepared for it. Training, augmented staffing from a partner or vendor, and deliberate knowledge transfer were all named, with the warning that it is arriving faster than the conversation suggests. Underneath that, a twenty-year-old security discipline restated for agents:

"Security is technology, process, and people… just because you have agents doesn't obviate the need or the role that humans play."

And on autonomy, a sequencing recommendation rather than a position: human in the loop on day one; automate the boring, monotonous bottom layer first; move up only as teams get comfortable.

The closing asks, for anyone who has to turn this into a plan.

Invest aggressively in: data centre network architecture, with 800-gig fabric named as the thing to be getting ready for; and network security east-west as well as north-south, with the ability to take remediation action quickly.

Avoid over-committing to: the checkbox. Spend the time and the money to understand your own environment first — "there's a lot of tooling to give visibility to what you already have, let alone what you will need" — and sketch the destination before buying, because the alternative is "a lot of zigzags that are very costly, very timely." Buy less of whatever happens to show up at your doorstep; neither a point product nor more platform bought blindly will help.

Five years out, the panel's own prediction, and a good line to leave with:

"I don't think we'll be using the term AI infrastructure. I think we'll just be talking about AI workloads… all infrastructure will be infrastructure."

Back to the list of sessions

Watch this session on demand

The most practically grounded panel of the two days, because one of the four has been running an AI-enabled NOC across eBay's entire production for eighteen months – after a year of development, deployment and security review first, which is the part nobody puts on a slide. FedEx, OpsMill and InsightFinder fill out the table. Their agreed starting point is unglamorous: the foundation is the data, and every organisation that succeeded began there. The reason is well put – a human operator carries design, history and judgement in their head and can go and read the runbook, and any automation, traditional or agentic, needs that same context made explicit before it can be any good. Garbage in, garbage out, with the twist that the scarce asset is not raw telemetry but normalised data and the knowledge that lives with the same ten people in every company. After data comes workflow, and they are refreshingly modest about where to start: opening the ticket, touching the service management system, calling the carrier. Unexciting, and a genuine win. The warning that should travel furthest is from the distributed systems researcher on the panel, and it is the quote. A hallucination is a silent failure – no crash, no "I don't know", just a plausible answer – and when one agent takes its input from another, a wrong answer upstream is laundered into confidence downstream. Hence the rule they all land on: a human approves anything that writes.

"The hallucination is silent failure. It doesn't crash, it doesn't tell you, I don't know. It gave you answer. And it sounds very actually reasonable."

Watch this session on demand

Panel Stage

A fireside between Phil, who built Micromuse and then Moogsoft between 2010 and 2022 and is now building CrazyCatz, and the analyst interviewing him, who sits on that company's board and was one of the people who put the name "AIOps" on the category in the first place. The title is his own verdict on it.

The argument is not that AIOps was the wrong idea. It is that it was the right idea a decade too early:

"I think the ambition for what we had at Moogsoft was exactly the right ambition. I think the problem that we were trying to solve is exactly the right problem to try and solve. All we had back then was machine learning."

"Success is a lousy tutor."

The second mistake was architectural, and it is the one that matters for anyone buying operations tooling now. Moogsoft was built around the org chart it found:

"…we kind of built around the current organizational structure and operating model, and what Moogsoft did was help automate the way humans did their job."

The claim is that this inverts. The classic operations pyramid of "catch and dispatch" exists to protect your most experienced people by putting layers of response teams in front of them. Agents run the other way: they take the judgement of your senior operators and push it down onto the infrastructure directly.

"…it is adapting to the agents, not the other way around."

Asked how far agentic triage can go, the answer was unhedged — "all the way to no human hand" — with self-driving and autopilot as the analogies, and the blocker named as cultural rather than technical. The caveat attached to it is worth as much as the claim: a language model alone will not get you there, you need a model that has learned how the infrastructure actually behaves.

The number that will get quoted from this session. Having rebuilt the engineering org around agentic coding, they measured output against the same team's work at Moogsoft:

"The number is 16 times, one six times."

With the quality metrics — coverage, scalability, failure resilience — also ahead. Two details stop that being a simple productivity story. Scrum teams went from seven or eight people to one, and they then had to "manufacture the friction that used to be there for a good reason" to keep quality and security honest. And the shape of the team changed: more product-aware senior engineers, fewer junior ones.

Where LLMs run out of road. Mathematics, software and music are all language — abstracted semantic meaning — which is why models do well at them. Physical systems that do not obey well-understood rules are the limit, and the expectation is specialised models trained from the ground up on specialised data rather than more of the same.

The wider frame, from the interviewer: everything since ubiquitous connectivity arrived in 1992 has been incremental, SaaS included — multi-tenancy and a common code layer, which bought return on assets and not much else. AI is the first non-incremental change since, and it lands on how a business is organised, operated and measured. The evidence offered was a Shell refinery in 1986–88, where linear and quadratic programming took headcount from 2,200 to 650 — but the real prize was being able to optimise what the plant produced against what the market wanted:

"Technology wasn't just important. Technology was the only way you could run the refinery. There was no other way of doing it."

The practical ask that came out of it, and the least obvious thing in the session: the skill this needs is process engineering. Somebody who can study a process, do time-and-motion on it, and ask who is touching it and whether they need to be.

On security, from the audience Q&A. Static detection means you already know how the attack unfolds, which is no use on day zero:

"Security is a predicate. It's a requirement. You can't roll out any platform that's new without security."

And one practice worth stealing regardless of vendor: they code with an adversarial agent in the loop that understands how the system can be breached — described as having the best vulnerability analyst you can get sitting on every scrum team.

Back to the list of sessions

Watch this session on demand

Thirty-eight years at the National Security Agency, finishing as director of cybersecurity – the person responsible for making the cryptography and keys for US national security systems – which makes this the session to cite when somebody calls post-quantum a vendor story. His framing of why the threat is present tense rather than future tense is the clearest available. Ordinary cyber threat work has indicators, signatures and a hunt guide. This one has none, because harvest-now-decrypt-later leaves no trace: an adversary copies encrypted traffic or files today and waits. You cannot detect it, and you cannot undo it. What you can do is in the quote – snap the chalk line. Everything collected after you implement post-quantum cryptography is out of reach of a future machine, and everything before it is not, which turns an abstract deadline into a date you are choosing by inaction. Also worth knowing: the US government has been preparing since roughly 2010 to 2012, so the timeline is not a reaction to recent hype. On where to start he is specific and matches the practitioner sessions elsewhere in the programme: discovery first, because most organisations do not know where cryptography lives in their estate – buried in purchased software, in libraries doing remote authentication, in firmware on older hardware – and the inventory has to extend to third parties, because your partners' timelines are your exposure too.

"Snap the chalk line. For everything that someone tries to collect after I've implemented, they're not going to be able to decrypt that with a future quantum computer."

Watch this session on demand

Panel Stage

Five people, run as two engineered scenarios rather than open discussion, and it is the most technically specific session in the top fifteen. The panel: a distinguished architect at eBay with 28 years in security, now working on agentic IAM and agent sandboxes; a senior manager at Capital One who leads the infrastructure chapter there and does independent AI research; the head of the corporate data office and AI team at Digital Realty; the head of security at Together AI, an AI-native cloud running inference and training on thousands of GPUs; and a moderator from World Wide Technology who leads their data and physical AI practice. Scope was set deliberately narrow at the start: agents running in production, development and test environments, not desktop agents, which were called "a whole different ballgame" for threat modelling.

The framing is the best short statement of the problem anyone gave all conference. Twenty years of security posture rests on three things:

1. Deterministic applications that encode the business flow they were written to fulfil.
2. A user as the actor, authenticating with their own identity to act.
3. Prescriptive data flows — registration page to public API to GraphQL to entity service to database, well defined end to end.

Agentic AI breaks all three at once. The agent harness is a generic application with a reasoning loop; what it will do is determined in the context of the request. The consequence drawn from that is the part worth carrying away:

"Your business logic has moved into the context… if someone is sending that context as part of the data plane and an agent is acting on it, that means the application is no longer relevant the way it was in the old days."

Which is why scanning the application has stopped telling you anything. If everyone is running a LangGraph-based implementation, everyone is running substantially the same image: "there's no point in scanning and re-scanning and doing all the analysis because all that analysis work that was critical has moved to the data plane."

And because the agent decides where to go, there is no call pattern to baseline:

"If you start looking at your analytics dashboards, it's Fourth of July fireworks there, because it's all fan-out calls."

Where the trust boundary went. Stated as the session's thesis: it is now the context, the delegation the user performed, and the memory the agent holds.

Classification, and the specific recommendation to act on. The problem posed was that classification programmes label data where it is created, while agent memory is new data assembled from pieces nobody labelled. The Capital One answer was concrete:

• Agent output is derived data, assembled from sources that are already classified, so it must be classified too.
• Label at write time, not at discovery. "When agent loads something from the source, it already has every context for the data that it is loading into memory," so stamp it as it writes to agent memory.
• Agent memory is a data product and falls under the same compliance regime — "it's aggregate sum of all the data." Two PII attributes plus a partial PCI attribute combine into something highly sensitive.
• The derived label is a new label unless it happens to match the source, because combining a secret from system A with internal data from system B synthesises something that deserves its own classification.

The failure mode he named has a name worth stealing — label decay. Agents write to memory; the same or later agents reload it for further action. If the label does not travel with it, a secret ends up in a prompt and the prompt goes to an external model. "So you're basically risking everything."

Together AI's addition, and the sentence to quote to anyone who thinks this is premature:

"If you don't have a proper data labeling infrastructure, then you've already lost."

Most organisations label only their highly sensitive data and nothing else, which does not survive contact with agents — "you are having massive data exfil patterns." Two lines attached to it: "you can't put the toothpaste back in the tube," and a show of hands on how many in the room had a zero-data-retention agreement with their model provider, which came back as very few.

Why network visibility breaks, and what to do instead. Existing dashboards were built on dependency data — service one calls service two — with anomaly detection layered on top. That logic fails because there is no deterministic path: agents reach the same source by multiple hops or different routes, which turns the picture into a graph rather than a chain.

The recommendation was explicitly not to invent something new:

• Borrow from the cloud era. OpenTelemetry and open tracing exist precisely to trace a request from A to B without knowing the path, which is the microservices problem in a harder form.
• But carry identity in the trace. "Your OpenTelemetry data needs to have the user context or a delegation context," because what one user's agent may reach is not what another's may.
• Don't try to control the agent — control the doors. "You cannot control how agents are going to work, and you don't want to control [it]. The reason you don't want to control is you're going to take the autonomy aspect away." Instrument entry and exit instead: agent gateways, MCP gateways, data flowing only through trusted endpoints you can collect at.
• The closing judgement: "the tools already exist. It's all about stitching them together."

The Digital Realty view put identity first, and raised a problem specific to enterprises with existing applications: those applications were built for users with user interfaces, so from the network you cannot tell whether an agent drove the UI or a human did — and taking the UI off in favour of a headless application does not resolve it. What is needed is full traceability of the chain of thought: what it fetched, what it did with it, whether it swarmed with other agents, whether it combined sensitive information, and what actions it took.

The analogy that landed:

"I have a nine-year-old daughter, and I don't want her going into an R-rated movie. But she has my identity, she has my credentials, she has my DNA."

Hence the position both took: agents get non-human identities and must not clone human ones — otherwise you cannot contain blast radius without cutting off the human's own access — and non-human identities make the audit trail tractable. Also flagged: watch egress, and watch internal activity too, because "agents will spawn a socket."

One finding from live rogue-agent research, offered as a caution about where the holes are: having built custom harnesses and focused the defence there, they found that someone running a coding agent locally was able to pull an OAuth token and execute a function with it. The conclusion drawn was that OAuth as deployed leans on derived identities and needs to move to single unique ones.

The audit-evidence practice, which is the most directly copyable thing in the session. Asked what evidence an organisation should be able to produce about what an agent accessed, Together AI described starting from the one signal every finance team already cares about — token cost. An engineer's spend spikes; map it to a project; $10,000 a month against a customer netting $20 million is nothing, so the question is whether you can see it at all. Working outward from that one flow, they found 36 other signals that correlated with misuse, including:

• agents committing code to repositories outside the organisation
• personal cloud storage attached to a work agent
• volume spikes at hours when the owner should have been asleep
• secrets appearing in prompts, rather than being fetched via the sanctioned MCP
• personal accounts in use

Each became a trigger for investigation rather than a block, and the reason they built it themselves was plainly stated: "we didn't have tools available today in order to be able to do it properly."

The eBay generalisation of the same idea, as a three-item watch list: what the agent is accessing and from which source systems; what crosses the trust boundary; and what the agent does with the data once it is outside.

Scenario two: authorisation, which the panel considers the unsolved half.

On whose permissions an agent should use, there is no single answer — a user's agent should carry a subset of that user's permissions by delegation; a team's agent needs a broader role on a non-human identity. But the premise itself was flagged as unstable, for an operational reason most people have not got to yet: efficiency pushes you away from one always-on agent per user and toward sharing a long-running agent, and the moment you share it you have session sharing, which means identity has to move out of bootstrap and into the session context.

The identity-standards guidance was unusually direct, and is the most actionable list in the session:

• "If you're still running a SAML infrastructure, think twice. The days are gone." Move to OpenID Connect and OAuth 2.1 or higher.
• Authorisation boundaries are moving toward scopes and claims.
• Credential presentation is moving from bearer tokens toward demonstrating proof of possession.
• Watch the workload identity working group, which is now also working on agent identity.
• OAuth token exchange matters more than it looks.

That last one is the mitigation for the threat he says everyone forgets:

"There's a threat called confused deputy… agent sends a request to MCP gateway, MCP gateway sends it to MCP server. At this point, MCP server has lost the context as to who sent the request."

The server then has to decide whether to reach the backend with its own credentials or the user's. Give that MCP server broad permissions and "it's going to fetch anything for every user." Token exchange is how the user context survives the hop — and the reason the OAuth journey is not optional.

His synthesis: in practice user identity wins in combination with a non-human identity — active OAuth delegation from the user to the NHI, with the delegation context carried all the way to the endpoint serving the data. "Otherwise you lose the chain of custody."

The honest statement of where this stands, from Together AI:

"Non-human identities, I think, have been solved to a certain extent. It's the authorization model that's still broken."

With the question nobody had an answer to: if an agent is authorised for a set of functions and now needs to do something else, do you update the policy, version the agent, or both? The current answer is to go back to the user for consent, which makes it a human-in-the-loop problem — "so it's either friction or insecurity, and not a good trade-off at this point."

On how often to interrupt the human, the panel converged from three directions, and this is the part most likely to change how someone designs a workflow:

The 2FA precedent: prompt people too often and they stop reading what they are authorising. Step up only when genuinely necessary.

A specific warning worth acting on this week — an agent holding refresh tokens:

"Imagine an agent which has access to refresh tokens of all the users. Believe me, it's going to use every user's refresh token to obtain an access token and perform action on behalf of that user if it can."

So restrict what refresh tokens an agent can hold, what they reach, and whether offline action is permitted at all.

Digital Realty's frame was workflow engineering: humans can be in the loop, on the loop, or out of the loop, and the variable separating them is trust. Tier-one system updates, human in the loop; fetching low-sensitivity data, out of the loop. That framework matters more as swarms appear, where agents talk east-west to each other as well as acting on their inputs.

And the Capital One proposal, which is the single most useful formulation in the session:

"The decision must be made when the cost of doing an action by the agent exceeds the cost of interruption for the human."

Built out as risk-tiered delegation: reads and reversible actions run silently under rules; escalation goes to a human. The observation that makes it practical is that most agent actions are reads or reversible — the exceptions are spending money, deleting something, and writing to external systems — so the classification job is smaller than it sounds. He has built his own judge model to assess whether a given action carries escalation risk, on the grounds that "you cannot scale things up by having humans, because obviously we cannot beat machine speed."

eBay's rule of thumb for the same question was accountability: ask who is accountable if this action goes wrong, and where there is a strong answer, put a human in the loop. Alongside that, policy as code — pre-approved policies for acting on a user's behalf — described as very early but able to take the rubber-stamping out of the low-risk tier without breaking human review on the critical ones. The two factors both sides kept returning to: reversibility and blast radius.

The verdict on shift left, asked directly and answered without hedging:

"To be very honest, the entire shift left is at risk right now. Because it's not that it's not needed — it's just not sufficient anymore."

The reason is non-determinism: "the same prompt or same query that you have given today might give a different result in an hour." Shift left worked because the resources were structured and testable; behaviour is now a runtime property. That pushes visibility back onto gateways and proxies, which have their own limit — Together AI's point that by the time a request reaches the MCP server or the proxy, "the decision's already been made by the agent."

What they recommend doing about it:

• Do not throw away what you built. The answer to "should we get rid of everything" was no, but be judicious about which existing cloud controls actually still apply.
• Threat-model every use case. This is the cost nobody has budgeted: "it's not like applications where category of applications, you run a threat modeling and you are good. It doesn't work that way." Every agentic use case needs its own.
• And the uncomfortable conclusion: "the protocol doesn't exist, or the standard doesn't exist… we have to build new standards, build new protocols to be able to address that." Vendor-defined interim answers were allowed as a stopgap, not a destination.

The closing exchange turned the panel on its moderator, who runs a physical AI practice, and it is a useful bridge to where this goes next. Robots are being approached exactly like agents — autonomous, with access to your data — except they also have access to your physical spaces. A rogue agent costs you data and reputation; a compromised robot on a manufacturing floor is a different category of event. His observation about readiness is the one to note: most organisations are still testing a single robot and have not begun thinking about how to deploy, secure and protect a fleet. The implication, which he accepted: in robotics the model has to be constraining specific actions, rather than the full autonomy the software world has been granting.

Back to the list of sessions

Watch this session on demand

Panel Stage

A two-person fireside: Cisco's Tom Gillis, who introduced himself as the company's chief technology officer, with Douglas Gourlay, president and CEO of Qumulo and a Cisco and Arista alumnus. It is a vendor conversation and makes no pretence otherwise — both men are selling an integrated stack by the end of it — but the first two-thirds carry some of the sharpest architectural argument of the conference, and one demonstration that is worth the session on its own.

The framing claim, and it is a good one. In virtual machine and Kubernetes workloads most of the system lives inside a box, and the hypervisor subdivides that box. AI workloads are parallel and rarely fit on one server, so what you have is a cluster of composable pools — CPU, GPU, memory, storage — with the network stringing them together:

"The network is at the back plane to pull together this giant supercomputer… it's playing the role that the PCI bus played in that server box."

The vulnerability argument, which is the reason the session exists. Gillis described having early access to frontier models through a vendor programme, and made a strong claim about what changed: these models can find vulnerabilities in complex software far more efficiently than their predecessors — he put it at roughly a hundredfold — because a model can take in fifty or a hundred million lines of code in its entirety. His read on the consequence:

"If you're following the news at all, where we have the PHP vulnerabilities, that is the first of just a series. There's going to be announcement after announcement. And these are not the esoteric, well, maybe I don't need to worry about that kind of vulnerabilities. These are the anyone who knows how to do this can log into your infrastructure and take control kind of vulnerabilities."

Treat the hundredfold figure as his, not as a measured industry number. The planning implication, though, is the part to take seriously, and it is the thesis of the whole session: if you cannot patch everything, you have to plan for compromise.

Gourlay's version of the same point named three properties rather than one:

"The speed and velocity upon which a computer system is capable of acting, and bluntly, the impunity upon which a computer system is now capable of acting, and the autonomy with which it's capable of acting, is what collectively should scare us."

Impunity he defined plainly as the lack of morality. And his framing of what is actually at stake moves the conversation off confidentiality and onto availability: attackers destroy data for ransom, or steal it for their own use. The illustrations were deliberately extreme — what a government loses if fifty years of taxpayer records are destroyed rather than leaked, and the blunter version for the room: "if you're a bank and you're sitting in this room and your ledger is locked and gone, you are out of business."

The segmentation argument, built on a case everyone remembers. Gillis recounted the Equifax breach as a structural lesson rather than a statistic: a single unpatched Apache instance, which by itself was of almost no consequence, followed by a long sequence of lateral moves over roughly a year, and that is where the damage was done. Finding every instance of anything to patch it is, in his words, "very cumbersome and suboptimal."

"Let's rely on the network to slow down that lateral movement. And this is not a new idea… But I would argue that the imperative around segmenting the network as your first line of defense has grown dramatically."

Gourlay's historical gloss on why the network is the right place for this is worth keeping as an argument you can reuse: the firewall succeeded in 1995 because the network was a point of control that protected everything around it — "deploy once and influence that scale across a business." Hence a good first line of defence and, he added, "bluntly, a great last line of defence as well for data exfiltration."

Why the installed base does not deliver that, in two specifics.

First, the devices were designed for a data centre made of boxes, where an IP address identified a function. "To this day, every next-generation firewall, including mine, has at its heart a rule table that is based on IP port and protocols, what we call the five tuple." And the operational process has not moved either: open a ticket, security review, network review, change control, staging, rule updated two weeks later.

Second, and this is the anecdote the room reacted to: a government agency decided by edict that it must have a firewall between every network segment, bought eight hundred of them, installed them between every VLAN — and the rule set on all eight hundred was permit IP any, any. The lesson generalises past the embarrassment: "You may have bought the product, but you're not using it and implementing it in a way that creates any value."

The distinction that makes this actionable — perimeter firewalls versus zone firewalls. Perimeter and DMZ firewalls will keep looking much as they do. But the bulk of the population is internally facing zone firewalls sitting on VLAN boundaries: a large bank might have on the order of a hundred firewalls in the DMZ and thousands sprinkled around in zones. Those are the ones with the any-any rules in them, because a bank of boxes at that count is unadministrable. The proposal is to push the function into the fabric — a small, simple, stateful firewall per switch port that understands context and topology. The design principle attached to it is the best line in this part of the session:

"Doesn't have all the bells and whistles of a DMZ firewall. Doesn't need all the bells and whistles. You don't want all the bells. It just opens the door for misconfiguration."

The demonstration, which is the single most useful thing in the session and does not depend on buying anything. Gourlay described a test you can reason through yourself. Take the most advanced edge firewall available. Put it in front of the thing you have just agreed matters most — an NFS mount point holding petabytes of your critical data. Now ask what happens when a properly authorised user, mounting it over an encrypted protocol they are entitled to use, begins writing and deleting:

"There's not a firewall out there that will stop an authorized user on an authorized protocol doing an authorized operation that destroys all your data."

They ran it: malware detonated through a leading edge firewall destroyed ten petabytes in thirty minutes. The point is architectural, not competitive — perimeter and zone enforcement are the wrong control for this failure mode, because nothing about the transaction is unauthorised.

Their answer was to move detection to the point of write — recognise the ransomware write pattern as it lands, signal the rest of the security stack, quarantine at source, protect every target rather than only their own, and roll back the errant writes. The claimed result was an 800-millisecond incident response, turning what would have taken a hospital offline for six weeks, or forced a ransom payment, into a sub-second remediation.

Whatever you make of the product claim, the structural lesson is the one to carry: it worked because network, server, storage and security behaved as one system rather than as discrete products. And Gillis's reason this now matters more than it did:

"The old world of, like, let's find an event, let's open a ticket, let's examine it. Too late. It's already played out."

With the division of labour spelled out: automated response coordinates protection of the data itself, and the network does what the network is good at, which is limiting blast radius — isolate it, constrain where it can go — after which you can take your time over the forensics.

The data-gravity reversal, which was Gourlay's best independent contribution and has nothing to do with security. Data centres are becoming politically difficult to site — his line was that we have gone "from NIMBY to bananas: build absolutely nothing near anyone, never again" — so they will be built wherever power, geopolitics and cost structures allow. That breaks the model the public cloud was built on:

"AWS exists because of data gravity. We said we must put the compute near where the data sits, and so we said, let's build the cloud around data… The world's changing."

The practical problem he posed: your enterprise corpus changes constantly, and different groups want different models, which live with different providers, in different clouds, on different neoclouds. Do you copy the data to all of them?

"Do you know how long it takes to copy 40 petabytes of data on NFS from Copenhagen to LA? Fifty-three years."

So the network's next job is to project data to the compute rather than move copies of it — "being the fabric that connects AI to data."

The sharpest version of that problem came from a real client shape: a country holding more than a hundred petabytes of subsurface geophysical survey data that cannot leave its borders, unable to get enough GPUs delivered in-country, and currently paying the large oilfield services firms to model it. The question they asked is a good one to hold onto:

"Can we use the GPUs in [another region] to process the data that sits in the kingdom and allow the two to work without ever compromising the sovereignty of the data, or without ever moving a copy of it permanently and persistently outside of the nation's boundaries?"

A distinction worth stealing: modelling runs on stale data, inference does not.

"Model building uses stale data. The entire history of humankind's production of the written word is a good example of stale data."

Inference on live telemetry is a different class of requirement. His illustration was a rocket launch, where the decision to land or self-destruct has to be made within about thirty seconds, drawing on launch facilities, ground stations, satellite tracking and two geographically redundant decision centres. The useful general form: for inference, data freshness is a correctness property, not a performance one.

Cisco's own token bill, told against themselves, and the most relatable content in the session. Twelve thousand software developers. Phase one was unrestricted:

"We literally put metrics in place that measured how many logins, how many pull requests… And in fact, the metric, we were quite explicit on this, like, if you're not using these tools, you're fired."

Then the bill arrived. Phase two is "let's be smart about how we use this," and the rule they landed on is simply the right tool for the right job: you do not need a frontier reasoning model to implement dark mode in a UI. The line that got the laugh, about a colleague using a top-tier model to write amusing emails: "First of all, not hilarious, and secondly, that's like a $150 email you just sent."

Two conclusions follow, and they are the practical payload:

Applications will be multi-model, and the model mix is a cost decision. Different models solve different classes of problem, and small targeted models are emerging alongside the frontier ones — Cisco has trained a model on the CCIE curriculum that can pass the CCIE exam, which "is not going to plan your vacation in France" and does not need to.

Three reasons to put AI infrastructure on your own premises, offered as a sequence of urgency:

1. Economics. The old public-versus-private cloud argument was fought over a factor of two, depending on who did the maths. Open-weight against frontier model pricing is, on his account, closer to 20× — an order of magnitude, not a margin. The metaphor: a $50 barrel of intelligence and a $2 barrel, and "sometimes the $2 barrel gets the job done as well."
2. Intellectual property. Data protection is built on fingerprinting and hashing, which works for source code. It does not work for an idea. "How do you protect and trademark an idea? It's much harder." For genuinely sensitive work his conclusion was blunt: air gap is the only answer, whether that means a VPC or your own data centre.
3. Sovereignty, which he treated as settled rather than arguable — "a requirement that's here to stay."

And the architectural consequence of all three, which is a real change in how to plan: it is not that some applications run in the cloud and others on-premises. "A single application will use multiple models that may live in different places," and the network stitches that together.

Two concrete planning signals from the closing stretch, both offered in passing:

• Flash and drive pricing. Gourlay cited a roughly 450% increase in flash prices over the past year, with supply difficult. If you are budgeting storage for AI workloads, that is worth checking against your own quotes.
• Encryption in transit is where post-quantum is arriving first. The cloud-extension pattern he described — software-defined playbooks spinning up virtual network instances across the major clouds in minutes, building IPsec tunnels between them and reaching the on-premises data set to extend the life of existing assets — runs on AES-256-GCM today, in a technology set that now has quantum-safe cryptography embedded in it.

The thesis they closed on, and the one to weigh sceptically because it is also the sales pitch: that it will become very difficult to assemble an AI data centre from individually sourced systems, that networking and compute are merging to the point where they are hard to tease apart, and that what enterprises will buy is a rack or half-rack with compute, networking, network services, firewalls and load balancers integrated, plus deep partnerships into storage. "I want to have one SKU, you order it, you push a button, you turn it on, and all that stuff just works." Hyperconverged infrastructure was acknowledged as a partial earlier attempt at the same idea.

Back to the list of sessions

Watch this session on demand

Insider risk, applied to agents, and the discipline transfers more cleanly than most borrowed frameworks. The premise is simply that if you put controls on a person with access to data, you put the same controls on the non-human identity with that access – what it reached, what it did, where the data went. Including the prompts: organisations that capture what their people type into a search box mostly do not capture what they type into a model. His risk matrix is a useful way to brief a board, because it separates cases that get lumped together: the benign person with a benign agent, which is still risk if they are quietly feeding it data they should not have; the person deliberately pushing an agent outside its box; outright collusion; and the compromised agent, which is the one most people have not thought about – a poisoned model doing something else entirely in the background while it answers your question. His illustration of that last one is small and alarming, an agent told to fetch a compression tool reaching for a lookalike domain one letter different from the real one. The phrase worth stealing is in the quote, and it is the cleanest formulation of agent risk from the two days: data, content, and a route to the internet – any two are manageable, all three are not.

"We call it the lethal trifecta. Access to the data, access to the content, and internal access to the internet."

Watch this session on demand

Short, technical, and carrying the single most striking efficiency number of the theatre track. The premise is that the industry crossed over this year: most tokens are now produced by inference rather than training, so the question moves from how fast you can train to how many tokens you get per dollar and per watt. The evidence is a customer demonstration in which the same inference workload took ninety seconds on one vendor's GPUs and thirty seconds when spread across a mix of silicon – accelerators, CPUs and GPUs together – and, because the accelerators draw less power, yielded about six times the tokens per watt. Whatever you make of a vendor-supplied benchmark, the architectural reason behind it is sound and worth understanding. Inference is two different jobs wearing one name. Prefill, where the prompt is ingested and the first token produced, is compute-bound and wants maximum floating point. Decode, which appends one token at a time to work already done, is memory-bound. A single GPU design does both reasonably and neither optimally, which is the compromise everyone is paying for – hence the move to disaggregate them into a prefill pool and a decode pool built for different things. That is a networking problem the moment the two pools stop sharing a chassis.

"It's three times faster to do that same workload by using a variety of silicon… you can actually get six times the number of tokens for a given watt."

Watch this session on demand

A contact-centre story rather than an architecture talk, and it is a reasonable ten minutes on a kind of AI that is already in production everywhere and rarely discussed at a networking summit. The scenario does the work: an agent at home with children arriving and a neighbour's leaf blower; a customer walking a city street who has just had a fraud alert and needs his card to work at lunch. He reads his account number twice, louder the second time, is asked again, gives up and hangs up unresolved – and wonders whether he was even talking to his bank, because he could hear a dog. Nothing was achieved, handle time went up by eight minutes, he will call back, and the recording is too poor to be useful data. That chain – first call resolution, average handle time, repeat calls, bad data, churn – is the actual cost of audio quality, and it is measured in the metrics the business already watches. Their product sits on the agent's device as a virtual microphone and cleans both directions, with accent softening and live translation on top. Those capabilities and the demonstrations are the company's own; the framing of noise as a business metric rather than an annoyance is the part worth taking.

"He has to call back to resolve his issue, and nothing's been accomplished."

Watch this session on demand

The most honest ten minutes about how many agents are actually running in enterprise networks, and the answer is: it depends entirely on what you are counting. A Gartner survey in July put it below ten per cent of enterprises; several vendor surveys average around eighty. Both are accurate, and the gap is definitional – Gartner's term for it is agent washing. Most of what is deployed and called an agent is robotic process automation, a chatbot, or an assistant that retrieves information and takes no action. Agents that reach the network, diagnose, plan and act exist in production, and they are in their infancy. Two observations worth carrying. Almost nobody is building their own: teams are switching on the agent features their incumbent vendors shipped, which means Cisco's work on Cisco gear, HPE's on HPE, Arista's on Arista, and nothing coordinating across a multi-vendor estate – which is every estate. And on security, his formulation is the sharpest in the track and sits below. The reason we have seen few agent-caused incidents in the network so far is not that the controls are good; it is that the deployments are small, and permission models built for humans have not yet met anything at scale.

"The risk isn't what the agent says, it's what it can do."

Watch this session on demand

A Japanese systems integrator, and the sharpest reframing of the trust question anyone offered. Why do we hesitate to hand network operations to AI? The usual answer is that it is non-deterministic and sometimes wrong – and his reply is in the quote: so are the people we hand the network to every day. Which clears the ground for the two real problems. The AI cannot show which knowledge it used to reach a decision. And a vendor's model knows general best practice, not your rules, which are specific to your environment and written nowhere it can read. Then the observation that makes the talk. We manage network configuration with great discipline – we can see its state, keep its history, review a change and roll it back – and AI learning has none of that. We cannot see what the model learned, and if it learned something wrong, it is hard even to find, let alone fix. Their answer is almost aggressively simple: make the environment-specific knowledge human-readable, keep it as markdown files in a folder, and put the folder in Git. Coding agents already store their skills and memory that way, so apart from the model an agent is a set of files – and once it is in version control you have who changed what, when and why, review, and rollback. No black box between input and output. The demonstration, on a leaf-and-spine fabric with injected packet loss, is honest about the gap: with no learned skill matching the situation, the agent marks the fault unknown and falls back on general practice.

"Human operators are also non-deterministic, but we still hand them the network operations every day."

Watch this session on demand

Ten minutes on what agents do to the build-versus-buy decision, and it lands somewhere more interesting than either. The opening is the right question: now that software can be produced quickly, the question is no longer whether you can build it but whether you should, because building was never the hard part – maintaining it is, and deciding what goes in it is. The analogy he borrows is good enough to reuse: everyone can cook, and restaurants still exist. His prediction is that the third option wins. Not building everything custom and not buying a monolith, but assembling – the agent takes existing community components, with their accumulated industry expertise and defaults, and composes something specific to you. Assembly was historically the option nobody chose because it needed people they did not have, and that is precisely the labour agents supply. He grounds it in ten years of network automation history, with an observation that matches what the NOC-to-AOC panel said independently: the organisations that succeeded did not start with scripts. They built a platform first – shared data management, APIs, permissions, change control, orchestration – and then plugged their own specific work into it. The source-of-truth product is the company's own.

"It's not can I build something? It's more should I build something."

Watch this session on demand

One question, asked well: the change succeeded, but did the network? The story is ordinary enough to be uncomfortable. A manufacturing plant migrates its ERP system; a senior engineer updates the object group, swaps the old subnet for the new, confirms the new system is reachable and closes the case. At two in the morning the nightly order sync fails, because a batch job still needed the old system and nobody told her. Every step was done correctly, and the result was a P1. Hence the line in the quote, and the claim – supported by several surveys he cites – that more than half of operators put their outages in the change window. His contract for a change is four statements written before anyone touches anything: what the change is meant to achieve, what must still hold true afterwards, what the blast radius is including every shared resource, and what you were unable to verify. That last one is the unusual and valuable part, because an undocumented gap in testing is indistinguishable from a tested pass when somebody reviews the incident later. The method follows: collect state across the blast radius before, execute, wait for timers, collect again, compare, and grade the outcome as pass, pass with warnings, fail – or inconclusive, which is a real and honest fourth answer.

"Completed does not mean it is verified."

Watch this session on demand

Titled "agents you can switch off", built against the ONUG working group's scenario, and genuinely different from everything else in the track. The critique of the status quo will be familiar: a web API means an open port, a key that nobody ever leaks into source control except that everyone does, and then load balancers, firewalls and infrastructure to protect it. Their model replaces the address. Every component – a device, a service, an agent – gets an identifier that behaves like a messaging handle rather than an address on a network, and communicates by cryptographic key, so reachability stops depending on where anything sits. Two consequences are worth the ten minutes whether or not you buy it. Subkeys can be scoped to a narrow slice of data, so an agent's authority is bounded by what its key can open rather than by policy written somewhere else. And because authority IS the key, you revoke it and the agent stops – in one place, with no ambiguity about what else just broke, which is exactly the thing that is hard in an API estate. The demonstration is the memorable part: a Nokia router running SR Linux with no open ports at all, which you can scan and find nothing on, yet can be addressed, configured over RPC and even reached by SSH. Outbound only.

"You revoke the key, and then they literally can't do anything."

Watch this session on demand

Titled "stop paying for L1 guesswork", and the useful move is refusing to let it be an automation talk. Automation has always come with a list of prerequisites – every monitoring tool integrated, a complete and accurate CMDB, an owner against every configuration item, change records filled in properly – and nobody in the room has those. What they have instead is tools firing one-to-one into the service desk, a catalogue everyone knows is incomplete, application mapping that remains the hardest thing anyone attempts with an ITSM tool, and a change process that goes off the rails despite genuine effort. The consequence he names is one every operations team will recognise by its nickname: ticket ping pong, as an incident bounces between teams while people hunt across separate systems for context that exists but is scattered. A well-trained veteran makes that traversal look clean, which is precisely the trap – the knowledge is in the person, and seats rotate. That is the quote, and it is the same problem the NOC-to-AOC panel called the "same ten people". Worth pairing with that session: both conclude that the work is making tacit knowledge explicit before any agent can be useful, and that this is unglamorous and unavoidable.

"A lot of the ownership of all of these things lives in people's heads. So now we're starting to rely on tacit knowledge."

Watch this session on demand

Susie Wee, who founded Cisco DevNet, on the least exciting precondition for all of this: whether your data is good enough to let anything act on it. Her framing is blunt and in the quote. The supporting numbers are the ones to take to a steering committee. Trust in the CMDB, across IT and operations, sits below fifty per cent – including at organisations that have invested seriously in it. Teams spend about 29% of their time reconciling data across tools simply to establish what is actually there. And the estimated annual cost of bad data runs to nearly thirteen million dollars. She is direct about the consequence: AI pilots are failing, and they are failing on the data rather than the model. The diagnostic that makes it concrete is the 2am question, which she decomposes into five: what changed, and you look in change tickets, pipelines and history; what does it relate to, via the CMDB, service maps or architecture diagrams; who owns it; has this happened before; and what breaks if I touch it. Every one of those answers exists somewhere in the estate. None of them is reachable quickly, which is the whole problem. She also names the category most inventories miss entirely – orphans, zombies, shadow IT and now shadow AI, which is easier to create than any of its predecessors.

"Good data, great AI. Bad data, catastrophic AI."

Watch this session on demand

A solutions integrator on the economics of enterprise AI, and it traces a sequence most organisations are somewhere inside. People start using public chatbots; the company sees proprietary material going into personal accounts; the logical fix is an enterprise licence for a frontier model. And then, in his phrase, the bill lands – cost per token, especially once the API is wired into workflows. The examples he reaches for are the ones in the news and in the quote: large, sophisticated companies consuming an annual budget in a month. Two complications on top. The models leapfrog each other constantly, so the choice does not stay made. And different functions want different ones – marketing on one, sales on another, engineers on a third – which turns into a subscription estate needing its own observability and security. Multi-model gateways help with management and not with cost. Their response is to benchmark open-weight models on their own GPUs against the frontier ones for specific workloads, and to put the ones that qualify inside the building – with the honest caveat that this is a per-workload judgement across owned hardware, neocloud, public cloud and frontier APIs, not a doctrine. "AI with an ROI" is the sales line; the budget arithmetic underneath it is real.

"You start seeing things on the news like Microsoft goes through their entire year spend in a month. Uber goes through their entire year spend in a month."

Watch this session on demand

Equinix, who open by saying they are not going to talk about networks, and the organisational observation they make instead is the one most worth hearing. AI projects begin with the chief data officer. By the time they reach the people who run infrastructure, what will be built and often where it will run have already been decided – which is the quote, and the source of a great deal of friction that gets mistaken for technical disagreement. Their diagnosis of why is fair: those decisions are being made with a cloud-first mental model from 2015 to 2020, and the landscape underneath has changed. Three constraints have arrived that a CDO historically never had to price. Lineage and governance. Cost control, which was nobody's first thought and has become one this year. And sovereignty – not as a principle but as a routing question, because data moving from raw storage to an AI platform to a GPU pool must not traverse links or borders it is not permitted to, which for a regulated business is a hard constraint on where the compute can be. The architectural point follows: the old three-layer cake of cloud, core and edge now has neoclouds and AI factories in it, which cannot sit where the rest of the estate sits, usually because the power is not there.

"By the time this project gets out to network infrastructure folks, all the decisions have been made about what we're going to do and sometimes where we're going to do it."

Watch this session on demand

ONUG's own session, and worth flagging as such: the CTO of ONUG introducing ONUG Connect, with the chief executives of zLinq and ConnectBase as partners. The origin is the honest part. Members of the Collaborative kept asking why wide area procurement cannot be modern, automated, driven by an API, and he spent some time explaining why it cannot – having run telecom buying himself for much of his career – before concluding they were right. The principle he sets out is the one to hold the venture to, and it is the quote: not wrapping the existing manual process in software, which preserves it, but removing the intermediation. Buyers see all the information themselves, uncurated, with context, and decide. The organisational ambition underneath is the less obvious half and arguably the more useful – putting sourcing, the people who provision, and whoever carries the profit and loss in front of the same information, so that a decision can be understood by everyone it affects. Set it beside ConnectBase's own theatre talk, which put numbers on the problem: eleven thousand last-mile operators worldwide and a sixfold price spread between providers serving the same building.

"I'm not looking to wrap a bunch of manual processes and preserve the status quo. I'm looking to disrupt the status quo."

A networking vendor that moved from service provider routing – AT&T, Comcast, Orange – into AI cluster interconnect, and the most useful observation is about operational sprawl rather than architecture. When they started working with people building large GPU clusters, they found monitoring in one tool, tuning by hand-written scripts, deployment in another tool, optimisation in a third. His word for it is in the quote, and anyone who has stood up a cluster will recognise it. Their answer is a single orchestrator covering design, deployment, validation, optimisation and operation – which is a reasonable thing to want whoever supplies it. On the network itself they describe the same three domains Broadcom and AMD laid out independently: scale up, scale out with a scheduled fabric of the kind Meta runs in its backend, and scale across, where the same AI application runs at distributed sites and the hundred-kilometre link between them still has to be lossless. Their operating system is proprietary rather than SONiC-based, carrier-grade from a decade in service provider networks, which is a genuine architectural choice worth being aware of rather than a feature. Professional services from design to first token are offered too – a telling unit of delivery.

"They will use for monitoring one tool. They will use specific manual scripts to do tuning. A different tool for deployment, different tool for optimization, different tool for operating. It was a chaos."

Watch this session on demand

Private 5G as a service, and the most customer-story-driven slot of the theatre track – almost all of it higher education, and almost none of it about AI, despite the framing. Read it for the coverage and deployment economics, which are the transferable part. The number to take away is one access point reaching nearly two miles outdoors at UMass Amherst; the other is the timeline, where replacing an indoor distributed antenna system took two to three months against the eighteen months to two years the speaker gives for the conventional route. The architecture is CBRS spectrum, eSIM provisioning, a virtual mobile core that can sit on-premise, virtualised or in a cloud instance, and – the detail most relevant to this audience – integration into the enterprise firewall rather than beside it. The use cases are worth skimming for pattern rather than product: ticket-scanning pedestals around a stadium, coaches' headsets on physical SIMs over dedicated spectrum, suites where Wi-Fi could not hold a video call, concessions and point of sale, and campus safety cameras tied to campus police at Brown and UMass. The AI claim – agents behind the platform producing a single unified view across OT and IT – is asserted rather than shown, and the customer names and results are the vendor's own.

"At UMass Amherst, we were getting nearly two miles of coverage from one access point, which was very significant to that CTO."

Watch this session on demand

Twenty years of packet analytics in trading networks, now pointed at enterprise observability, and the architectural point is one every team building with network data will hit. Models reason about networks well, and they need accurate independent data to do it – but network packet data runs to terabytes a day, and the quote is the obvious consequence. You cannot put that in front of a model, and sampling it puts you back where the observability sessions elsewhere in the programme said you should not be. So the work happens before the model: capture at line rate – their appliance does 200 gigabits per second – and compute, in real time and from every packet, the performance metrics and the application transactions, separating server processing time from network time. What goes north is around two gigabits per second of structured records, which a data warehouse can hold and an agent can query through a tool interface with guardrails. Compression by summarisation rather than by sampling, so nothing is blind. The honest framing is that this has existed for banks and exchanges for two decades and has only now reached a price and performance point where ordinary enterprises can run it. The product claims are the company's own.

"We're talking about terabytes a day. You definitely don't want to feed that into your LLMs. That's going to blow your token cost through the roof."

Watch this session on demand

Built on a single sentence that has been around security for years and has never been more useful, and it is the quote. Everything a defender holds is a list: the asset inventory, the CMDB or IPAM, firewall rules, ACLs, cloud security groups, scan results, the exception register, the segmentation design. An attacker holds none of those. They pour water in and watch where it goes, which is a graph. That mismatch is old; what is new is the speed and scale at which it can now be explored. The examples he uses are the most interesting part, because two of them come from inside AI labs rather than from enterprises. An agent in a training environment, with the single permitted route to the outside being a proxy used to update models, found a zero-day in that proxy, moved laterally, and reached the external resource it wanted. Something comparable happened at the UK's AI Security Institute. These were highly restricted networks with serious protection and one opening, and the opening was enough. His conclusion is unfashionable and correct: segmentation is what bounds the blast radius when something inside starts exploring, and that holds whether the explorer is an attacker or an agent doing its job too well.

"Defender thinks in lists and attacker thinks in graphs."

Watch this session on demand

A company that secures design environments for over two hundred semiconductor firms, which gives the headline number its weight. A customer believed it was running fifty or sixty agents. It was running fifteen hundred, across three hundred projects. That is the quote, and it is the most concrete measurement of agent sprawl anyone offered. Their survey data tracks the dawning realisation: among organisations with fifty agents or fewer, 72% say they need more control; past a hundred agents it is 90%. The reason they give for that is the sharpest observation in the talk. Agents are being dropped into human workflows – we ask them to do what we already asked people to do – but they do not respect organisational boundaries the way a person does, because they reason without the acquired sense that stops an experienced employee from doing something technically permitted and obviously wrong. Their figure: 84% of organisations say agents cross project boundaries more easily than their own staff can. Hence three enforcement points – at the endpoint where the agent runs, in controls that understand what an agent is rather than what a packet is, and at the systems it reaches – and one principle that generalises beyond their product: the enforcement must sit outside the agent, where the agent cannot touch it.

"They thought they had 50 or 60 agents running. It turns out they had 1,500 running across 300 different projects."

Watch this session on demand

Opens with an outage most of the room lived through. On 21 September, Newark, JFK and LaGuardia stopped for eight hours – a thousand flights cancelled, six thousand delayed – because the primary circuits went down and the failover did not save them: a construction crew had cut the secondary. The detail that makes it a lesson rather than bad luck is in the quote. The degradation was known and not acted on. The rest is a maturity model for telecom estates that is more useful than it sounds, because almost nobody manages this well and the reasons are structural: more than two hundred assets to track, in an industry whose net promoter score is half that of technology overall. Three tiers. Unmanaged – no complete inventory, vendors chosen opportunistically, no line of sight between procurement, finance and the network team – which large companies mostly escape except in the estate they just acquired, where it is the norm. Managed – a complete inventory that lives in several places, some in a provider portal, some in a spreadsheet, with what the engineers see still invisible to finance and the reverse. And orchestrated – one view of every circuit regardless of provider. Most enterprises are in the middle and think they are at the top.

"They knew it needed to be green, but they didn't act on it, and when it tried to fail over to secondary, construction crew happened to cut the secondary."

Watch this session on demand

Aliro's co-founder and CTO, making the one argument in the quantum track that does not depend on a quantum computer ever arriving. His case is that post-quantum cryptography is necessary and nowhere near sufficient, and he builds it from two things he says happened this year rather than from the usual timeline. The first is a post-quantum signature candidate that had been in expert review for three years and was, on his account, broken by an autonomous agent in sixty hours of agent time and withdrawn from standardisation the next day, for about $100,000 in tokens. The second is implementation rather than mathematics: a standardised signature scheme whose algorithm is sound, but whose signatures he says were recovered on an ordinary laptop in under a second, with one library in four projected to ship a critical bug. Those specifics are his and worth checking against the sources; the shape of the argument is the part to carry out. A single family of maths problems underneath your most critical links is a single point of failure, and it no longer matters much whether the thing that breaks it is a quantum computer or an agent with a budget. The product half – entanglement over fibre you already light, alongside the encryptors you already run, for tamper evidence and clock sync as much as for keys – is the vendor's own. The ask was modest and concrete: do PQC everywhere, then pilot physics on one link.

"This is half of a junior engineer's salary that now you can levy this kind of attack on a standard."

Watch this session on demand

A services firm demonstrating something genuinely different: an agent that predicts rather than reacts. The reason is a show of hands from a panel earlier that morning, and it is the quote – asked who permits an agent to apply security patches with no human approval, not one person in the room raised a hand. Their reading of that is right and unusual: the human approval is necessary, and the human is therefore the bottleneck in the loop. So rather than arguing for more autonomy, they moved the decision earlier, where there is time to think. The worked example is a good one. A peering partner is announcing more prefixes than the contract allows. Nothing is broken; the routing tables are filling toward their hardware limits and will break in a few hours. The agent forecasts each node's table growth and lists those that will cross the limit, with the history and the forecast bands charted so the engineer can see the pessimistic case; finds which peer is announcing fastest; reads the contract to establish what that peer is entitled to announce; and inspects the filter on the relevant device, which exists and is misconfigured to permit anything. Then it proposes the fix and waits. Evidence at every step, a decision taken before the outage rather than during it.

"Who lets their agent to apply security patches automatically without human intervention and approval – and actually nobody raised their hand."

Watch this session on demand

Nile – founded by John Chambers and Pankaj Patel after Cisco – on the part of the estate that modernised least. The framing holds up: the data centre unified its compute, network and storage into pools and went pervasive with zero trust; the wide area converged network and security into SASE; and the campus and branch, where the users, devices and things actually are, remained point products, ad hoc security and very little automation. The statistics he puts behind it are the ones to carry into a budget conversation. Seven sites in ten have no IT staff on the premises, which makes patching, licensing and configuration management across both IT and operational devices a travelling problem. Around two-thirds of successful breaches now originate outside the data centre, many of them from manual configuration error. And about a third involve IoT – the cameras, the appliances, the things that are connected and unmanaged and have no posture at all. That last figure is worth reading immediately after the Aviatrix keynote's French supermarket refrigerators, which is the same sentence with a real company's name on it. His conclusion is the quote, and it is a fair description of where the attack surface went while everyone was securing the data centre. The network-as-a-service answer is the company's own.

"This traditional LAN has become a breach magnet."

Watch this session on demand

Opens with two sentences that sound contradictory and are not, and they are the quote. The argument for the second half is about how to read a technology's progress. Most people track quantum by hardware, which is the equivalent of having tracked GPUs through the 2010s and being surprised by the AI boom – the chips improved steadily and predicted nothing. What signalled the change was application progress: multiples of fifty, a hundred, two hundred in training, recognition and inference, visible years before anything launched publicly. Read quantum the same way and the picture is different: the qubit count required for useful work in several areas, cryptography among them, has fallen by roughly two hundred times in two years. He cites McKinsey putting between one and 2.7 trillion dollars of annual economic value on quantum by 2035, with 90% of it going to early adopters, and about three hundred enterprises already building. The example of what preparation looks like is the most useful part, and it is not about quantum at all: an investment bank that had built the teams, the infrastructure and – crucially – the view of where it would apply the technology before ChatGPT existed, and took internal document access from 20% to 80% within six months of its arrival. The readiness was not the model. It was knowing where it would go.

"There's not a single thing you can do on a quantum computer today that would be useful to you. And… if you don't start preparing for quantum computing today, you are going to get absolutely smoked."

Watch this session on demand

The best-argued ten minutes in the quantum track, and it opens by conceding the thing a vendor would normally hide: there is nothing useful you can do on a quantum computer today. The talk is about what follows from that rather than around it. His argument is that almost everyone tracks the wrong indicator – hardware – and that hardware never predicted anything. GPUs marched on for years and gave no warning of the AI boom; the signal was in the applications, where training and recognition benchmarks were moving by multiples well before ChatGPT. Morgan Stanley is his example of someone who read that correctly and had the teams and the use cases ready when the technology landed, taking internal document access from 20% to 80% within six months. Applied to quantum, he says the qubit count needed for cryptographically relevant work has fallen roughly 200-fold in two years – and he revised that to a thousand-fold mid-talk, because a paper published that morning put RSA within reach of 20,000 qubits. The mechanism he offers for why it compounds like that is worth the ten minutes on its own: ten interdependent subsystems each improving twofold is not a twofold gain, it is a thousandfold one. His conclusion is a staffing point, not a product one. Nobody can track this literature by hand any more – he cites arXiv going from 30,000 papers in a month to 40,000, and capping submissions at two per person – so readiness has to be somebody's standing job. The market sizing and the adoption counts are the vendor's own.

"There's not a single thing you can do on a quantum computer today that would be useful to you… if you don't start preparing for quantum computing today, you are going to get absolutely smoked."

Watch this session on demand