Agent communication protocols leave authorization undefined for AI agents

At a glance

What this is: This analysis argues that agent communication protocols standardise messaging faster than authorization, leaving AI agents exposed to broad scopes, stale permissions, and weak revocation.

Why it matters: It matters because IAM, NHI, and PAM teams will need to govern agent-to-tool and agent-to-agent access with controls that assume runtime delegation, not static service-account style access.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Authzed's analysis of authorization gaps in AI agent communication protocols

Context

AI agent identity is becoming a governance problem because the agent, not the human, now makes runtime decisions about tools, tasks, and delegation. The security model changes when an identity can initiate actions, chain work to other identities, and continue operating across trust boundaries without a fresh human decision at each step.

The core failure is not communication standardisation. It is that protocols like MCP, A2A, and ACP describe how agents talk, but they do not fully define how permissions should be scoped, reduced, revoked, or consented to as the work moves between agents and resources.

Key questions

Q: How should security teams govern AI agent access when protocols leave authorization open-ended?

A: Treat authorization as a separate governance control rather than a protocol feature. Define who can do what, with which resource, for how long, and under which context, then enforce that policy centrally at runtime. If the protocol only standardises message exchange, it still needs an external policy layer to prevent over-broad access and stale delegation.

Q: Why do AI agents make least privilege harder to enforce than service accounts?

A: AI agents can change actions, tools, and delegation paths during execution, so a privilege set chosen at provisioning time may no longer match the task in progress. Service accounts usually follow a more stable pattern of use, while agents can branch, chain, and reuse access across multiple operations. That makes static scopes too coarse for agentic work.

Q: What breaks when revocation does not propagate across distributed agents?

A: Stale permissions continue to exist in caches, peers, or spawned sub-agents, so access that should have been removed remains usable. That creates a lifecycle failure, not just an authorization bug, because the actor can continue operating after the security team believes the entitlement is gone. In practice, the old access outlives the intended approval.

Q: Who is accountable when an AI agent shares data beyond its intended scope?

A: Accountability should sit with the team that defined the delegation boundary and the policy that allowed the handoff. If the system permits implied consent, broad scopes, or silent inheritance across agents, then the organisation owns the governance failure even if the individual action was taken by software. Audit trails need to show every approval boundary.

Technical breakdown

Why protocol authentication is not the same as authorization

MCP and A2A can define transport, message structure, and authentication, but authentication only proves that an entity is participating in the exchange. Authorization decides what that entity may do with which resource, for how long, and under what context. In agentic systems, those decisions cannot be treated as a generic token problem because the agent may change behaviour during execution, call different tools, or hand work to another agent. When authorization is left outside the protocol, implementers patch the gap with platform defaults that were designed for simpler service-to-service flows, not dynamic delegation chains.

Practical implication: treat protocol support as connectivity, not policy, and place authorization decisions in a dedicated control layer.

How coarse scopes expand the attack surface for agents

Standard OAuth scopes are often too broad for autonomous work. An agent given a role-like token may be able to read or write across an entire system when the task only needs a narrow object-level action. That is a problem of insufficient granularity of access control. In agentic environments, a single token can outlive the user intent, cover unrelated endpoints, and amplify compromise if intercepted or replayed. Fine-grained access control must express task, resource, and duration together, otherwise least privilege becomes a slogan instead of an enforceable model.

Practical implication: model agent permissions at task and resource level, then verify that scope matches the exact operation set.

Why revocation and consent break down across agent handoffs

Distributed agent systems introduce timing problems that classic identity controls handle poorly. If revocation signals arrive late, are cached locally, or are not synchronised across participants, an agent can continue acting on permissions that should already be gone. The same problem appears in consent flows. If a user approves one delegation and that approval is reused implicitly for later handoffs, the system loses purpose limitation and auditability. This is the new enemy problem in agent form: policy changes and resource changes no longer reach every actor in the same order.

Practical implication: require revocation propagation and explicit consent renewal at each meaningful delegation boundary.

Threat narrative

Attacker objective: The attacker wants durable, delegated access that survives the original task and enables broader action than the agent should have been allowed to perform.

1. Entry occurs when an attacker intercepts or obtains a bearer token or over-broad delegation token issued for an agent task.
2. Escalation happens when that token is replayed, reused across unrelated endpoints, or inherited by a sub-agent without scope attenuation.
3. Impact follows as the attacker keeps access after revocation, moves across trust boundaries, and abuses the agent chain to reach data or actions beyond the original task.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authorization for agents is now a governance layer, not a token detail. The article correctly shows that protocol standardisation does not solve the core policy problem, because autonomous agents need scoped, revocable, context-aware permissions. For identity teams, the important shift is that agent communication standards and access governance are no longer separable design choices. Practitioners should treat authorization as an independent control plane for agentic behaviour.

