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.
Editorial analysis by NHI Mgmt Group, 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.
Key questions
Q: How should security teams implement runtime-scoped access for AI agents and machine workloads?
A: Security teams should replace standing credentials with access issued only for the task at hand.
Q: Why do agent-to-agent handoffs increase access risk?
A: Agent-to-agent handoffs increase risk because authority can move beyond the original requester and be reissued without the same level of scrutiny.
Q: What breaks when MCP credentials are hard coded?
A: Hard-coded credentials break lifecycle control.
Practitioner guidance
- Define separate runtime policies for delegation and tool access Create one policy layer for agent-to-agent handoff and another for tool and system actions.
- Replace reusable agent credentials with task-bounded grants Remove broad tokens and standing machine roles from agent workflows where the access can be narrowed to a single operation.
- Preserve full provenance across the delegation chain Log initiating user, initiating agent, delegated agent, tool call, target system, approval state, and access duration so downstream action can be traced back to the source request.
Bottom line: A2A and MCP solve different problems, but both require execution-time controls because static entitlements cannot safely follow delegated agent workflows.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
22/07/2026 4:42 pm
Runtime authorisation, not protocol choice, is the real control plane for agentic access: A2A and MCP solve different coordination problems, but both fail if access is pre-baked into the workflow. The security decision has to be made at the moment of action, against the requesting identity, task, target, and duration. Practitioners should stop treating the protocol layer as the trust boundary.
A few things that frame the scale:
- Gartner predicts that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024, and that 15% of day-to-day work decisions will be made autonomously.
A question worth separating out:
Q: What should teams do when a legitimate agent workflow becomes too broad?
A: They should re-scope the workflow so each handoff and tool call has its own approval boundary, then revoke any persistent access that allowed the workflow to expand. The key test is whether the downstream action still matches the original task, not whether the first step was legitimate.
👉 Read our full editorial: A2A and MCP security hinge on runtime agent access control
This post was modified 5 days ago by NHI Mgmt Group