A quarter of the talks at AGNTCon +MCPCon Europe were about security. Not one said the fix was a better prompt

Hey 👋

Special issue. No news roundup this week.

I spent Thursday and Friday at AGNTCon + MCPCon Europe, at the RAI in Amsterdam, and I spoke on the Thursday afternoon. This issue is what two days of it looked like from the floor: what the program says about where agent security is actually going, and an honest account of how my own talk went.

The protocol half of the event, meaning MCP dropping sessions, the OAuth changes and WebMCP, needs its own deep dive with the schema diffs in it. That is next Saturday's issue. This one is about the conference.

Five rooms ran in parallel for two days. Ninety-one talks, keynotes, panels and workshops, by my count off the published program, not counting breaks, sponsor demos and the lunch table topics. Nobody saw more than a fifth of it, including the people who were there both days.

So I did what I would do with any other pile of documents: I counted it. Twenty-four of the 91 sessions were about security, identity, authorization, or governance in the sense of controls you can test on a running system rather than policies you file. That is a bit over a quarter of the program, at a conference that does not call itself a security conference.

Eight were squarely about three related questions: which agent is acting, how it got permission to act on someone's behalf, and who can prove afterwards what it did.

Nine if you count CHAP, Brightbeam AI's protocol for making human approvals, overrides and handoffs repayable instead of leaving them in chat logs. Spec, paper and code are public, so you can check that one yourself. The classification is mine, made from titles and abstracts, so argue with it if you like; every session above links to its own abstract.

Two things stand out. Six of those eight ran on the Friday, and organizers do not give a whole day to a theme they think is niche. And three security sessions, two of them from the list above, were scheduled against each other at 15:00 on Friday, so attending one meant missing the other two. There were more security talks than the grid had room for.

Across those 24 sessions, not one proposed control was "write a better system prompt". Not one. I did not sit in all 24, so read that as the abstracts plus the rooms I was in, but the pattern is consistent enough that I will defend it.

What people proposed instead was infrastructure. Liran Tal of Snyk put it most bluntly: rules and /security-review prompts "aren't enough: they're costly, brittle, and non-deterministic. Run them three times, get three answers." Sheng Liang's keynote made the same argument one layer up: MCP gateways can intercept and filter tool calls, "but that alone is not enough," so you also need visibility into agent activity, consistent policy enforcement and centralised control.

Juan Antonio Osorio ran Claude Code and Codex inside hardware-isolated microVMs that boot in under a second, on libkrun and KVM, then added one layer at a time on stage: a copy-on-write snapshot of the workspace, so every file the agent touched had to pass a review gate; secret exclusions the agent cannot override; an egress firewall that filters by domain name; and an MCP proxy that checks each tool call against a Cedar policy. All Apache-2.0, and his closing line is the one to keep: isolation is the floor, not the ceiling. Siemens' Seshu Tolety argued that governance should be written as properties you can test against a running deployment. Do that, and the EU AI Act, ISO/IEC 42001 and GDPR mappings fall out at the end instead of being where you start. Agent-Smith, Glenn ten Cate and Jorge Carvalho's open-source autonomous pentesting agent, runs in ephemeral Docker sandboxes with server-side controls on cost, execution time and tool calls rather than asking the model to be careful.

The cleanest test method of the two days came from Roy Belio of Red Hat, and it deserves a wider audience. Start with the problem he solved. When you attack your own agent, a safety-trained model often just refuses, and the attack stops there. You cannot tell whether your infrastructure blocked it or the model simply declined. So he took the model out of the equation: he ran an abliterated Qwen3.5, meaning one with its refusal behaviour stripped out, which cooperates with every attack it is handed. Then he ran custom probes in garak, the open-source LLM vulnerability scanner, against an OpenClaw agent on OpenShift, adding one tier of hardening at a time. Putting the agent in a sandbox stopped credential theft completely. A Kubernetes NetworkPolicy stopped it escalating across the cluster. The prompt injection classifier caught the attacks that hid their payload in encodings. Three of his four attack categories were fully blocked by the second tier.

Run it that way and you find out whether your infrastructure stops an attack, rather than whether the model felt like declining that day. If you are writing agent security tests this quarter, steal the design.

The fourth category did not stop. It gets its own section below.

Every control presented in Amsterdam that anyone claimed worked was outside the model. I have been making that argument in this newsletter for months from incident reports. It was pleasant, and slightly disorienting, to watch a two-day program arrive at it independently.

Christian Posta framed it in the four questions enterprises will actually ask: who is this agent, what is it allowed to do, what has it done, and can we revoke its authority. A year ago a talk with that title would have ended in an open question.

