A2A and MCP security hinge on runtime agent access control

At a glance

What this is: This is an analysis of how A2A and MCP create different security boundaries for AI agents, with the central finding that runtime access control matters more than protocol choice.

Why it matters: It matters because IAM, PAM, and NHI programmes now need to govern agent delegation, tool access, and task-scoped permissions in the same control plane.

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.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 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%).

👉 Read Apono's analysis of A2A vs MCP security for agent workflows

Context

AI agent identity risk is no longer limited to one protocol or one integration pattern. A2A governs delegation between agents, while MCP governs how those agents reach tools, data, and systems, so the real governance question is where authorisation is enforced and how far it travels with the task.

For IAM and PAM teams, the problem is familiar even if the actors are not: standing privilege, broad scopes, and unclear provenance create more risk as workflows become multi-step and machine-driven. That makes agent access control a lifecycle problem as much as a runtime one, especially when human requests are converted into agent-to-agent handoffs and then into tool calls.

Key questions

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. That means task-scoped credentials, explicit approval boundaries for sensitive actions, and logs that record both the tool selected and the identity used. If the agent can change its plan, the control model must be able to change with it.

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. IAM controls built for stable human sessions do not automatically cover agent-to-agent transfers, short-lived tasks, or downstream tool calls. The risk is authority propagation, not just authentication failure.

Q: What do teams get wrong about least privilege for AI agents?

A: They often stop at permission scope and ignore behavioural scope. An agent can have narrow access and still be risky if it can independently select targets, chain tool calls, and trigger irreversible actions. Least privilege is necessary, but it does not describe the agent's freedom to act.

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.

Technical breakdown

A2A delegation creates an authority chain, not just a workflow

A2A, or agent-to-agent communication, standardises how independent agents hand off work, context, and implied authority. The technical issue is that delegation is not the same as execution. Once one agent passes a task to another, the receiving agent may inherit context that looks operationally harmless but is actually authority-bearing, especially if it can continue the chain. That is why provenance matters: the initiating user, initiating agent, delegated agent, and any subsequent agent all become security-relevant identities. Without a clear authority envelope, A2A turns workflow orchestration into a propagation problem where permission boundaries blur across each hop.

Practical implication: Treat delegated agent work as a bounded authority transfer, not a convenience layer for automation.

MCP standardises tool access, but permission scope still decides exposure

MCP, or Model Context Protocol, connects agents to tools, prompts, data sources, and external systems through a standard interface. The protocol does not determine whether the resulting access is read-only, write-level, or administrative. That decision lives in the enterprise identity model, the token design, and the runtime policy attached to the tool call. In practice, MCP can be safely narrow or dangerously broad. A single reusable credential behind a tool endpoint can turn a harmless request into access to unrelated records, destructive actions, or downstream systems the task never needed.

Practical implication: Map every MCP connection to a specific operation and constrain the credential behind it to that operation only.

Runtime authorisation is the control point for agentic identity

The article’s most important technical point is that agentic systems need runtime authorisation, not just pre-provisioned access. Runtime authorisation evaluates the requesting identity, current task, target system, requested action, and allowed duration before the agent acts. That is different from static RBAC because the needed permission may change from one step to the next within the same workflow. When A2A and MCP are combined, the chain can move from user request to delegated agent to tool call in seconds. If access is not re-evaluated at each step, the workflow inherits privileges that no single actor actually needs.

Practical implication: Require task-scoped, time-bound approvals at each handoff and tool call instead of trusting the broader workflow.

Threat narrative

Attacker objective: The attacker or malicious workflow aims to convert legitimate task delegation into broader system access and unauthorised downstream action.

1. Entry occurs when a human request is passed into an agent workflow and then delegated from one agent to another through A2A, creating a chain where authority is inherited rather than re-decided.
2. Escalation occurs when the downstream agent reaches a tool or system through MCP using a credential or scope broader than the immediate task requires, allowing the action set to expand beyond the original intent.
3. Impact occurs when the combined delegation and tool access produce an unapproved business-system change, data exposure, or other downstream action that the initiating user never explicitly authorised.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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 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.

Chain-of-authority is the new identity boundary for agentic systems. The article makes clear that a task can start with a legitimate user request and still end in excessive access if delegation and tool permissions are not re-authorised at each hop. This is not a minor implementation detail. It is the failure mode that turns orchestration into privilege propagation, and practitioners should treat provenance as a first-class control objective.

Least privilege has to be task-definable at runtime, not only at provisioning time. The old assumption was that access could be assigned before execution because the actor and purpose were stable enough to predict. That assumption fails when agents can hand off work, select tools, and act within the same workflow window. The implication is that identity governance has to move from static rights assignment to context-bound decisioning.

Standing machine access becomes more dangerous when it is reusable across multiple agent hops. The article shows that broad tokens and generic service roles do not just widen access, they multiply it as tasks move across agents and systems. That makes over-scoping a compounding risk, not a single misconfiguration. Practitioners should read this as a warning that reusable credentials are now delegation fuel as much as authentication material.

Agentic identity governance now sits at the intersection of OWASP Agentic Applications Top 10 and NHI governance. A2A and MCP introduce both delegation abuse and tool misuse, which means the security model has to cover authority transfer, access scope, and action provenance together. For security architects, the important conclusion is that agent controls cannot be bolted onto application controls after the fact. They have to travel with the task.

From our research:

• 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.
• For a broader control model, see OWASP Agentic Applications Top 10 and how agent identity, tool misuse, and delegation risks fit together.

What this signals

Runtime authorisation will become the practical dividing line between controlled agent use and uncontrolled agent sprawl. The more workflows move from a user request to multiple agents and into MCP-connected tools, the less value static entitlement reviews provide on their own. Programmes should expect their existing IAM and PAM processes to be measured by whether they can follow the task, not just the identity.

Chain-of-authority will emerge as the more useful concept than single-actor privilege for agentic programmes. When a task can pass through several autonomous or semi-autonomous steps, the security question becomes who can hand off authority, who can receive it, and when it expires. That requires provenance, not just access inventory.

Dynamic least privilege for agents now belongs in the same planning cycle as NHI governance and agentic AI policy. The structural issue is not whether teams have a policy, but whether their control set can enforce task-scoped access when identity, context, and execution shift mid-workflow. For practitioners, that means aligning agent controls with NIST AI Risk Management Framework guidance and the OWASP Agentic Applications Top 10 rather than extending human-session assumptions into machine workflows.

For practitioners

• 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. Use the initiating identity, current task, target system, and action type as mandatory policy inputs.
• 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. Narrow each connection to one approved operation and one short-lived permission envelope.
• 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.
• Move agent access into PAM and NHI governance reviews Review agent workflows with the same discipline used for privileged human access and service accounts, focusing on standing access, scope creep, and offboarding when an agent or workflow changes.
• Test failure modes where one task becomes many actions Simulate benign requests that cross from A2A handoff into MCP tool use and verify that the final action cannot exceed the original business intent or duration.

Key takeaways

• A2A and MCP create different security boundaries, but both demand runtime authorisation tied to task, identity, and duration.
• The evidence points to a governance gap where delegation and tool access can compound into broader action than the original request allowed.
• Practitioners should shift from static access models to task-scoped controls, full provenance, and short-lived permissions for agent workflows.

Key terms

• A2A — Agent-to-Agent Protocol: An emerging communication standard enabling AI agents to authenticate and communicate securely with each other. A2A introduces new NHI challenges as each agent-to-agent interaction requires verified identities, scoped permissions, and auditable communication channels.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• 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.

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.

👉 Apono's full post covers the control questions, access chain, and runtime enforcement model in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.