Why safe agents can still create unsafe handoffs

Quick answer: an agent can be safe inside its own boundary and still create an unsafe outcome when it delegates. The receiving agent may lose the human origin, inherit broader permission, or trust a credential that was never meant to travel. Governance therefore has to evaluate the handoff, not only each agent.

Executives usually review agents one at a time. What data can this agent read? Which tools can it call? Who approves its output? Those are necessary questions. They are no longer sufficient when the agent can ask another agent to act.

The old security name for this is the confused-deputy problem. In the original 1988 formulation, a program with legitimate authority is induced to misuse that authority for someone else. Multi-agent systems make the pattern faster and harder to see: delegation can be recursive, asynchronous, and spread across organizations.

Three ways trust breaks at the boundary

1. Identity collapses

A person asks Agent A for a result. Agent A asks Agent B to perform an action. The target system sees Agent B's service identity, but not necessarily the person whose request began the chain or Agent A's role in translating it. The action is authenticated while its authority is poorly attributed.

2. Permission expands

Agent A may be allowed to prepare a change but not deploy it. If Agent B owns a standing production credential and treats A's request as sufficient authority, the handoff has converted a narrow instruction into a broader capability. Both agents followed their local rules. The chain violated the intended ceiling.

3. Trust becomes contagious

A compromised agent can use relationships that other systems already trust. It can place instructions in a repository, ticket, document, or message that another agent later consumes. The next agent does not need to trust the attacker directly. It only needs to trust the contaminated handoff.

A worked multi-agent example

A sales manager asks a revenue agent to prepare a renewal-risk brief for one account. The revenue agent delegates customer-history retrieval to a CRM agent. The CRM agent then asks an analytics agent to query product usage, and the analytics agent sends the result to a communications agent that drafts an executive email.

1. The manager's request is narrow: analyze one renewal.
2. The revenue agent translates the task: retrieve account history.
3. The CRM agent uses a broad credential: it can read every customer record, not only the named account.
4. The analytics agent joins more data: usage records for related subsidiaries enter the context.
5. The communications agent acts on inherited trust: it drafts an external email containing information the manager was not entitled to request.

No individual agent needed malicious instructions. The failure emerged because origin faded, effective permission widened, and downstream systems treated upstream trust as transferable. A final approval may catch the email. It will not fix the architecture that assembled it.

The seven checks at every handoff

Use these as acceptance criteria for a delegated action, not as a questionnaire completed once when an agent is registered.

1. 01
   Origin

   Can the receiving agent prove which person or organization authorized the work?

2. 02
   Attribution

   Does the record name every agent that acted, not only the final system?

3. 03
   Narrowing

   Is the delegated capability strictly smaller than the capability held upstream?

4. 04
   Human ceiling

   Is effective authority capped by what the originating person could do?

5. 05
   Lifetime

   Is access issued for this task, to this resource, for a short period?

6. 06
   Runtime check

   Is authorization evaluated when the consequential action happens?

7. 07
   Evidence

   Can any link be revoked, and can the full chain be reconstructed?

A token proves possession of a credential. It does not automatically prove the full delegation chain, preserve the originating human's limit, or guarantee that authority narrowed at every hop. OAuth 2.0 Token Exchange provides useful delegated and “on-behalf-of” semantics, including an actor claim, but no single current building block closes all seven checks across recursive, cross-domain agent chains.

Standards status and review cadence

Last primary-source review: September 9, 2026. We review the NIST, IETF, OpenID Foundation, Model Context Protocol, and Agent2Agent sources below every six months, and sooner when a primary specification or final guidance changes. Drafts, concept papers, community-group work, and working-group drafts are treated as emerging mechanisms, not settled controls.

As of this review, RFC 8693 remains the stable foundation cited here for token exchange and actor semantics. NIST's software and AI-agent identity work is still a concept-stage project. OpenID's agent-authorization work includes working-group drafts rather than final specifications. MCP defines OAuth-based authorization for HTTP transports, and A2A 1.0 defines protocol-level authentication and authorization requirements; both help secure their respective boundaries, but neither by itself proves or constrains an entire recursive delegation chain.

Material change note: September 9, 2026 — added the dated standards review, six-month review cadence, and primary MCP, A2A, and OpenID references. The seven control checks and 30-day audit did not change.

A 30-day delegation audit

Days 1–5: choose the chains. Select five consequential workflows that include at least one agent-to-agent or agent-to-tool handoff. Name the human origin, every agent, every system, and the business owner.

Days 6–12: trace effective authority. Record the credential actually used at each hop, its resource scope, lifetime, ability to delegate again, and the originating person's own ceiling. Do not document only the intended permission.

Days 13–18: test the boundaries. Attempt an out-of-scope account, a stale approval, a revoked upstream identity, and a request whose wording changes after the first hop. Confirm the runtime denies the action rather than relying on a later audit.

Days 19–24: reconstruct the chain. Give an independent reviewer the final action record. Ask them to identify who authorized it, which agents acted, what each saw, how authority changed, and where the chain could have been stopped.

Days 25–30: narrow before scaling. Replace standing credentials where practical, shorten lifetimes, add resource constraints, define human gates for consequential actions, and assign an owner to unresolved gaps. Scale only the patterns that preserve attribution and narrowing.

What the evidence does and does not show

The attached March 2026 preprint usefully synthesizes the identity-collapse, privilege-expansion, and contagious-trust framework. It also repeats adoption and over-permissioning percentages drawn from analyst forecasts and vendor reports. Those figures are not needed to establish the control problem, and the underlying primary datasets were not available for independent verification here, so this article does not repeat them as facts.

The stronger foundation is structural: Hardy's confused-deputy model, the delegated-token semantics in RFC 8693, NIST NCCoE's 2026 call for better software and AI-agent identity and authorization, and the preprint's seven-check requirements synthesis. The exact market percentage can change without changing the governance requirement.

References

• Norman Hardy, “The Confused Deputy (or why capabilities might have been invented),” ACM SIGOPS Operating Systems Review, 1988.
• IETF RFC 8693, OAuth 2.0 Token Exchange, 2020.
• NIST NCCoE, “Software and AI Agent Identity and Authorization,” concept-stage project, reviewed September 2026.
• OpenID Foundation, AuthZEN agent-authorization working-group drafts, June 2026.
• Model Context Protocol, Authorization specification, current version reviewed September 2026.
• Agent2Agent Protocol Specification, version 1.0, reviewed September 2026.
• Binod Kumar, “The Agent-to-Agent Handoff Problem: Session Trust and Privilege Escalation Across Agent Boundaries,” preprint, March 2026.

Put the controls into the company design. Read the Agentic Operating Model and the AI governance operating guide.