This year Zalando answered it with code. Magnus Jungsbluth and Jan Brennenstuhl described the identity broker they built and open sourced as part of their agent platform. One service issues the credentials, keeps track of who authorised whom when an agent calls an application that calls another one, works across both third-party and in-house applications, integrates with the CNCF project agentgateway, and keeps authentication and authorization code out of individual agents and MCP servers entirely. Their framing was economies of scale, borrowed from scaling an enterprise to thousands of microservices: push it into the infrastructure, because you are not going to solve it once per agent. Tool approvals and human-in-the-loop get enforced centrally, so neither agent authors nor MCP authors have to build anything. That is delegated agent identity running in production at real scale, not a proposal on a slide.

The enterprise plumbing moved too. ID-JAG, the Identity Assertion JWT Authorization Grant, is the mechanism behind MCP's Enterprise-Managed Authorization, which went stable on 18 June 2026. In plain terms: your company's identity provider hands the agent a short-lived ticket for one named service, so an administrator grants and revokes access in one console instead of every employee clicking through a consent screen for every tool. Three of the people who built it gave a session on it, and their framing of the problem was the honest one: per-user, per-service consent does not scale to thousands of employees, so the decision has to move into the identity provider. The missing piece they named themselves is that SaaS authorization servers have to support the flow first.

And Takashi Norimatsu of Hitachi, a Keycloak maintainer, did the least glamorous and most useful thing on the program: he read the spec carefully enough to find the seams. Two of them. Elicitation, the flow where a server pauses to ask the user a question mid-request, has a URL mode in which the person who answers can end up being someone other than the person who started the request. And exchanging a token between two domains can leak information and let a token be used fraudulently. His point about why this is hard to detect is the kind of detail that only comes from doing the work: you have two tokens from two domains, and the same human normally has a different identifier in each, so you cannot spot the swap by checking whether the two identifiers match.

Belio's fourth attack category is the most useful thing I heard in two days.

Memory poisoning survived every tier of hardening. These probes instruct the agent to write the attacker's content into its own memory, the notes it keeps and reads back on later runs. They kept succeeding through sandbox isolation, NetworkPolicy and the injection classifier alike, because none of those controls sit between an agent and its own memory. OWASP added this as ASI06, Memory and Context Poisoning, to its 2026 Top 10 for Agentic Applications, and in his words, no deployed control addresses it today. It is a measured result with a probe suite behind it rather than a prediction, and it is the one place where the infrastructure answer currently runs out.

The consent gap is the other open front, though that one at least has a proposal. Andrew Bud's framing is worth borrowing wholesale. An agent turns up at a bank or a shop, the relying party in the jargon, holding valid tokens, a passkey, an inherited session and legitimate tool credentials. Every credential checks out. But its instructions have been rewritten by a prompt injection, so the action it is performing is not the one the human wanted. As the abstract puts it, "whilst the request is authenticated, human consent to the means taken is not." For the relying party that means the customer can later deny having asked for it and the site has nothing to show otherwise, at exactly the point where money moves and actions cannot be undone.

Why it is hard: any evidence the agent or its device produces comes from inside the system the attacker already controls. If the attacker shaped the instructions, the attacker can shape the proof. So before a high-risk action runs, the relying party needs evidence from outside that system, which the agent cannot manufacture. Exogenous, out-of-band, in the title's terms. He presented a decentralised, open-source relying-party pattern for it that composes with OAuth, MCP and passkeys, and that does not require the agent's operator to have onboarded to anything.

Provenance has proposals too, and they are further along than I expected. Ola Hungerford is standardising two complementary efforts in the MCP community. Interceptors are hooks that run at fixed points in clients, servers and gateways and behave the same way every time. The other is a convention for serving Skills over MCP, with a gateway that records centrally who wrote what and a hook in the client that credits the author whenever a Skill runs.

So the scoreboard, in plain terms. Identity: solved and shipping. Consent and provenance: patterns exist, nothing is deployed at scale. Memory poisoning: nothing at all. Put that next to the attribution test from issue #26 and the shape repeats. We can say who the agent is. We still cannot prove what it was asked to do, by whom, or that the record is worth anything in a dispute.

The governance note, and the one with something to do at the end of it.

Manik Surtani, CTO of the Agentic AI Foundation, used his Friday keynote, called Catch Them Early, to say the foundation had inherited the entry bar of the CNCF, the foundation that hosts Kubernetes, without inheriting the conditions that made that bar reasonable: a bar designed for a mature industry, applied to a field just over a year old. The only door open admitted work that had already won, while the projects most in need of a neutral home were turned away, in his words, "at exactly the moment governance is cheap to install and expensive to retrofit."

