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.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “A Security Engineer's Guide to the A2A Protocol”.
Key questions
Q: What breaks when A2A Agent Cards are not signed or verified?
A: Unsigned Agent Cards weaken the first trust decision in an agent-to-agent exchange because consumers cannot reliably confirm who they are talking to before work begins.
Q: Why do coarse OAuth scopes create risk in agent-to-agent workflows?
A: Coarse scopes let one agent carry more authority than a single task requires, so a token that was meant for one delegated action can be reused for unrelated resources or data.
Q: How do security teams know if agent tokens are too permissive?
A: Look for tokens that are long-lived, reusable across services, or visible to the agent runtime itself.
Practitioner guidance
- Define agent identity boundaries before enabling A2A traffic Inventory every agent that can initiate, receive or broker A2A messages and assign a clear owning team, trust domain and approval path for each.
- Bind OAuth scope to task-specific authority Reduce reusable authority by constraining scopes to the exact downstream action and data set the agent needs for the current task.
- Require authenticated Agent Cards Reject unsigned or unverified Agent Cards in production paths so agent discovery does not become a spoofing entry point.
Bottom line: A2A makes agent coordination more scalable, but it also turns identity proof, consent and delegation into the primary security questions.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:15 pm
Agent-to-agent interoperability creates an identity boundary problem before it creates an integration problem: A2A makes agent coordination easier, but it also expands the number of parties that must be trusted before work can proceed. Unsigned discovery objects, coarse scopes and shared context mean the control plane is no longer just authentication plus transport. The practical conclusion is that agent identity, delegation and consent must be treated as first-class governance concerns, not implementation details.
A few things that frame the scale:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between A2A coordination and MCP tool access?
A: A2A governs agent-to-agent communication, while MCP governs agent-to-tool access. That distinction matters because tool access may be tightly bounded by a single agent, whereas A2A introduces a second trust boundary where identity, consent and delegation must survive between independent agents.
👉 Read our full editorial: A2A protocol security exposes new agent-to-agent trust gaps