TL;DR: Agentic AI shifts identity from passive prompt handling to runtime action, multi-step delegation, and tool use across LLMs, MCP servers, and downstream services, creating authentication and authorization gaps that current IAM patterns do not fully cover, according to Aembit. The core problem is not just stronger auth, but governance built on assumptions that no longer hold once agents decide, act, and recompose permissions dynamically.
NHIMG editorial — based on content published by Aembit: an analysis of agentic AI authentication, authorization, and MCP
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern authentication for agentic AI systems?
A: Security teams should govern agentic authentication as a chain of identities, not a single login event.
Q: Why do traditional least-privilege models struggle with AI agents?
A: Traditional least privilege assumes the system’s required permissions are known before execution begins.
Q: What breaks when MCP servers run with shared local trust?
A: Shared local trust breaks isolation because any process on the machine may be able to call the server, and the server may inherit privileges that were never intended for broad reuse.
Practitioner guidance
- Map every agentic trust boundary Document where the application, MCP client, MCP server, and downstream service each authenticate and where identity context is lost.
- Constrain runtime capability discovery Limit which tools and servers an agent can discover at runtime, and review any mechanism that lets the agent expand access after the task begins.
- Separate human intent from machine execution Do not assume a user’s permissions should automatically flow through the agent.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of the app, LLM, agent, MCP client, MCP server, and service chain.
- Concrete authentication patterns across OAuth 2.0, OAuth 2.1, API keys, Kerberos, and local process trust.
- A walkthrough of delegation, dynamic permissions, and identity blending between user and agent.
- The article's current-state observations on MCP implementation maturity and where shortcuts are still common.
👉 Read Aembit's analysis of agentic AI authentication and authorization →
Agentic AI authentication: what IAM teams need to rethink?
Explore further
Agentic authentication is no longer a point control, it is a chain-of-custody problem. Once an agent can discover tools, call services, and pass through MCP boundaries, the question is no longer whether a login succeeded. The question is which identity owns each action as the request moves across the chain, and whether that identity remains intelligible to governance tooling. Practitioners should treat agent authentication as delegated execution control, not just session establishment.
A few things that frame the scale:
- 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.
- Only 80% of organisations report that their AI agents have already acted beyond intended scope, including sensitive data sharing and credential exposure.
A question worth separating out:
Q: How do identity teams handle delegation when an AI agent acts on behalf of a user?
A: Identity teams need explicit rules for when the agent is allowed to inherit user intent and when it must use a narrower machine identity. If the downstream service cannot preserve upstream identity context, the delegation chain should be treated as broken, and the action should be reviewed as a separate governed event.
👉 Read our full editorial: Agentic AI authentication is breaking old IAM assumptions