A2A protocol security exposes new agent-to-agent trust gaps

At a glance

What this is: This is Semgrep’s analysis of the A2A protocol, with the key finding that standardised agent-to-agent communication expands the attack surface around identity, OAuth, consent, and stream handling.

Why it matters: It matters because IAM, NHI, and agentic AI teams will need to govern how agents discover each other, exchange data, and inherit authority without assuming human-paced review or session boundaries.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Semgrep's full protocol guide on A2A security and agent interoperability

Context

A2A is a protocol for agent-to-agent communication, which means the identity problem shifts from a single agent invoking tools to multiple agents exchanging tasks, messages, and artifacts. For identity programmes, that creates a governance gap: authority is now distributed across agents that may discover each other dynamically and operate outside familiar human approval loops.

Semgrep’s guide is useful because it frames A2A as an implementation and security issue, not just a protocol design story. The practical question for NHI and IAM teams is whether existing controls can still express trust, consent, scope, and revocation when one agent can hand work to another at runtime.

That matters even more in environments where agentic workloads are already becoming common. The current starting position is atypical in maturity, but it is increasingly becoming the normal design assumption for new agent systems.

Key questions

Q: How should security teams govern agent tool calls in production?

A: Treat each tool invocation as a separate identity decision, not as a one-time permission granted to the agent. The control model should validate current context, the specific tool being called, and whether the action matches the intended task. This is the only way to keep delegated agent activity auditable and bounded.

Q: Why do AI agents create new risk for IAM and NHI programmes?

A: Because they can execute actions, inherit permissions, and connect to sensitive systems without a human acting each time. That shifts risk from static account management to runtime behaviour, delegated access, and lifecycle control. IAM programmes must therefore track both the agent and the identities it uses.

Q: What breaks when OAuth scopes are broader than resource permissions?

A: When OAuth scopes are broader than resource permissions, the connector can succeed while the downstream application allows access to objects the security team never meant to expose. That creates a split control plane where one layer says yes to invocation and another layer says yes to access, with no single governance decision in charge.

Q: Who is accountable when an agent leaks data through an MCP server?

A: Accountability sits with the teams that defined the trust boundary and the controls that failed to enforce it, usually identity, platform, and security owners together. If tool authorization, context validation, or monitoring was missing, the breach is a governance failure, not just a runtime incident. Shared ownership must be explicit before deployment.

Technical breakdown

A2A agent cards and endpoint discovery

An Agent Card is a machine-readable description of an agent’s capabilities, skills, auth schemes, and endpoints. In practice, that turns discovery into a security problem: if cards are public or easily guessed, adversaries can enumerate agents, infer available actions, and test the interface with the same methods used against web APIs. The risk is not only exposure of the endpoint itself, but exposure of the capability model behind it. In agentic systems, metadata becomes an attack map.

Practical implication: treat agent discovery data as an access control surface and restrict who can enumerate and query agent cards.

OAuth scopes and consent in agent-to-agent delegation

A2A can use OAuth, but the protocol does not force short-lived tokens, fine-grained scopes, or user consent before data is shared between agents. That means an agent may act with authority that was originally granted for a different purpose, and the receiving agent may receive data or actions that exceed the original intent. This is a classic delegation problem, but the stakes increase because the actor is software deciding at runtime what to pass onward.

Practical implication: bind delegated authority to task scope and expiry, not to broad standing tokens reused across agent interactions.

Stream hijacking, shared context, and task state leakage

A2A supports asynchronous task states, streaming updates, and intermediate artefacts. That is operationally useful, but it also creates a place where stolen or forged session tokens can observe, redirect, or manipulate ongoing work if implementations do not isolate streams and contexts correctly. Shared context is especially sensitive because it can carry payment data, identity documents, or other material that was never meant to traverse multiple agents. The protocol does not remove the need for strong session and context isolation.

Practical implication: isolate streams, bind task context to the correct session, and avoid shared context for sensitive data unless access is explicitly constrained.

Threat narrative

Attacker objective: The attacker’s objective is to turn agent-to-agent delegation into unauthorized access, data exposure, or result manipulation at machine speed.

1. Entry occurs when attackers identify exposed A2A endpoints or public Agent Cards and use the protocol surface to probe for accessible agents.
2. Escalation occurs when weak OAuth scope design, missing consent, or unsigned cards let the attacker inherit broader authority than the original interaction should permit.
3. Impact occurs when the attacker uses the delegated agent path to trigger unauthorized compute, leak data, or manipulate task results across agents.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

A2A creates a delegation governance problem, not just an interoperability problem. Once agents can hand work to other agents, the key question becomes who may delegate what, under which scope, and for how long. Existing IAM patterns were built around human-paced approval and relatively stable sessions. A2A shifts that authority into machine-to-machine flow, so the governance model must now account for cross-agent trust boundaries, not just single-actor authentication.

