AI agent stacks fail when identity is bolted on last

At a glance

What this is: This is a layer-by-layer map of AI agent architecture, showing that auth, authorization, and auditability have to span the full stack, not sit only at the front door.

Why it matters: IAM, NHI, and PAM teams need this because agentic systems change how identity, delegation, and approval boundaries work across human users, non-human principals, and tool access.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read WorkOS's analysis of the building blocks of an AI agent

Context

AI agent architecture is not just a model question. The primary governance problem is that identity and authorisation must be enforced across the user surface, orchestration layer, tools, model calls, and downstream services, because each layer can widen the blast radius if access is assumed rather than checked.

For IAM and NHI programmes, the important shift is that an agent is not a single control point. It is a principal that can act across services, carry delegated access, and produce actions that need auditability and approval boundaries, especially where MCP servers and session-scoped access are involved.

Key questions

Q: How should security teams govern AI agents that call external tools?

A: Treat the agent as a distinct principal, not just a user session with automation attached. Enforce authentication at every layer, scope each tool to the minimum required action, and log the initiating user, the agent identity, and the tool call. That creates a defensible access chain and reduces the blast radius if the agent behaves unexpectedly.

Q: Why do AI agent systems need session-scoped access instead of long-lived tokens?

A: Because agentic workflows often outlive the original human intent and can continue using delegated access after the task is finished. Session-scoped access keeps authority tied to one bounded job, then removes it before the agent can reuse the same token elsewhere. That is a stronger control than relying on later review or manual revocation.

Q: What breaks when MCP tools are exposed without access scoping?

A: The agent can discover and invoke capabilities that were never intended for that task, which turns tool discovery into ambient authority. Without scoping, authentication alone does not limit what the agent can do. The result is larger blast radius, weaker auditability, and more difficult incident reconstruction when a call goes wrong.

Q: How do IAM and PAM teams account for agent actions in audit trails?

A: They should log the human requester, the agent principal, the tool or service called, the permissions used, and the outcome. That separation matters because agent behaviour is not the same as user behaviour, even when the agent acts on behalf of a person. Clear attribution is the only way to support review, compliance, and containment.

Technical breakdown

Why AI agent auth must run through every layer

In an agent stack, authentication and authorisation cannot live only at the app boundary. The user authenticates at the surface, the orchestrator may authenticate as an agent principal, and tool calls often traverse MCP or API credentials that need their own verification. If any layer treats downstream access as implicitly trusted, the system inherits an overly broad delegation chain. That is why agent systems need identity continuity, not just login. The audit trail must also show which human initiated the request, which agent executed it, and what access was used.

Practical implication: define and verify identity at every handoff, not just at initial sign-in.

MCP servers, tool permissions, and runtime access scoping

MCP exists to externalise tools so agents can discover and call them over a network instead of shipping every integration inside the agent process. That improves operability, but it also creates a security boundary that needs explicit authentication, permission scoping, and logging. Without runtime scoping, an agent may discover tools it should not use or keep access longer than the task requires. The architectural risk is not only credential theft, but tool overreach through ambient authority. In practice, MCP should behave like a governed capability bus, not a convenience layer.

Practical implication: scope each MCP tool to the minimum callable action and require verifiable identity before execution.

Session-scoped access versus long-lived delegated tokens

Traditional OAuth patterns were designed for human workflows where long-lived connections are acceptable. Agentic systems change that assumption because the actor may continue acting after the original user intent has ended. Session-scoped access limits the token lifetime to a specific task, then removes renewal authority from the agent itself. That is a material control shift because the point is not simply rotation, but bounded delegated authority. It reduces the persistence of access that an agent can carry into unrelated workflows or future prompts.

Practical implication: use session boundaries to contain agent access to one task, not one relationship.

NHI Mgmt Group analysis

Identity architecture is now part of the agent runtime, not a peripheral control. Once an AI agent can choose tools, sequence actions, and continue across multiple calls, auth becomes a runtime dependency rather than an upstream gate. That matters because the stack no longer has a single trust point. Practitioners should treat identity as an execution-plane design problem, not an afterthought.

