Agent-to-agent (A2A) communication makes systems more capable by letting agents hand off subtasks to each other. That same hand-off mechanism is also the attack surface. When one agent can instruct another, the question shifts from "is this agent trusted?" to "is this agent's delegation of authority to that agent legitimate?" The two questions are distinct, and conflating them is where most teams get hurt. For a grounding in how agent identity and credentials work before delegation enters the picture, see AI agent identity: why agents need their own credentials.
What Delegation Abuse Actually Means
Delegation abuse does not require a compromised agent in the traditional sense. It occurs when a legitimate agent delegates work in a way that exceeds the scope it was given, carries permissions further down a chain than the original principal intended, or creates a delegation path that circumvents a control that would have applied to a direct call.
Three patterns recur in agentic systems:
Authority laundering. An orchestrator agent holds permission to read a sensitive data source. It delegates a subtask to a worker agent that was never meant to have that access. The worker inherits the orchestrator's authority, and the read goes through. No credential theft occurred; the permission simply traveled further than the policy intended.
Chain amplification. Agent A can write to a staging environment. It delegates to Agent B, which re-delegates to Agent C. By the time the action reaches Agent C, nobody is inspecting whether the original grant was meant to be transitive.
Confused deputy via tool calls. A research agent, trusted to call read-only tools, is manipulated into instructing an action agent on behalf of a user it is working for. The action agent does not verify whether the instruction was explicitly authorized by the human principal or inferred by the research agent.
None of these require the agent to be "hacked." They require only that the delegation model has no enforcement boundary.
The Attacker's Goal
An adversary exploiting A2A delegation abuse is typically trying to achieve one of two things: privilege escalation (reaching a resource or action that neither the attacker nor the directly compromised agent is authorized for) or attribution washing (causing an action that is traceable only to a trusted internal agent, not to the actual origin).
Both goals are served by the same structural weakness: a delegation chain in which each hop trusts the previous hop unconditionally and does not verify whether the original principal authorized that specific action for that specific delegatee.
Why the Standard API Security Model Does Not Help
Traditional API security relies on authenticating the caller. If the caller presents a valid credential, the request proceeds. In a flat agent topology this works adequately. In a multi-agent system it breaks down because the calling agent is authenticated, but the question of whether that agent was legitimately instructed to make the call — and whether its delegatee is permitted to receive the delegated scope — is not answered by authentication alone.
OAuth 2.0 addresses a version of this problem for human-to-service delegation with the concept of scoped, short-lived tokens that cannot be used for purposes outside the stated scope. The same principle applies to agent delegation, but most agent frameworks do not enforce it. The agent simply passes its own credential downstream, or the platform issues a new credential based solely on the calling agent's identity rather than the intersection of the calling agent's scope and the task being delegated.
For an overview of how A2A protocols work and where governance fits in, see Agent-to-Agent (A2A) Communication, Governed.
The Control Classes That Contain It
Containing delegation abuse requires controls at the delegation boundary itself, not just at the credential issuance step.
Scoped delegation tokens. When agent A delegates to agent B, the credential issued to agent B should represent the intersection of what agent A is allowed to do and what agent A is explicitly delegating. If agent A holds a write permission but is delegating a read-only task, the delegated credential should carry only read. The original grant does not automatically transfer.
Non-transitivity by default. A delegation should not be further delegatable unless the original principal explicitly allows it. The receiving agent cannot re-delegate unless the token or policy record says it may. This breaks chain amplification at the first hop.
Time-bounding. Delegated authority should expire in proportion to the expected task duration. A research subtask expected to run for two minutes should not produce a credential that remains valid for eight hours. Short validity windows limit what an abused delegation can achieve.
Audit trails tied to delegation chains. Logging an action as "agent B wrote to resource X" is not enough. The audit record should capture the full delegation lineage: who instructed agent B, under what delegated scope, and whether that delegation was within the scope of the original grant. Without this, attribution washing succeeds in audit even after the fact. For the properties an audit trail needs to hold up, see audit trails that hold up.
Plan and capability limits at the receiving end. The resource being called should not rely solely on the delegating agent's reputation. It should enforce its own access policy against the presented credential, including checking whether the credential's stated scope is actually permitted for the requested action.
Threat Modeling A2A in Your Own Systems
A practical threat model for A2A delegation in your environment starts with four questions:
| Question | What you are looking for |
|---|---|
| What can each agent be instructed to do, and by whom? | The origination policy: which principals may invoke which agents |
| What permissions does each agent hold, and can they be delegated? | The scope inventory: no agent should hold more than its tasks require |
| Can a delegation be re-delegated without explicit authorization? | Transitivity gaps: assume re-delegation is unsafe unless enforced otherwise |
| Is the delegation chain captured in audit, not just the terminal action? | Attribution completeness: the chain, not just the leaf, must be logged |
The output of this exercise is usually a smaller set of agents that need privileged capabilities, a clearer statement of which delegations are intentional, and a list of delegation paths that were unintentional but currently possible. The AI agent governance for enterprises framework covers where this threat model fits in a broader program.
Governed Connections as the Structural Control
The controls above work best when agent-to-agent communication is modeled as a first-class identity problem. Each agent should have its own identity, and when communication between agents is enabled, the platform should issue credentials scoped to that agent's defined role and connection policy rather than forwarding the caller's credential. The trust granted to a delegatee is bounded by the delegator's own grant, not inherited in full.
Connections between agents should carry an explicit trust level and be revocable independently of the underlying agent credentials. Audit logs must capture the chain of invocation, not just the terminal action, so forensic reconstruction after an incident is possible without relying on agent-generated logs that a compromised agent could influence.
The design follows the same principle that makes OAuth useful: the delegate cannot receive more authority than the delegator held, and the grant is time-bounded and purpose-specific. For a deeper look at how governed connections between agents are structured, see governed connections between agents and resources.
Common questions
Does mutual authentication between agents prevent delegation abuse? Mutual authentication confirms that both agents are who they claim to be, but it does not constrain what they are permitted to do in that session. An attacker who needs agent B to perform an action can use a fully authenticated agent A as the intermediary if A is allowed to instruct B without scope constraints. Authentication is necessary but not sufficient; you also need scope enforcement at the delegation boundary.
If we log all A2A calls, is that enough? Logging is essential for forensics and compliance but is not a preventive control. Logging tells you what happened; it does not stop an over-broad delegation from succeeding. The logs are also only as trustworthy as the system that writes them — if a compromised agent can influence what gets written, the log may omit the delegation path. Append-only, externally written audit trails address that concern, but they still do not substitute for enforced delegation scope. See tamper-evident audit logs with cryptographic proofs for the properties that make a log forensically reliable.
How does this differ from regular RBAC? Role-based access control assigns permissions to principals. Delegation abuse is a problem of transitive authority: a principal with a given role instructs another principal, and the question is whether that instruction carries the full role or a subset of it. Standard RBAC models do not answer the transitivity question. You need a delegation model that explicitly defines what scope travels with each hand-off, layered on top of whatever RBAC governs each agent's direct access. For an overview of how RBAC maps to agent governance, see RBAC and custom roles for AI operations.
How does delegation abuse relate to prompt injection? They can compound each other. A successful indirect prompt injection attack may cause an agent to initiate a delegation it would not otherwise make — extending the attacker's reach through the delegation chain rather than just through that single agent's actions. Treating both threat vectors together gives a more complete picture of lateral movement risk in multi-agent systems.
How should you handle an agent that has been granted delegation rights it should not have? The immediate action is to revoke the delegation grant and, if the agent has already delegated to others, cascade the revocation to any active downstream sessions. Once access is contained, audit the delegation chain that existed to identify what was accessible and whether any data or actions were taken outside intended scope. Going forward, treat delegation grants with the same rigor as direct permissions: scoped explicitly, time-bounded, and reviewed as part of any access-review cycle. See how to audit AI agent activity for what that review process should capture.