Because standardisation reduces integration friction, not trust complexity. Each new connection creates another opportunity for broad scope, weak delegation, or invisible handoffs between agents, tools, and data sources. The risk is cumulative when identity controls do not follow the protocol path.
Why standardised protocols still increase identity risk
Standardised protocols make integration easier, but they do not standardise trust decisions. MCP and A2A can multiply identity risk because every endpoint, tool, and agent relationship still needs explicit scope, delegation, and verification. If those controls are inconsistent, the protocol simply gives weak identity paths a cleaner, more repeatable way to spread.
Where the risk comes from in MCP and A2A
The main issue is not whether the protocol is documented, it is whether the identity path is bounded. In MCP, the same client can reach multiple servers, tools, or resources, so token handling, audience restriction, and server trust boundaries matter. In A2A, delegated action between agents adds another layer of indirection, which makes it easier for broad permissions or weak handoffs to travel farther than intended. See MCP Security Guide for the authorisation model and token handling issues that make this boundary easy to get wrong.
Standardisation also creates scale effects. Once a protocol becomes the default integration path, teams tend to reuse the same patterns across many tools and agents, which can turn one overbroad credential or trust rule into a widespread exposure. That is why protocol consistency is useful operationally, but dangerous if it is mistaken for policy consistency. The same pattern appears in Multi-Agent and A2A Security Guide, where signed agent identity and multi-hop delegation are treated as first-class security concerns.
For practitioners, the hard problem is that trust handoffs are often invisible at runtime. A standard can tell you how requests should move, but it does not by itself tell you who may speak for whom, how long that authority lasts, or whether the receiving side should accept the request at all. That is why AI Agent Identity Security: The 2026 Deployment Guide is useful for the lifecycle side of the problem, especially where ephemeral credentials, least privilege, and task-scoped access are needed.
Risk and Threat Considerations
MCP and A2A increase exposure when identity controls lag behind protocol adoption. The most common failure mode is broad delegation, where an agent or tool inherits more authority than the task requires, and that authority is then reused across multiple hops or sessions. The result is a larger blast radius, weaker attribution, and a higher chance that an apparently routine integration becomes a privilege path.
Failure mechanism: A standardised request path makes it easier to connect more systems, but if the receiving side does not enforce audience restriction, scoped delegation, or per-hop verification, a credential or assertion can be reused in places it was never meant to reach. That can enable confused deputy behaviour, overprivilege, or invisible handoff abuse.
Impact: One compromised agent, token, or trust relationship can expose multiple downstream tools and datasets, especially when delegation chains are long or cross-organisational. The attacker does not need to break the protocol, only to exploit the gap between transport standardisation and identity governance.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP and A2A expose agent identity and delegation abuse across tool and peer hops. |
| ASI07 — Insecure Inter-Agent Communication | A2A creates trust handoffs that can fail when inter-agent communication is weakly authenticated. | |
| Recommendation — Constrain agent authority and validate each delegated action before execution. Authenticate inter-agent exchanges and reject unauthorised message paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP and A2A depend on how agents and tools prove identity and accept tokens. |
| NHI-05 — Overprivileged NHI | Protocol reuse can spread excessive agent or tool privilege across many connections. | |
| Recommendation — Use strong authentication and bound tokens to each protocol audience. Reduce each non-human identity to the minimum access needed for the task. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP servers, tools and agents authenticate to each other as services and workloads. |
| AC-6 — Least Privilege | The core risk is broad delegation and reusable authority across standardized agent paths. | |
| AU-3 — Content of Audit Records | Invisible handoffs and delegated actions require traceable records for attribution. | |
| Recommendation — Authenticate service-to-service interactions with explicit identity and trust checks. Limit each agent and tool to the minimum permissions required for the operation. Record who delegated what authority, to whom, and for which action. | ||
Practitioner Guidance
What to prioritise: Treat every MCP server, A2A peer, and delegated tool call as a distinct trust decision. The protocol path is not the trust model, so you need to define which identities may act, what they may access, and whether they may pass authority onward.
What to verify: Confirm that tokens are audience-bound, delegation is task-scoped, and handoffs are visible in logs and traces. If you cannot explain who authorised each hop, you do not yet have enough control for safe agent-to-agent interaction.
What good looks like: A mature deployment limits each agent to narrowly defined actions, expires authority quickly, and makes cross-agent or cross-tool access attributable without manual reconstruction.
Practitioner takeaway: Standardisation lowers integration friction, but identity risk stays high until you bound delegation, constrain scope, and make every handoff inspectable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org