Unsigned Agent Cards introduce a capability discovery trust gap. When agent identity metadata can be spoofed cheaply, the protocol surface stops being a neutral directory and becomes a reconnaissance vector. That matters because agents do not just discover services, they infer what they are allowed to ask for. Practitioners should read this as a warning that discovery and trust are inseparable in agentic environments.

Coarse OAuth scopes are a form of authority mismatch in agent systems. The scope model may have been acceptable for a predictable application call, but it breaks down when an agent chains sub-tasks across other agents. The result is delegated power that persists beyond the original intent, which is exactly the kind of overreach identity governance is meant to prevent. Teams should treat broad scopes as a control design flaw, not just a configuration issue.

Shared context is becoming the new identity blast radius for agentic software. When sensitive data moves through intermediate agents, the exposure is no longer confined to one application boundary. This aligns with the OWASP agentic risk model and the broader NHI problem of authority sprawl: more identities, more handoffs, more places for control failure. Practitioners should assume that every new delegation path enlarges the blast radius unless context isolation is explicit.

Capability-based access will matter more as agent-to-agent protocols mature. Semgrep’s observation that A2A favours resource handles over free-form access is consistent with the direction of least-authority design. The industry should expect tighter coupling between task scope and resource capability, because human-style permission prompts do not scale to autonomous delegation chains. That is a structural shift in how identity control must be expressed.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• That visibility gap makes OWASP NHI Top 10 the right next reference point for teams defining agentic control boundaries.

What this signals

Capability boundary: A2A adoption will force IAM and NHI teams to treat delegated agent work as a governed capability, not a generic service call. That means more emphasis on task scope, session binding, and revocation paths, especially where one agent can hand work to another without human review.

With 98% of companies planning to deploy more AI agents within 12 months, per AI Agents: The New Attack Surface report, the control problem is no longer experimental. Teams should expect agent discovery, token replay, and shared-context exposure to move into mainstream audit conversations.

If your programme already uses Zero Trust language, A2A is the point where you must prove it. The OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward tighter authority design, but the operational change is simple: every agent handoff needs a named owner, a bounded purpose, and a revocation path.

For practitioners

• Inventory every exposed A2A endpoint and Agent Card Map where agents are discoverable, which skills they advertise, and whether card metadata leaks endpoints or auth schemes. Restrict public enumeration and treat card publication as a governed exposure point.
• Bind OAuth tokens to task scope and short expiry Eliminate broad reusable tokens in agent-to-agent flows and enforce single-purpose scopes for each task. Review whether tokens can be replayed across agents or reused after the originating task completes.
• Isolate streaming sessions and task contexts Separate concurrent streams so a stolen or forged token cannot silently observe or influence another session. Keep sensitive artefacts out of shared context unless access is explicitly constrained.
• Adopt capability-based authorisation for agent handoffs Prefer explicit resource handles and narrow permissions over broad delegated authority when agents pass work between each other. This reduces confused-deputy risk in multi-agent orchestration.

Key takeaways

• A2A turns agent interoperability into an identity governance problem because agents can now delegate authority to other agents at runtime.
• Unsigned cards, coarse OAuth scopes, and shared context are the main control gaps that expand the attack surface for agentic systems.
• Practitioners should prioritise narrow capability-based access, short-lived delegation, and isolated task contexts before A2A adoption accelerates.

Key terms

• Agent Card: An Agent Card is a machine-readable description of an agent’s capabilities, endpoint, and invocation details. In A2A-style systems it helps other agents discover and call the agent at runtime, which makes the card a governance object as much as a technical descriptor.
• Capability-Based Authorization: Capability-based authorization grants narrowly defined verbs on specific resources instead of broad role membership. For AI agents, that means the token should allow only the exact task steps required, because probabilistic behaviour can turn coarse permission into chained misuse.
• Task Context: The state and data associated with a specific agent job, including messages, artefacts, and intermediate outputs. In A2A-style systems, context can become an exposure path if it is shared too broadly, reused across sessions, or allowed to carry sensitive data without strong isolation.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.

What's in the full article

Semgrep's full protocol guide covers the implementation detail this post intentionally leaves for the source:

• JSON-RPC, gRPC, and REST binding examples that help engineering teams validate real implementations
• Protocol-level discussion of transport handling, streaming, and webhook update paths for long-running tasks
• Semgrep's checklist for testing A2A implementations and spotting common security failures
• Further notes on unsigned Agent Cards, OAuth scope design, and serialization risks in agent payloads

👉 Semgrep's full guide covers the A2A attack surface, protocol bindings, and implementation pitfalls in more depth.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.