Agentic AI authentication is breaking old IAM assumptions

At a glance

What this is: This is an analysis of how agentic AI changes authentication and authorization across LLM apps, MCP, and service integrations, with the key finding that old trust and privilege assumptions break once agents can act at runtime.

Why it matters: It matters because IAM, NHI, and lifecycle teams will need to govern agents, MCP servers, and delegated service access without assuming static intent, fixed scopes, or human-paced approval loops.

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.

👉 Read Aembit's analysis of agentic AI authentication and authorization

Context

Agentic AI changes the identity problem because the system is no longer just answering questions. It is making decisions, selecting actions, and calling tools across multiple trust boundaries, which means authentication and authorisation can no longer be treated as a single application control.

The article argues that the familiar mental model of a passive LLM is already too small for current deployments. Once the agent sits in a loop, talks to MCP servers, and reaches into downstream services, IAM teams have to think about delegation, scope, and accountability in a much more dynamic way.

For identity programmes, the most important shift is that the effective subject is no longer only a user or a workload. The governance target becomes the agent itself, plus the chain of identities and permissions it can invoke at runtime.

Key questions

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. Each hop, from the app to the MCP client, from the MCP server to downstream services, and from one agent to another, may use different credentials and trust assumptions. The control objective is to preserve identity context and constrain delegation at every boundary.

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. AI agents often discover new needs while working, such as switching from read-only access to write or create actions. That makes static provisioning incomplete, because the real privilege set emerges during runtime rather than during design.

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. This creates a local attack surface where authentication is bypassed or reduced to process proximity instead of explicit authorisation.

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.

Technical breakdown

Agent loops and runtime tool selection

An agentic system is not a static request-response interface. It runs in a loop, keeps context from prior outputs, and uses that context to decide the next action, which can include calling tools or asking for new capabilities. The LLM still only returns text, but the surrounding agent interprets certain output as instructions to act. That distinction matters because the control point moves from prompt handling to execution governance, where identity, timing, and scope all matter at once.

Practical implication: teams need to map where text becomes action, because that is where authentication and authorisation must be enforced.

MCP authentication and delegated access

MCP standardises how an agent discovers and uses external capabilities, but it does not remove the trust problem. The MCP client authenticates to the server, the server authenticates to its target service, and each hop can use different mechanisms such as OAuth, API keys, Kerberos, or shared local process trust. The result is a chain of identity boundaries, not a single control plane. When the server acts on behalf of the agent or user, delegation becomes the core design issue, especially when downstream systems do not preserve upstream identity context.

Practical implication: identity architects should trace which hop owns the identity at each boundary and where delegation is lost.

Dynamic permissions and least privilege drift

The article’s strongest architectural point is that agents discover required permissions at runtime rather than only at design time. A task that begins as read-only can expand into write access, object creation, or access to adjacent systems once the agent encounters real-world constraints. That means least privilege is no longer a one-time provisioning exercise. It becomes a moving target shaped by the agent’s runtime path, the data it encounters, and the tools it is permitted to call.

Practical implication: privilege decisions must be reviewed against actual agent behaviour, not only against the original design intent.

Threat narrative

Attacker objective: The objective is to get an agent or integrated service to perform actions beyond the intended trust boundary by abusing delegated identity and runtime permission expansion.

1. Entry occurs when the agent or MCP client connects to a server through local process trust, API keys, or an OAuth flow, creating an initial identity boundary that may be weakly enforced.
2. Escalation happens when the agent discovers new tool needs at runtime and expands from read-only actions into broader write, create, or delegated service access.
3. Impact follows when the agent chain acts with permissions that outlive the original assumption set, allowing unintended changes, sensitive data exposure, or uncontrolled downstream actions.

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

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.

Least privilege was designed for stable intent, and that assumption collapses under runtime agent behaviour. The classic NHI governance premise is that developers can define required access before execution begins. That assumption fails when an agent discovers new requirements mid-task and requests additional capabilities to complete the goal. The implication is not merely that permissions need adjustment, but that precomputed privilege boundaries no longer describe the real execution path.