The new Sandbox phase is the fix. It asks for a working implementation, a named active maintainer, and either early external interest or a credible technical thesis. It gives you, in the foundation's own words, "a home and a neutral flag, nothing more": infrastructure, no funding, no marketing. Growth is the real gate, and it is three conditions at once: production use by two unaffiliated organisations, commits from two or more organisations over six months, and a written plan accepted by a technical committee sponsor. Six month checkpoint, twelve months to apply, archival discussion if you miss it.

The part I respect is that they made it falsifiable. "We will publish three counters at every annual review: acceptances, graduations, archivals." And: if the archival counter is still zero in two years, that is a signal they are being too conservative. Hold them to it, because most foundations never publish the denominator.

The foundation hosts six projects today: MCP, A2A, goose, AGENTS.md, agentgateway and Agent Router. It runs eight working groups, two of which are Identity & Trust and Security & Privacy, and both are open to anyone, with no membership and no paperwork.

If you maintain an agentic security tool and have been waiting until it looks impressive enough, the bar moved specifically so that you would not wait.

I spoke on Thursday at 16:20 in the Emerald Room, against Nokia's agent control plane talk and a 95-minute governance workshop, which is a slot that teaches you humility about audience size. The deck and the companion notes are up: What a Year of Breaking MCP Tells Builders →

One sentence carried the talk: every trust check I looked at compared one piece of text to another piece of text that nobody had issued, signed or tied to an identity. Three findings, three servers, and the same four questions each time. What did the operator think was being checked, what was actually checked, what did the caller get out of it, and who ended up in control?

The session. I made up a session identifier, and Grafana MCP accepted it and went to work with its configured service account. That same server takes the address of the Grafana it should talk to from a caller-supplied X-Grafana-URL header, with no list of allowed destinations, so I pointed it at the cloud metadata endpoint, the internal address that hands out the machine's credentials.

The network. A GitLab MCP server used a personal access token to authenticate itself to GitLab, and checked nothing at all on the way in. It listened on 0.0.0.0 and accepted requests from any origin, so any web page the operator happens to visit can call all 86 of its tools.

The approval. Four independent vendors shipped code that ran before the dialog asking the user whether to trust the server had appeared. All four within one year.

Three controls, which is the whole takeaway and short enough to act on. Check who published a server before you look at what is inside it. Authenticate the caller coming in as a separate job from the credential you use going out. And keep a snapshot of every tool definition you were given, compare it on each run, and refuse to run when one has changed.

The part I am most glad I did was cut a finding. I had planned to tell the room that more capable models are easier to poison. Going back through the 2026 data, it does not hold up cleanly. Two benchmarks support it, MCPTox and Raccoon. Three results complicate it: Wharton GAIL's 40,000 grading trials, a June evaluation where attacks tuned on small open models did not transfer to frontier ones, and Cisco's study of fifteen models, where turning on reasoning mode cut one model's attack success rate from 88.3% to 43.5%. So I said that from the stage instead, and landed on the claim the evidence does support: model choice is not the control, the failure is structural, and structural failures need protocol and host fixes.

Not a check this week. A contribution.

Pick one: join an AAIF working group and turn up to the next call (Identity & Trust or Security & Privacy if you read this newsletter); or, if you maintain something agentic that works and has a maintainer, apply to Sandbox; or add a transcript to the community archive below, because five parallel tracks means the recordings are the only way most of us see four-fifths of it.

The bar moved down deliberately. Walking through the door is now the cheapest thing on this list.

→ The recordings and the slide archive. Slides are attached to the sessions that shared them on the program page already, and the video usually follows. When the security sessions are up I will link the ones worth your time.

→ Most MCP servers are empty. David Golverdingen analysed 856 tools across 103 MCP servers and found that 97% of the tool descriptions carry what he calls a critical smell, the top severity in his own rating of how badly a tool is described. He runs nine production servers and 50-plus tools at a 300-to-400-person Dutch HVAC company, used daily by non-developers, so this is not a lab result. If the number holds up, tool description quality is a security problem as much as a usability one, and it is sitting in everybody's catalog right now.

→ The AAIF counters. Acceptances, graduations, archivals, published at every annual review. That is a falsifiable promise about whether Sandbox becomes a pipeline or a parking lot, and it is checkable in a year.

→ Next issue, Saturday. The protocol half of Amsterdam: what the 2026-07-28 stateless spec changes for security, why dynamic client registration was deprecated and what the replacement makes your authorization server fetch, and the WebMCP numbers.

If you were in the Emerald Room on Thursday, I want the feedback more than the compliment. Reply and tell me where you lost the thread.

Cheers, Amine

If a colleague deploys agents in production, forward this to them.

Sources