Nobody Agrees What Delegation Means, and That Is a Security Problem

I ended the last piece with a promise: that the seam where one agent trusts another is where the unsolved problems live, and that I would spend the next stretch of work measuring what breaks there. The design is now written down, before any results, so that it constrains what I can claim later. It also changed while I was writing it, because the thing I set out to measure turned out not to exist.

The argument people actually have about managed agent runtimes is whether to use one. The case for is serious. Platform security teams you cannot afford, sandboxing you did not build, state and recovery you do not babysit, identity and guardrails as configuration instead of code you maintain forever. The case against is equally serious: opacity, lock-in, and a trust boundary inside someone else’s product where you cannot inspect what happens. Both positions are held by people who have thought about it, and the tradeoff they are arguing over is real.

Both positions also assume that “managed agent runtime” names one thing. Read the three products carefully and that assumption falls apart, and it falls apart in a way that matters more than the tradeoff being argued about.

Start with AWS. Bedrock AgentCore reached general availability in October 2025 and its Harness followed in June 2026, and it supports A2A, so on a market map it looks like the delegation-capable managed runtime. It ships a hosting contract. The documented protocol contract pins protocolVersion: 0.3.0, serves agent cards at /.well-known/agent-card.json, and passes the invocation payload through unmodified. Delegation is whatever the framework you put inside the container makes it, because the runtime supplies no primitive for it. The authorization side is more developed, with on-behalf-of token exchange generally available since April, implementing RFC 8693 and carrying both the agent’s identity and the original caller’s at every hop. What it does not document is a chain-depth limit, a scope-narrowing requirement, or anything preventing a received token from being exchanged onward. And the Cedar schema behind AgentCore Policy offers AgentCore::OAuthUser and AgentCore::IamEntity as principal types. There is no agent principal at all.

OpenAI went the opposite direction and most stack diagrams have not caught up. Its genuinely managed runtime is multi_agent in the Responses API, in beta since 9 July 2026 and GPT-5.6 only, where a root agent spawns subagents server-side through six OpenAI-executed actions with hierarchical names like /root/researcher. Orchestration happens inside the model layer. Meanwhile the low-code hosted product went the other way: AgentKit’s Agent Builder was deprecated on 3 June with shutdown in November. There is no A2A support and no plan for one; the open issue has been sitting since last year and the maintainer said explicitly they would hold off on adding the adapter to the core SDK. OpenAI’s interoperability bet is MCP.

Anthropic ships a third shape. Claude Managed Agents has been in public beta since 8 April, still requiring the managed-agents-2026-04-01 header, and its multiagent orchestration is a coordinator delegating to workers through delegate_to_agent. The constraints are where it gets interesting. Delegation depth is one, so workers cannot delegate onward. A roster holds at most twenty distinct agents. Workers inherit nothing from the coordinator: each declares its own tools and MCP servers at creation time, which means there is no mechanism by which a coordinator can grant a worker anything it did not already have. Authority is static and declared. The same session, however, shares one sandbox, one filesystem, and one credential vault across every agent in it.

There is no common substrate. An agent definition that runs on all three does not exist.

That is why the security question cannot be asked the way I originally asked it. Three of the largest companies in the field have shipped three structurally incompatible answers to what it means for one agent to hand work to another, with three different implied trust models, and all three appear under the same category heading on every market map. A transparent proxy, a model-native spawn tree, and a fixed depth-one topology with statically scoped workers are not variations on a theme.

The protocols underneath do not settle it either. A2A v1.0.1 makes agent card signing a MAY and verification-before-trust a SHOULD, with no PKI, no trust anchor, and no revocation. RFC 8693 token exchange appears zero times across the specification’s 3,610 lines, so delegated authorization is left entirely to implementations. What signing gives you, where it is used at all, is identity, and identity is not trust. Knowing which domain issued a card tells you nothing about whether the context you hand over leaks, whether authority reaches further than you granted, or whether what comes back is safe to act on.

Comparative agent-security work exists and it is better than it was six months ago. MCPSecBench runs seventeen attacks across four surfaces against three MCP host applications with fifteen trials each, and finds that outcomes vary considerably by host, which is the closest thing to what I want to do. A2ASecBench defines seven A2A attack families including card spoofing and ships a pluggable adapter interface, though it tests the official demos rather than comparing runtimes. ACIArena contributes the only named propagation metric in the field across 1,356 cases, comparing six open-source multi-agent libraries. The June systematization of 247 papers organizes the whole area around information flow, delegated authority, and persistent state, and concludes that existing benchmarks underrepresent long-horizon and deployment-sensitive risk. What I cannot find anywhere is the four properties together: managed runtimes as the unit of comparison, both delegation and tool-call boundaries in scope, one attack corpus held constant across them, and statistical treatment of non-determinism. One industry lead is still unread, so I am saying I cannot find it rather than that it does not exist.

The design follows from the divergence. Since no agent definition ports, the study holds constant what can be held: the task, the attack corpus, the tool surface down to identical MCP servers and schemas, and the topology of one delegating principal, one delegate, one privileged sink. The delegation mechanism varies, because the mechanism is now the independent variable. That leaves an obvious confound, since runtime and model are entangled in every managed cell, and a naive runtime-versus-runtime table would attribute model differences to runtimes and would deserve to be ignored. The fix is model-matched pairing against a self-hosted control that can reach many providers, so the primary quantity is managed minus self-hosted for the same model, and cross-runtime comparison is a secondary result carrying its caveats openly.

Four properties get measured: context confinement, meaning whether content crosses a boundary the delegator did not intend to send; non-amplification of delegated authority, meaning whether a delegate reaches capability the delegator did not hold or grant; injection propagation, meaning whether adversarial content survives a hop and acts at the next one; and boundary observability, meaning whether the operator can see any of it from the runtime’s own telemetry. That last one is a primary result, because auditability is part of what a managed runtime is selling and nobody has scored it.

Predictions go on the record before any code runs, derived only from vendor documentation, because the point is to report where the documentation was wrong. AgentCore should permit authority to amplify, since nothing documented requires narrowing on re-exchange or bounds chain depth, and Policy should not see the A2A hop at all given the missing agent principal. OpenAI’s dominant leak channel should be context propagation at spawn, and its guardrails should not fire at the delegation boundary, because input guardrails run only for the first agent and output guardrails only for the one producing final output. Anthropic should show no amplification through the tool interface, by construction, and should still show it through the shared filesystem and vault. Where a runtime structurally prevents a scenario, that gets reported as structurally prevented, which is a different result from no violations observed.

Measurement is the part that might not work. There is no API to export traces from OpenAI’s dashboard, tracing is unavailable to Zero Data Retention organizations, and whether the hosted multi-agent runtime exposes per-subagent trajectory data to the caller is undocumented. That is a fact worth knowing whether or not anyone runs this study: if you cannot reconstruct what crossed a delegation boundary, you cannot audit it after an incident either. Where a runtime fails that test, it comes out of the behavioural comparison and gets reported as an observability finding, because a weaker proxy dressed up as the same measurement is worse than a missing cell.

So if you are choosing a managed runtime this quarter, you are choosing a trust model, and the three on offer differ more than their category page suggests. Three questions separate them. Where does delegation actually happen, in the runtime or in your code? What does the runtime know about the authority crossing that boundary, and can it enforce anything there? And what will it tell you afterwards about what crossed? Ask those of AgentCore, of the Responses API, and of Managed Agents, and you get three different answers today, none of which is documented as a security property.

The method document comes next, with the corpus, the observation contract, and the statistics.