Identity context breaks when MCP servers act on their own service identities instead of the originating user or agent. This is the structural gap at the centre of the article: delegation chains often lose provenance at the point where the downstream service is invoked. When that happens, accountability becomes partial and remediation becomes ambiguous. Practitioners should treat identity propagation across AI toolchains as a design requirement, not an afterthought.

OAuth on its own does not solve agent governance because the authorisation question changes at every hop. Browser login, MCP client access, server-to-service access, and inter-agent calls each have different trust semantics. That fragmentation is why agentic AI should be evaluated through both OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, with NHI governance layered underneath. The practical conclusion is that one authentication pattern cannot govern the whole agent stack.

Dynamic capability expansion creates an identity blast radius that traditional access reviews will miss. The agent’s effective privilege set is shaped by runtime discoveries, not only by assigned scopes. That makes periodic review too slow to describe actual exposure, especially when the agent can chain tools or collaborate with other agents. Practitioners should treat post-execution evidence as primary governance data, not secondary telemetry.

From our research:

• 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.
• The governance gap is widening, so review OWASP Agentic Applications Top 10 for the control patterns practitioners are using to close it.

What this signals

Runtime capability discovery is becoming the new identity boundary for agentic systems. Once tools can be added or invoked mid-session, the programme has to govern behaviour rather than just access assignment. That makes agent telemetry and post-execution evidence more important than static approval records, especially for teams aligning to the OWASP Top 10 for Agentic Applications 2026.

The practical signal for IAM and NHI teams is that delegation, not authentication alone, will dominate the next wave of control design. If your programme cannot explain which identity acted at each hop, you do not yet have governable agent access. The operating model needs to cover human, machine, and agent identities in one lifecycle view.

Identity blast radius: agentic systems expand privilege through runtime discovery, so the real exposure is the maximum action set the system can reach in a live session. That means access reviews, PAM patterns, and secrets handling all need to be evaluated against executed behaviour, not assumed intent.

For practitioners

• Map every agentic trust boundary Document where the application, MCP client, MCP server, and downstream service each authenticate and where identity context is lost. Use that map to decide where delegation must be preserved and where separate service identities are unavoidable.
• 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. The goal is to stop permission drift before it becomes normal operating behaviour.
• Separate human intent from machine execution Do not assume a user’s permissions should automatically flow through the agent. Define when the agent must act as its own identity and when it must be blocked from inheriting broader human authority.
• Record agent actions as governance evidence Log tool selection, server calls, scope changes, and downstream service access in a format that supports review and incident investigation. Without this evidence, access reviews will miss the real behaviour of the system.

Key takeaways

• Agentic AI changes the identity problem by turning authentication into delegated runtime execution across multiple trust boundaries.
• The most important failure mode is assumption collapse: least privilege and review cycles were built for stable intent, not for agents that discover permissions mid-task.
• Identity teams should map delegation, preserve provenance, and govern actual runtime behaviour if they want to control agentic access safely.

Key terms

• Agentic AI: Software that can decide and take actions at runtime, not just produce outputs. In identity terms, the key issue is that access and execution become dynamic, so governance must cover the action path, not only the initial request. The subject may be a machine, but the accountability problem is often human-owned.
• Model Context Protocol: A standard for connecting AI agents to tools and services through a common interface. It reduces integration friction, but it also introduces a new identity boundary because the client, server, and downstream service can each rely on different authentication methods and delegation assumptions.
• Delegation chain: The sequence of identities and trust decisions that allows one component to act on behalf of another. In agentic systems, the chain may pass from a user to an agent, then to an MCP server, and finally to a downstream service. Governance fails when the chain loses provenance or scope.
• Identity blast radius: The maximum amount of access, data, or action an identity can reach if its runtime behaviour expands beyond the original design. For agentic systems, this is often larger than the provisioned scope because tools and permissions can be discovered or chained during execution.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Aembit: an analysis of agentic AI authentication, authorization, and MCP. Read the original.