Notifications
Clear all
Topic starter
22/07/2026 4:37 pm
TL;DR: A2A expands agent-to-agent delegation while MCP expands agent access to tools and systems, and the article argues that neither protocol is inherently more secure because both create different trust boundaries, according to Apono. The real control point is runtime authorisation tied to requesting identity, task, target, action, and duration, because standing access and broad machine roles let agent workflows compound risk across layers.
NHIMG editorial — based on content published by Apono: A2A vs MCP: Which Is More Secure?
By the numbers:
- By the end of 2026, task-specific AI agents are expected to appear in 40% of enterprise applications, up from less than 5% in 2025.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
Questions worth separating out
Q: How should security teams govern AI agents that choose tools at runtime?
A: Security teams should treat runtime tool choice as a governed access event, not a normal application call.
Q: Why do A2A and MCP create new identity risk for enterprise IAM?
A: Because they move access decisions from a single login boundary into a chain of delegation and tool execution.
Q: What do teams get wrong about least privilege for AI agents?
A: They often stop at permission scope and ignore behavioural scope.
Practitioner guidance
- Define runtime approval boundaries for agent handoffs Require each delegated task to carry explicit limits on context, action scope, and whether the receiving agent may delegate again.
- Replace reusable broad tokens with task-scoped credentials Audit MCP connections for credentials that can read, write, or administer more than the immediate task requires.
- Preserve end-to-end provenance across agent chains Log the initiating user, initiating agent, delegated agent, tool call, target resource, approval decision, and expiry together so security teams can reconstruct the full chain of authority.
What's in the full article
Apono's full analysis covers the operational detail this post intentionally leaves for the source:
- A step-by-step breakdown of how A2A delegation and MCP tool access interact inside a real agent workflow.
- Operational examples of how task scope, duration, and tool permissions should be evaluated at runtime.
- The article's table of control questions for origin, boundary, context, authority, and expiry.
- Practical guidance for reducing standing machine access before agent workflows inherit it.
👉 Read Apono's analysis of A2A vs MCP security for agent workflows →
A2A vs MCP: where do runtime controls need to live now?
Explore further
22/07/2026 4:42 pm
Runtime access control for agents is now a governance baseline, not an optimisation. A2A and MCP together show that the security problem is no longer just who can log in, but which identity can delegate, which identity can act, and how long that authority persists. That is a structural shift for IAM, PAM, and NHI programmes. Teams that still anchor control design to static entitlement reviews are already behind the operational reality.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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 AI agent delegation chain causes an unauthorised action?
A: Accountability depends on whether the organisation can reconstruct the chain. If logs capture sender identity, recipient identity, task ID, delegation depth, and validation results, investigators can pinpoint the failing handoff. Without that trail, responsibility becomes ambiguous across the orchestration layer and the individual agents.
👉 Read our full editorial: A2A and MCP security hinge on runtime agent access control
