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.
At a glance
What this is: This analysis says A2A and MCP solve different parts of the agent workflow, but both shift security to runtime access control rather than static permissions.
Why it matters: IAM, PAM, and NHI teams need to treat agent delegation and tool access as separate authorisation decisions, or broad credentials will compound risk across workflows.
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.
Context
A2A and MCP are two different protocols for agentic AI access. A2A governs delegation between agents, while MCP governs how agents reach tools, data, and external systems. The governance problem is not choosing one protocol over the other, but recognising that each creates a different authorisation boundary for non-human identity.
As more enterprise applications include task-specific AI agents, control models built around static application permissions become less useful. Security teams need to decide how access follows the task as it moves from human request to agent delegation to system action. That is the core identity challenge in this topic.
The article's central claim is that runtime access control matters more than protocol branding. The enterprise question is whether the requesting identity, task, target, action, and duration are enforced at the moment of use, rather than assumed from the workflow itself.
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. That means validating workload identity, scoping permissions to the defined job, and ending access when the job completes. This reduces what an AI agent can discover during a credential sweep and limits lateral movement if a foothold occurs. Runtime scoping works best when paired with vaulting and removal of exposed secrets.
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. If the receiving agent can delegate again or inherit broader context than it needs, the workflow can accumulate more privilege than the business task justified.
Q: What breaks when MCP credentials are hard coded?
A: Hard-coded credentials break lifecycle control. They are difficult to scope, hard to rotate, and easy to reuse across tools or environments, which means the same secret can outlive the team or use case that created it. In an MCP context, that creates a standing access path that is far broader than the interface suggests.
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.
Technical breakdown
A2A delegation creates a new authority boundary
A2A, or agent-to-agent communication, lets one agent hand work, context, or responsibility to another agent. Technically, that means authority can move laterally across a workflow instead of staying with the original initiating actor. The security problem is not message exchange by itself, but the implied decision to trust the receiving agent with some portion of the task and its context. Once delegation becomes possible, the question shifts from connectivity to bounded authority and whether the receiving agent may continue the chain.
Practical implication: treat every agent handoff as a separate authorisation event, not as an extension of the original request.
MCP turns tool access into runtime authorisation
MCP, or Model Context Protocol, standardises how agents connect to tools, prompts, APIs, and external systems. In practice, it is the point where an agent's request becomes a real system action, which makes scope the critical issue. An MCP connection can be narrow and task-scoped, or it can expose broad read and write authority behind a single integration. The protocol does not define the enterprise permission model, so implementation choices determine whether the agent has just enough access or far more than the task requires.
Practical implication: bind every MCP tool call to the specific operation, resource, and duration it needs.
Chain-of-authority risk appears when A2A and MCP are layered
When a task passes from human to agent, then from agent to agent, and finally into a tool call, the workflow becomes a chain of authority. Each hop can add scope, retain context, or reuse credentials in ways that are not visible at the end of the chain. That creates a governance problem for provenance, approvals, and expiry. The technical failure is not one bad protocol, but the loss of clear lineage between who initiated the work, who delegated it, and what access was exercised downstream.
Practical implication: preserve initiating user, acting agent, delegated agent, target system, action, approval, and expiry in the audit trail.
Threat narrative
Attacker objective: The objective is to turn a legitimate agent workflow into over-broad system access and unauthorised downstream action.
- Entry occurs when a legitimate user task is handed to an AI agent, giving the workflow an approved starting point rather than a forced compromise.
- Escalation happens when the first agent delegates to another agent or reuses a broad tool credential, expanding authority beyond the original task boundary.
- Impact follows when the downstream agent uses MCP access against a sensitive system and the workflow performs an action broader than the user intended.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Standing access assumptions do not survive delegated agent chains: Broad machine roles and reusable credentials were designed for stable executors, not for workflows that hand off authority mid-task. Once one agent can delegate and another can act, privilege is no longer tied to a single identity or a single boundary. The implication is that entitlement design must follow the delegation path, not the application perimeter.
Identity blast radius becomes the governing concept: When task context, token scope, and downstream action compound across agents and tools, the blast radius is defined by how far authority can travel before expiry or review. That is why dynamic least privilege belongs at the centre of agent governance. Teams should measure how much access a workflow can accumulate, not just whether the first step was approved.
Approvals must move from workflow design to execution-time enforcement: A workflow that looks well governed on paper can still execute an over-broad action if the runtime grant is wider than the task. This is the same governance failure seen in many NHI programmes, but agents make it more visible because authority is continually reassembled. Practitioners need execution-time controls that can narrow, observe, and revoke access as the task changes.
A2A and MCP are converging pressure points for NHI governance: The article shows that agent delegation and tool access are no longer separate concerns. The same identity programme now has to govern who can hand off work, what can be passed along, and which external systems can be touched at each step. That pushes IAM, PAM, and NHI teams toward a single runtime governance model.
From our research library:
- 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.
- Read next: Agentic AI Identity Guide
What this signals
Identity blast radius is now a workflow property: Once delegated agents can inherit context and then use MCP to reach systems, the real risk is not one over-privileged token but the cumulative authority that a task can assemble. Programmes that only review the first actor in the chain will miss the actual control point.
Runtime enforcement has to replace inherited trust assumptions: Access models built for stable service accounts do not map cleanly to agentic workflows that recompose privilege mid-task. The practical shift is from provisioning-time entitlement confidence to execution-time decisioning, with expiry and provenance attached to every hop.
A growing agent estate also changes how teams should think about auditability and response. If the chain of authority is not preserved, investigators may know that an action happened but not which user, agent, or delegated step made it possible.
For practitioners
- 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. Each layer should evaluate requesting identity, task context, target resource, action type, and expiry before permission is granted.
- 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. Grants should expire automatically when the task completes or changes scope.
- 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.
- Audit agent workflows for scope creep Identify where an approved request can expand into broader reads, writes, or administrative actions after a handoff or tool call. Focus on workflows where the first step is narrow but the downstream action is not.
Key takeaways
- A2A and MCP solve different problems, but both require execution-time controls because static entitlements cannot safely follow delegated agent workflows.
- The main governance risk is compounded authority across handoffs, not the protocol choice itself.
- Teams need provenance, expiry, and task-bounded grants or agentic workflows can turn legitimate requests into over-broad system action.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent delegation and runtime privilege are the article's core security issue. |
| Recommendation — Bind agent actions to least-privilege runtime grants and block privilege inheritance across handoffs. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article warns against broad machine roles and reusable credentials in agent workflows. |
| Recommendation — Scope non-human credentials to task-level access and remove standing privilege from agent paths. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Network Access Devices) | The article centres on services and agents authenticating to systems through controlled credentials. |
| Recommendation — Use IA-9 controls to constrain how service-like actors authenticate and access downstream resources. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime authorisation and entitlement scoping are the article's primary governance concern. |
| Recommendation — Apply PR.AA-05 to ensure agent access is authorised per task, target, and duration. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes how delegated access and broad tokens can expand reach across systems. |
| Recommendation — Map agent workflow exposure to credential access and lateral movement to prioritise containment. | ||
Key terms
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Chain of Authority: Chain of authority is the sequence of identities and approvals that explains how a task moved from request to action. In agentic environments, it is the evidence needed to prove who initiated work, which agent delegated it, which tool executed it, and whether the resulting access stayed within bounds.
- Delegation Boundary: A delegation boundary is the line that separates what a person, service account, or agent may do directly from what it may do on behalf of someone else. It matters because runtime access should follow the delegated relationship, not expand into broad inherited privilege.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 22, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org