Because the risk is compounded across layers. A2A can broaden who receives work, and MCP can broaden what each recipient can touch. When those links are combined without strong scoping, the organisation gets a larger blast radius, more difficult revocation, and weaker accountability across the agent chain.
Why This Matters for Security Teams
MCP and A2A become especially risky when they are combined because each layer expands identity scope in a different direction. A2A broadens who can receive, delegate, or chain work between agents, while MCP broadens what each agent can reach through tools and data sources. That creates a compound trust problem: the receiver of a task may not be the entity that should hold the capability to execute it.
For security teams, the failure mode is not just excessive access. It is also weak attribution, unclear revocation, and policy decisions that were never designed for autonomous handoffs. Current guidance in OWASP Agentic AI Top 10 and NIST’s NIST Cybersecurity Framework 2.0 points toward tighter authorization and traceability, but the operational pattern is still emerging. NHIMG’s Ultimate Guide to NHIs and 52 NHI Breaches Analysis both show the same lesson: once identity scope is over-broadened, recovery is usually reactive rather than controlled.
In practice, many security teams discover that the chain was over-permissioned only after an agent has already moved data or triggered downstream actions.
How It Works in Practice
The core issue is that MCP and A2A stack two different identity decisions on top of each other. MCP often governs tool use, data access, and action execution within a single agent context. A2A governs inter-agent delegation, message passing, and work reassignment across agents. If both are implemented with static RBAC alone, the policy model assumes a stable human-like job role, but agents do not behave that way. They are goal-driven, can branch into unexpected tool paths, and can chain requests in ways that are difficult to pre-authorize.
A stronger pattern is to treat the agent as a workload identity, then evaluate permissions at runtime based on intent, context, and task state. That means short-lived credentials, per-task scoping, and revocation when the task ends. In mature designs, the agent proves what it is with workload identity and then receives just enough capability to complete a bounded action. This aligns with the direction described in the OWASP Top 10 for Agentic Applications 2026 and NHIMG’s OWASP NHI Top 10, both of which emphasize that agent permissions must be bounded to the action, not the persona.
- Use ephemeral secrets or tokens for each task instead of long-lived standing credentials.
- Bind A2A delegation to explicit policy, not implicit trust in the sender agent.
- Limit MCP tool access by context, data sensitivity, and task purpose.
- Log both the originating agent and the receiving agent so accountability survives handoff.
When this is implemented well, revocation is clean because the credential expires with the task, not with the agent’s lifetime. These controls tend to break down in distributed agent meshes where messages are forwarded through multiple brokers and the original authorization context is lost.
Common Variations and Edge Cases
Tighter delegation and shorter-lived credentials often increase operational overhead, so organisations have to balance security against workflow reliability and developer friction. There is no universal standard for MCP plus A2A identity binding yet, so current guidance suggests using the least permissive option that still allows the agent to complete a narrowly defined task.
One common edge case is multi-agent orchestration where a planner agent assigns work to specialist agents. In that model, A2A can be safe only if the planner does not inherit the specialist’s tool rights and the specialist does not inherit the planner’s broad context. Another edge case is recovery automation, where an agent may need temporary elevation to fix a failed process. That should be time-boxed and explicitly approved, not baked into the normal path.
Another risk appears when teams assume the MCP server is the trust boundary. It usually is not. The real boundary is the combination of workload identity, runtime policy, and tool-specific authorization. NHIMG’s Ultimate Guide to NHIs and the vendor research in AI Agents: The New Attack Surface report both show that visibility gaps widen quickly when organisations cannot see what an agent accessed or why. Best practice is evolving, but the direction is clear: isolate delegated work, shorten credential life, and require runtime policy evaluation for every meaningful tool call.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2A-01 | A2A delegation expands agent-to-agent trust and needs scoped controls. |
| CSA MAESTRO | IAM-03 | MAESTRO addresses identity and access risks in autonomous agent workflows. |
| NIST AI RMF | AI RMF covers governance of autonomous behavior and traceability across agents. |
Apply AI RMF governance to define ownership, logging, and escalation paths for agent chains.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
