Per-hop detection does not survive a delegation chain

Run the numbers before you read anything else.

You have a five-hop agent delegation chain. Your injection detector is good: it catches 70% of attacks at every hop. That is better than most deployed systems.

End-to-end detection probability is about 17%.

Detection composes multiplicatively against you. Each hop is another chance to miss, and a miss anywhere in the chain is a full compromise, because by the time the last agent executes, nothing downstream knows what the original request was supposed to authorize.

This is the part of agent security I think is most consistently underestimated. Teams tune the detector. The detector was never the right layer.

The failure mode has a name and it is 38 years old

Hardy formalized the confused deputy problem in 1988: an entity without permission coerces a more privileged entity into performing an action on its behalf.

Restate it for agents. An orchestrator is acting on a user’s behalf. It gets manipulated, through injected content or direct reasoning, into instructing a more privileged sub-agent to do something neither the user nor the orchestrator authorized. The sub-agent has no way to know. It received a well-formed request from a legitimate peer.

The novel wrinkle is that the deputy here is a language model. You can argue with it. Classical confused deputy attacks needed an interface flaw. This one needs a paragraph.

And empirically it works. Testing across current agent frameworks has found inter-agent trust exploitation succeeding in 100% of cases. Not most. All of them. Models apply scrutiny based on where an instruction appears to come from rather than what it actually asks for, which is an alignment artifact you cannot patch out of one framework in isolation.

Why the existing standards do not close it

The reasonable objection is that delegation is a solved problem in ordinary systems. We have had OAuth for years.

OAuth Token Exchange (RFC 8693) supports on-behalf-of delegation and defines an act claim that records the chain of prior actors. The act claim is informational. It is not enforced across hops. It tells you what happened, assuming everyone in the chain was honest about it, which is exactly the assumption under attack.

MCP defines how an agent calls a tool. It does not define what a delegated agent should be permitted to call. In practice a worker agent inherits the orchestrator’s full permission set: no scope restriction, no expiry, no delegation audit trail.

Agent-to-agent protocols are the same story one layer up. ANP organizes identity around decentralized identifiers, negotiates protocols dynamically, and discovers capabilities through a well-known endpoint, with an explicitly zero-trust posture. Google’s A2A does comparable work with a different identity model. Both are good. Neither defines fine-grained runtime authorization, which is to say: what an authenticated agent is actually permitted to do once the connection is up.

That last point is the one worth internalizing. Identity and transport are largely solved. Authorization is largely not. And “authenticated” gets read as “authorized” constantly, because in human-facing systems the gap between them is usually small.

Capability gates are not authorization

Most frameworks do have something that looks like permission scoping. Tool allowlists, capability declarations, role definitions in the agent config.

Independent testing has found these function as organizational hints rather than enforced boundaries. They tell a well-behaved agent what it should do. They do not prevent a manipulated one from doing otherwise, because the check and the thing being checked live in the same process, driven by the same model, reading the same channel.

Which is the actual root cause underneath all of this: current agent architectures collapse the data plane and the control plane onto one channel. Trusted instructions and untrusted content arrive as the same kind of thing. The agent has no structural way to tell them apart, so any content it ingests is potentially an instruction.

You can see this play out in the wild. Frameworks with an exposed control-plane port have attracted protocol-aware exploitation within hours of deployment. Malicious skills distributed through supply chains perform exfiltration and further injection. These are not unrelated bugs. They are the same architectural decision failing in different directions.

Runtime sandboxing helps and does not solve it. Out-of-process policy enforcement with default-deny egress meaningfully reduces the attack surface, and an agent cannot override constraints it does not control. But a legitimate API call that exfiltrates data is indistinguishable from ordinary traffic once it reaches the sandbox boundary. And a single-agent sandbox governs what one agent can reach. It defines nothing about how agents authenticate to each other or delegate authority across a network. Those are orthogonal concerns, and right now nothing connects them.

The property that would actually help

If per-hop detection is structurally insufficient, the alternative is to make the authority itself incapable of expanding, so that a missed detection is not a full compromise.

This is not a new idea outside of agents. Macaroons introduced attenuation-only delegation in 2014: a bearer token carries caveats chained through nested HMACs, and a derived token can only reduce its parent’s authority, never expand it. WAVE generalized it into decentralized transitive delegation with independently verifiable attestations, deployed across roughly 800 IoT devices. Biscuit keeps the attenuation-only guarantee but replaces the shared-secret chain with public-key signatures per block, so verification works offline.

They differ in cryptography and maturity. They converge on one property: delegated authority that can only narrow as it crosses a hop, verified independently of what the delegating party claims it was authorized to grant.

Apply that to the chain at the top of this post. A manipulated orchestrator can still be manipulated. It simply cannot hand a downstream agent more authority than the originating principal actually held. The attack does not need to be detected to fail.

I think that is where this goes, and I think the industry is currently spending its effort one layer too high. Better injection classifiers are worth building. They are not a substitute for an authorization boundary, and treating them as one is how you end up with a 17% end-to-end detection rate you never measured.

More on the isolation side of this next.