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.
Why This Matters for Security Teams
A2A and MCP change the identity problem from “who signed in” to “what is allowed to happen next.” That matters because enterprise IAM was built around relatively stable human sessions, not chains of delegated agent actions and tool calls. Once an agent can pass context to another agent or invoke an MCP tool, the security boundary shifts from authentication to authority propagation. That is exactly where legacy role models become brittle.
Security teams often assume least privilege will hold if the initial agent identity is strong, but that assumption fails when downstream actions are decided at runtime. NHI research consistently shows how quickly this becomes operational debt, especially when secrets and access paths are spread across teams and environments. NHI Management Group’s Ultimate Guide to NHIs and the 52 NHI Breaches Analysis both show that non-human compromise tends to become visible only after access has already expanded.
Current guidance from the OWASP Agentic AI Top 10 and the NIST Cybersecurity Framework 2.0 points toward stronger runtime governance, but the control model is still emerging. In practice, many security teams encounter agent-to-agent privilege drift only after a tool chain has already executed outside the intended trust boundary.
How It Works in Practice
In an A2A or MCP environment, identity has to follow the workload, not just the login event. The practical model is closer to workload identity plus runtime authorisation than to a static user session. An agent presents cryptographic proof of what it is, receives narrowly scoped access for a specific task, and then loses that access when the task ends. That is why ephemeral credentials, short token lifetimes, and request-time policy checks are now central to agent governance.
A useful pattern is to separate three layers:
- Workload identity: the agent proves itself with OIDC-style tokens, SPIFFE/SPIRE identities, or equivalent machine identity primitives.
- Intent-based authorisation: policy evaluates what the agent is trying to do, in context, rather than relying only on pre-assigned roles.
- JIT access and revocation: secrets or tokens are issued per task, are short-lived, and are revoked automatically when the action completes.
This is the direction recommended by the Top 10 NHI Issues, which highlights how static credentials and overbroad entitlements fail under machine-scale automation. It also aligns with the agentic guidance in OWASP Top 10 for Agentic Applications 2026, where chained tool use and prompt-influenced execution can turn a narrow task into broad reach if policy is not evaluated at runtime.
For enterprise IAM teams, the operational question is not whether the agent authenticated successfully, but whether each downstream action was authorised with full task context, provenance, and expiry. These controls tend to break down when legacy applications cannot accept short-lived tokens or when MCP tools reuse broad service accounts across multiple workflows.
Common Variations and Edge Cases
Tighter delegation controls often increase integration overhead, requiring organisations to balance stronger containment against developer friction and legacy compatibility. That tradeoff is real, especially in environments where MCP servers, workflow engines, or internal APIs were designed for persistent service accounts rather than per-task credentials.
There is no universal standard for this yet, so implementation choices vary. Some teams use policy-as-code with real-time evaluation, while others add brokered token exchange between the agent and each tool. Best practice is evolving toward context-aware authorisation, but the exact mechanism depends on whether the agent is acting alone, within a multi-agent pipeline, or as a delegate of a human request.
Edge cases matter. If an agent can call a privileged system through multiple hops, the real risk is not one compromised identity, but one identity that can continuously mint or inherit more authority. That is why the Ultimate Guide to NHIs stresses short-lived access and strong governance, while the Analysis of Claude Code Security is a useful reminder that tool-enabled AI can cross from assistance into action very quickly. This guidance breaks down when organisations treat agent permissions as static service configuration instead of continuously evaluated authority.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2A-01 | A2A delegation creates chained agent authority and runtime trust decisions. |
| CSA MAESTRO | MAESTRO-02 | MAESTRO addresses agent orchestration, tool access, and delegated execution risk. |
| NIST AI RMF | AI RMF covers governance for autonomous systems whose actions change at runtime. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived secrets and rotation are central when agents call tools dynamically. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust is relevant because trust must be re-evaluated for each tool invocation. |
Use AI RMF governance to assign ownership, monitor agent behaviour, and manage escalation paths.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
