Notifications
Clear all
Topic starter
02/08/2026 12:11 pm
TL;DR: A2A standardises agent-to-agent communication across JSON-RPC, gRPC, REST, and webhooks, but Semgrep notes that unsigned Agent Cards, coarse OAuth scopes, missing consent, and stream hijacking create new trust and data exposure paths for agentic workloads. The governance gap is not transport choice, but whether identity, authorisation, and delegation are still defensible when agents can coordinate at machine speed.
NHIMG editorial — based on content published by Semgrep: A2A protocol security analysis and testing guidance
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Isolate streaming sessions and task contexts Separate concurrent streams so a stolen or forged token cannot silently observe or influence another session.
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
👉 Read Semgrep's full protocol guide on A2A security and agent interoperability →
A2A protocol security: what IAM teams should watch first?
Explore further
02/08/2026 1:15 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: A2A protocol security exposes new agent-to-agent trust gaps