Least privilege stops being definable at provisioning time when the actor can change its own execution path. The article's strongest implication is that static scopes assume a fixed task, but autonomous agents can adapt, delegate, and select tools mid-session. That makes the old provisioning model structurally incomplete for agentic access. The implication is that identity governance must move from one-time entitlement assignment to runtime policy evaluation.

Insufficient granularity of access control is the named failure mode this protocol gap exposes. Broad OAuth-style tokens were designed for simpler service access, not for agents that need object-level, time-bound, and chain-aware permissions. When a single delegation token can span unrelated actions, the security model inherits excessive blast radius by default. Practitioners should read this as a category-level warning for every agent platform that treats scopes as an implementation convenience.

Revocation propagation is the control that breaks when distributed agents act asynchronously. The article shows how cached authorization state, delayed updates, and recursive delegation create stale permissions that outlive intent. That is not just a technical bug, it is a lifecycle failure in which access changes fail to reach all participants at the same moment. The implication is that offboarding and revocation logic for agents must be designed for distributed consistency.

Consent fatigue turns delegated approval into implied consent unless the system re-asks at the right boundary. Multi-agent workflows can obscure who is actually authorising which data exchange, especially when sub-agents inherit permissions from prior steps. That weakens accountability across human, NHI, and autonomous layers at the same time. Practitioners should expect auditability to fail first in the handoff chain, not at the initial login or token issue event.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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.
• That governance gap becomes more visible when you pair it with the OWASP Agentic AI Top 10, which frames the runtime control problem practitioners now have to close.

What this signals

Agent authorization is becoming a runtime governance problem, not a provisioning problem. As agentic systems spread, static entitlement reviews will miss the real decision point, which is the moment the agent selects a tool or forwards work. Teams should expect policy enforcement to move closer to execution, with stronger runtime checks for task, context, and delegation chain before action is allowed.

Insufficient granularity of access control will surface as the next major blind spot in agent programs. Once broad scopes are accepted as normal, teams lose the ability to explain why an agent had access to unrelated data or write paths. That is a programme risk as much as a technical one, because audit evidence will not match the actual behaviour of the system.

The practical signal to watch is whether your agent platform can prove purpose limitation end to end. If you cannot show which permissions were granted, which were inherited, and which were revoked at each handoff, you do not yet have governable agent identity.

For practitioners

• Separate transport from authorization control. Define policy outside MCP, A2A, or ACP messages, then enforce it at a central decision point that can evaluate task, resource, and context before every sensitive action.
• Replace broad scopes with task-bound permissions. Issue tokens that map to a single task or object set, and reject delegated access that covers unrelated endpoints, resources, or write paths the agent does not need.
• Design revocation to propagate across the full agent graph. Test whether permission removal reaches cached agents, remote peers, and spawned sub-agents before the original task can continue, and treat failed propagation as a control defect.
• Require explicit consent at each meaningful handoff. Do not let prior approval become implied consent for later data exchange, especially when agents forward information to another system or another autonomous actor.
• Audit delegation chains for scope attenuation failures. Check whether each hop reduces privilege, or whether permissions accumulate as work moves from agent to sub-agent to tool, creating avoidable blast radius.

Key takeaways

• Agent communication standards do not solve authorization, revocation, or consent by themselves.
• Broad scopes and stale permissions create the real security gap when AI agents act across trust boundaries.
• Identity teams need runtime policy, scope attenuation, and propagation-aware revocation before agentic systems can scale safely.

Key terms

• Agent Authorization: The policy layer that decides what an AI agent may do, with which resource, for how long, and under what context. In agentic systems, authorization must be evaluated at runtime because the actor can change tools, tasks, and delegation paths while it is already operating.
• Scope Attenuation: The reduction of privileges as a task moves across agents, sub-agents, or tools. Without attenuation, permissions can accumulate instead of narrowing, which breaks least privilege and increases the blast radius of a single delegated action or compromised token.
• Revocation Propagation: The process of ensuring that permission removal reaches every cache, peer, and delegated actor that may still honour the old access. In distributed identity systems, revocation is only effective when it arrives before stale authorization can be reused.

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.

This post draws on content published by Authzed: LLMjacking: How Attackers Hijack AI Using Compromised NHIs. Read the original.