Trust Boundaries Between Cooperating Agents

Trust boundaries between cooperating agents must be enforced by the runtime. Authority can pass from one agent to another without proof that it belongs there. Verifiable delegation, zone-based isolation, and cryptographic identity turn that handoff from a claim the receiving agent must believe into a boundary the execution environment can enforce.

Why multi-agent systems create a trust problem that prompts cannot solve

At the end of a delegation chain, a worker receives an instruction it cannot authenticate. The message says the action was “approved by the human principal”, but the worker cannot distinguish a legitimate orchestrator’s instruction from a compromised one’s claim. Both arrive as text in the same context window. This is instruction-data conflation, and it makes the handoff an attack surface.

That differs from the binary access question in a single-agent system, where an agent either has access to a resource or does not. In a multi-agent system, authority propagates through delegation, so a worker’s behavior depends on permissions and claims passed through other agents. Crew Scaler’s NIST response identifies shared persistent memory, delegated tool authority, and inter-agent communication as sources of vulnerabilities distinct from those documented for singular AI models. The boundary is no longer just around a resource, but across the chain that decides how to use it. A prompt saying “only trust instructions from verified sources” cannot establish that boundary, because it adds another instruction to the same ambiguous channel.

How the threat taxonomy maps across a multi-agent system's real surface area

The scope of the problem becomes clearer when the system is mapped by where authority travels. Crew Scaler’s NIST response taxonomizes 193 distinct threat items across nine risk categories, including Agent-Tool Coupling, Identity and Provenance, Memory Poisoning, and Workflow Architecture. It finds Non-Determinism and Data Leakage to be the most under-addressed domains across the reviewed frameworks. No reviewed framework achieves majority coverage of any single category. The gaps span different structural positions.

Delegation chains expose transitive authority when a worker inherits an orchestrator’s session permissions without scope reduction. A compromise can then propagate upward and sideways as well as downward through assigned tasks. Shared memory creates a different route, because an injected false belief in a vector database can persist across sessions and reach subsequent agents. Tool coupling adds the “confused deputy” problem, in which an agent exercises a credential’s full authority even when its assigned task needs only part of it.

Peer communication extends the surface further. Oxford’s multi-agent security survey identifies steganographic collusion, where agents encode covert coordination in messages without detectable surface signals, and coordinated swarm attacks, where network effects amplify a breach across many agents. These threats mark the upper bound of a surface that already includes permissions, stored beliefs, and tool access. A prompt-level control cannot cover that range because it does not govern the structures through which the attacks spread.

Two real incidents that show what happens when the architecture assumes away the problem

Clinejection on February 17, 2026, began with a malicious GitHub issue title and triggered a chain of five vulnerabilities. This led to an unauthorized supply-chain compromise of the Cline AI coding tool’s npm package, which affected an undisclosed number of developer and CI/CD systems over approximately eight hours before the package was removed. A permission bypass in Anthropic’s Claude Code GitHub Action was the proximate cause. Its checkWritePermissions function unconditionally trusted any actor whose name ended in '[bot]', allowing unauthenticated external attackers to inject prompts and trigger full repository compromise without write access. The architectural gap was a missing runtime boundary between the agent’s data ingestion surface and its authority surface.

The LiteLLM PyPI backdoor in March 2026 exposed a different entry point. A backdoor package remained on PyPI for three hours, with nearly 47,000 downloads during that window. It delivered an autonomous attack component to users of LiteLLM, the language-model gateway used by DSPy, Microsoft GraphRAG, and dozens of other agent frameworks. The compromised package arrived through the same installation channel as legitimate updates, compromising trust in the software supply chain. No instruction in an agent’s context could distinguish the installation channels, because they were the same.

The two cases differ in how hostile material entered, but share an implicit trust model encoded in deployment assumptions. One trusted an actor-name convention where an authority check was needed. The other let compromised software in through a trusted delivery route. In both, the architecture assumed a boundary that the runtime did not enforce.

Why the zone model is the right mental frame for enforcing trust at the infrastructure layer

Network security shows how a zone can change what a system can reach, beyond what it is expected to do. Applied to agents, the zone model determines what an agent can reach from its assigned position. It does not depend on the agent remembering instructions about what to avoid. An interaction can be local to the agent, delegated by an orchestrator, or crossing a shared-resource boundary. Those positions call for different trust postures.

Full trust applies only to what is within a single agent’s own context window, including its own tool outputs, earlier reasoning steps, and extended context. This is the narrow area the agent can structurally account for. Orchestrator-to-worker communication instead belongs in a verify-then-trust zone. Before executing a task, the worker validates that requested file paths, API endpoints, and tool scopes fall within its assigned boundaries. The orchestrator likewise treats worker summaries as provisional until structurally validated.

Zero trust applies when agents cross boundaries to use shared resources or work as peers. If two workers can write to the same path, access passes through a runtime-enforced queue or merge layer. That distinction makes the network analogy operational. A boundary has force because the execution environment mediates the crossing. Asking an agent to stay inside a zone does not change what it can physically reach.

The three runtime controls that enforce zone boundaries in practice