Long-lived delegated access is the wrong default for agentic systems. Human-oriented OAuth patterns assume the same actor remains in control long enough for review and revocation to make sense. In agent systems, that assumption weakens because the actor can continue to act independently through tools and memory. The implication is that access governance must move from durable delegation to task-bounded authority.

Agent as principal is the named concept that most programmes still under-model. The article makes clear that an agent needs its own identity, not just a user token borrowed from the person who requested the task. That distinction is central to auditability, policy enforcement, and blast-radius containment. Practitioners should stop treating the agent as a hidden implementation detail.

MCP concentrates both operational flexibility and governance risk. Moving tools into discoverable servers makes integration easier, but it also creates a single place where authentication, tool scope, and audit logging must be disciplined. The governance question is not whether MCP is useful. It is whether tool discovery is being matched by equivalent control over what the agent can actually invoke.

The stack exposes an assumption collapse in human-centric authorisation models. Access review processes were designed for actors whose privileges remain stable long enough to be observed and recertified. That assumption fails when the actor is an agent that can acquire, use, and release access across short execution windows and delegated tool calls. The implication is that identity governance must account for transient machine decisions, not only stable human entitlements.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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.
• For the broader control model, OWASP Agentic AI Top 10 is a useful next reference for tool misuse, prompt injection, and identity abuse.

What this signals

Agent principal: programmes that still model the agent as a hidden workflow component will struggle to assign accountability, apply policy, or reconstruct incidents. The operational shift is not just more logging. It is a different identity object that must be governed alongside the human who initiated it and the services it can reach.

With 92% of organisations saying governing AI agents is critical to enterprise security, but only 44% having implemented any policies, the gap is now one of execution rather than awareness, according to AI Agents: The New Attack Surface report.

Teams should expect MCP-style tool discovery and session-scoped access to become a standard design pressure, not a niche pattern. That will force IAM, PAM, and application teams to agree on who can authorise task boundaries, who can renew them, and how the agent's own identity is represented in policy.

For practitioners

• Map identity controls to every agent layer Document where authentication, authorisation, and logging occur at the user surface, orchestrator, tool boundary, and downstream service level. If any layer inherits trust from another without an explicit check, the agent stack has an unmanaged identity gap.
• Scope MCP tools as discrete governed capabilities Limit each tool to the smallest meaningful action, then validate the caller before allowing execution. Where possible, pair tool access with policy checks and logging that show who initiated the session and which tool the agent used.
• Replace long-lived delegation with task-bounded sessions Use session-scoped access for agent workflows that touch external services or sensitive data. When the task ends, the access should end as well, with no agent-driven renewal path that extends the original approval.
• Separate agent identity from human identity in audit trails Record the initiating user, the executing agent principal, the tool invoked, the arguments used, and the outcome returned. That separation is essential for incident response, policy review, and proving whether the agent stayed within its authorised task.

Key takeaways

• AI agent architecture changes identity governance because auth, authorisation, and audit need to span the full execution chain.
• Long-lived delegated access and review-based controls are a weak fit for agents that can act across short, task-bounded sessions.
• Practitioners should model the agent as a distinct principal, then enforce scoped tools, bounded sessions, and attributable logs around it.

Key terms

• Agent As Principal: An agent as principal is an AI system treated as its own authenticated and authorised identity rather than as an invisible extension of the user. This model is necessary when the agent can call tools, hold permissions, and leave an audit trail that must distinguish its actions from the human requester.
• Session-Scoped Access: Session-scoped access is delegated permission that exists only for the duration of a specific task or interaction. In agentic systems, it prevents long-lived tokens from becoming persistent authority and limits the chance that an agent can keep using access after the original approval should have ended.
• Mcp Server: An MCP server is a network-exposed service that publishes tools for agents to discover and invoke at runtime. It centralises tool access, but also creates a governance boundary where authentication, permission scoping, and logging must be enforced before the agent can execute a call.
• Fine-Grained Authorization: Fine-grained authorisation checks access at the level of a specific resource, action, or relationship rather than broad role or scope assignment. For agents, that precision matters because broad permissions can turn a single prompt or tool misuse into a much larger blast radius.

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 building or maturing an IAM programme, it is worth exploring.

This post draws on content published by WorkOS: The building blocks of an AI agent. Read the original.