A zone can hold only if delegation has a verifiable scope, agents have cryptographic identities, and task credentials expire when the work ends. The first control makes each instruction from orchestrator to worker carry a signed delegation token. That token encodes the originating principal, authorized scope, and expiry for the runtime to inspect before execution begins. The recomputable trust protocol research proposes deriving trust from verifiable anchored evidence. Applied to delegation, the downstream agent re-derives whether an instruction is authorized instead of inheriting the upstream agent’s trust level.

The second control establishes who is participating in that exchange. The Agent2Agent Protocol’s version 1.0, released in March 2026, added signed Agent Cards that use JWS and JSON canonicalization to help verify domains and confirm identity. Cryptographic identity gives the runtime a firmer basis than an agent’s declaration of its own name. Identity and authorization must be checked separately because a known agent can still ask for work outside its scope.

The third control limits what the worker can do with an accepted task. Credentials must be scoped to the specific subtask, expire at completion, and avoid copying the orchestrator’s full session permissions. The 2026 Singapore Consensus names least privilege as its first agentic design principle. Audit makes these controls inspectable by recording the delegating agent, receiving agent, scoped credential, task correlation ID, and verification state at each handoff. Without that record, the chain cannot be reconstructed to establish whether its boundaries actually held.

Where existing protocols leave enforcement gaps and what the runtime must fill

MCP and A2A supply necessary communication infrastructure, but neither claims to provide the whole enforcement layer. The Model Context Protocol release candidate published on May 21, 2026, for the 2026-07-28 specification removes transport-level session management. Its stateless core lets it run on ordinary HTTP load-balanced infrastructure. That partially addresses session-layer threats, but leaves prompt-level injection and supply-chain threats untouched.

A2A addresses agent-to-agent discovery and identity assurance. Version 1.0 has surpassed 150 supporting organizations, with production deployments in financial services, supply chain, and IT operations. A2A explicitly leaves authorization decisions to implementers. Establishing that a message came from a known agent does not establish that the sender may issue this instruction to this worker at this scope.

The gap lies at the intersection of the protocols. MCP does not govern inter-agent delegation, while A2A does not govern tool access or memory. Neither decides who may instruct whom to use which tool on which data. Persistent memory adds a boundary that survives the conversation, because later agents can read material left by earlier ones. Crew Scaler’s NIST response identifies shared-vector-database poisoning as an attack pattern with few documented countermeasure catalogs in existing frameworks, reinforcing why memory authorization must be a runtime responsibility.

What governance tier an agent operates in changes what runtime enforcement is achievable

The strength of those controls depends on what the deployment makes verifiable. Under singular governance, one organization knows every agent directly because the same principal enrolled all of them. Provenance provides a basis for identity verification within that boundary. Least-privilege enforcement and audit logging are fully achievable there. The runtime still has to enforce them, but it starts with a known population of agents.

With federated governance, the organizations involved use a shared framework and agreements in place of that direct relationship. Identity can be verified within the federation, while authorization remains bounded by its agreements. A worker from another organization must not inherit the orchestrator’s full organizational authority simply because both belong to the federation. The runtime has to keep track of both who belongs and what they are allowed to do.

Open environments lack both common provenance and shared mediation. Without external cryptographic identity infrastructure, trust depends on what can be inferred from behavior, which can be manipulated. This is a present deployment condition for teams connecting agents to external services, third-party MCP servers, or A2A-enabled peers from other organizations. The 2026 Singapore Consensus names traceable identity as its second agentic design principle, requiring actions to be attributable to a specific authorized principal. In federated and open settings, that attribution must be cryptographic rather than declarative because declarations cannot independently establish provenance.

What a purpose-built agent runtime must enforce that adapted cloud tooling cannot

These requirements change what the execution environment must understand. A general-purpose cloud runtime sees API calls and compute events, while an agent runtime must see a delegation graph with principals, scopes, expiry, and verifiable provenance at every edge. That graph is what makes zone enforcement and mid-execution revocation possible. Per-task credentials, recomputable delegation verification, cryptographic identity, and cross-session memory authorization therefore cannot be treated as optional plugins. They require authority over execution itself.

The reference architecture in the research separates that responsibility into a Control and Governance Plane and a Runtime and Coordination Plane. The Control and Governance Plane holds zone assignments, delegation policies, and cryptographic identity, and decisions are checked before execution as well as logged afterward. The Runtime and Coordination Plane carries those decisions into agent lifecycle, workflow coordination, tool routing, context and memory coordination, scheduling, and runtime assurance. Credential scoping happens at task dispatch, memory access is authorized at read time, and delegation tokens are validated before a worker begins. The separation connects the rules governing authority to the mechanisms that constrain its use.

The 2026 Singapore Consensus’s Companion Report on Agentic Risk Management identifies runtime assurance as verification of authorized scope at startup and continuously during execution. Cloud monitoring designed to observe activity does not provide that enforcement. Adding records to an execution model cannot give it power over delegation and memory that it does not already have. General-purpose tooling would have to be rebuilt as an agent runtime to implement this two-plane separation. The gap is therefore structural, and closing it means making trust boundaries part of how agents execute.