AI Agent Identity Governance: A Five-Layer Architecture for Securing Agents and MCP

Why Traditional IAM Is Hitting a Wall

Identity and Access Management (IAM) is nothing new — but PlainID co-founder and CTO Gal and iC Consult CTO Andrei made a sharp observation in a joint webinar: when it comes to AI agents, the IAM systems we've spent the past two decades building are running up against the limits of their original design.

Tracing the evolution of IAM, Andrei noted that the early focus was entirely on employees — using single sign-on and streamlined onboarding to improve efficiency and cut costs. Identity counts were small, manageable, and relatively static. The scope then expanded to consumer identities (far greater in volume), then to non-human identities (NHI) (essentially uncountable). The emergence of AI agents has fundamentally changed both the scale and the nature of identity management.

Gal emphasized that agent identities are no longer predefined or predetermined — they are dynamically created and generated per task. Even more critical is the shift in scope: a human employee's permissions can be slowly refined through role assignments over years, but a defining characteristic of AI agents is precisely their ability to do far more than expected. This high degree of dynamism is the core reason traditional IAM architectures struggle to keep up.

The Five-Layer Agentic IAM Architecture Blueprint

The central framework proposed by both experts is a five-layer architecture built around the concept of an "access path." They repeatedly stressed one easily overlooked prerequisite: when discussing agent security, resources must always remain in view.

Andrei specifically cautioned that many people focus entirely on the agent itself and its behavioral flow, forgetting the bigger picture — agents ultimately exist to access resources the enterprise provides: MCP tools, API services, data sources, knowledge bases, and various applications. "Without the resource in scope, the entire discussion is somewhat meaningless." Policy must therefore always answer one question: what is this agent permitted to do?

Layer 1: Agent Identity

On agent identity, Andrei corrected a common misconception: the idea that "an AI agent is just a service account" is wrong. An agent may use a service account, but it is far more than that — it will often collect multiple credentials for legitimate reasons. More importantly, the foundational principle is: agent identity must never be equated with user identity, and the impersonation pattern must be firmly avoided.

Gal added that agent identity management must be adapted to their just-in-time nature — many agents are short-lived, created for a specific task.

Non-Human Identity (NHI) is a rapidly expanding category within IAM, encompassing service accounts, API keys, OAuth clients, machine certificates, and any credential not belonging to a real human user. Unlike human users, NHIs typically have no active login behavior, are difficult to harden with MFA, and their lifecycle management is easily neglected — long-unrotated keys and uncollected permissions are pervasive across enterprises. At the technical level, AI agents do use NHI credentials (such as service account tokens) to call APIs, but their governance complexity far exceeds traditional NHI: a single agent may dynamically request and combine multiple credentials within one task, and may exist for only minutes. This renders the lifecycle management processes designed for "long-lived service accounts" essentially ineffective in agent scenarios.

Layer 2: Discovery and Registration

"If we don't know they exist, we simply cannot manage them." Gal admitted that customers are still figuring out where to manage agents. The reality is that enterprises won't have a single registry — agents will be scattered across multiple hyperscale cloud providers and multiple agent frameworks, "often unaware of each other's existence."

Andrei offered a simple but profound observation: every application running in the enterprise, every subscribed SaaS product, either already has agents today, will have them soon, or will at minimum expose an MCP interface — "otherwise it has no reason to exist." Discovery and visibility, combined with establishing clear ownership for every agent, is therefore what organizations should be doing right now.

Gal went further, arguing that owning individual agents isn't enough — governance needs to operate at the level of "agent classes/patterns." He used the analogy of templates and instances: a "travel management" agent blueprint can be authorized to access the company's booking system, while the instance serving Andrei personally should only access his own email and calendar — different levels correspond to different levels of access complexity.

Policy Management: From Roles to Dynamic Context

Layer three is policy management, and it's the heart of the entire discussion. Gal was explicit: roles don't work anymore. Static, predefined provisioning cannot cope with this scale and speed. The answer is policy — which can capture the contextual and dynamic nature of agent activity and govern entire agent workflows.

One frequently overlooked point: an agent isn't a single operation but a series of interconnected operations. You must build context around the entire workflow to truly govern it.

Andrei introduced the concept of cross-identity logic. When a user gives an agent a task and the agent accesses systems in the background, you must determine whether this is behavior permitted to occur on behalf of that user. In the future, agents will also connect to other agents, forming call chains — "and we absolutely do not want to pass the initial user's token to some downstream agent."

Gal added that delegation and chained identity are key concepts. Access control is no longer about "can I access something," but about the combined permissions of multiple identities. Take a travel agent as an example: the real question isn't whether the agent itself can access specific customer information, but the binding relationship between the agent and the person behind it — a person working in Europe should, through that agent, only be able to access European customers, not American ones. Policy must account for all identities involved in the process simultaneously.

Enforcement and MCP: Externalize the Authorization Logic

Andrei was blunt in his warning about MCP security: many of the MCP-related incidents that have occurred over the past few months have unfortunately stemmed from broken authorization concepts. Applications are often built on roles that map AD groups to specific permissions — a mechanism that simply doesn't scale in the agent world.

His core recommendation: pull authorization logic out of the application layer and hand it to a dedicated authorization enforcement and policy management system, rather than trying to solve it inside that small MCP interface — that's a dead end.

On "where to enforce," Gal's view is that there's no single right answer: starting at the gateway is simplest and non-invasive, requiring no changes to code or agents. But a gateway can only see what it sees, so you also need integration with agent frameworks, enforcement at the MCP server, and even pushing down to the data layer. Keep in mind that downstream applications and SaaS systems can typically only see what's in the token — they can't see all the identities involved in the workflow.

On "what to enforce," Gal's principle is: enforce whatever matters to you. The prompt layer can serve as a first gate — if the request itself is unauthorized, intercept it at the prompt stage. At the data layer, unauthorized data should not enter the agent workflow at all; masking alone is insufficient.

For MCP control, Gal stressed that simply determining "can this tool be used" is far from enough. You also need to understand who is using it, what the intent is, and how the tool is being used. For example: the same travel agent sending a notification to a customer is a legitimate use, but using it to mass-email a large group of non-target customers is abuse. To truly govern this, you must understand the manner and purpose of tool usage.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic and now adopted by multiple AI frameworks. It provides large language models with a standardized interface for tool invocation and context access. MCP servers act as "tool providers," and agents send requests to them via MCP clients to invoke external capabilities — such as querying a database, sending email, or calling internal enterprise APIs. Because MCP itself is a lightweight protocol layer with no built-in fine-grained authorization mechanism, early implementations commonly relied on passing identity tokens from the caller directly, leaving permission decisions to the application itself. This pattern is particularly dangerous in chained agent call scenarios: intermediate nodes cannot verify the complete identity chain of a request, nor can they enforce least-privilege access control. Externalizing authorization decisions to a dedicated Policy Decision Point (PDP) — and having the MCP layer only execute policy results — is the mainstream recommendation in current security architecture.

Tokens, Traceability, and Observability

In response to an audience question about "how to terminate a user token at runtime and exchange it for one representing the agent's identity," Andrei identified the worst pattern: a local MCP server directly forwarding the end-user session and impersonating the user to access target systems — which means the target system can no longer detect that it's actually an agent operating, and traceability is completely lost.

The correct approach is to use tokens that clearly indicate "the agent is acting on behalf of the end user." He mentioned standards such as transaction tokens, which include claims for subject, client, audience, and the full action chain. Downstream systems should also not reuse the same token, but instead obtain narrow-scoped tokens through token exchange protocols — passing a highly privileged token everywhere was never best practice, and in the agent era it amplifies the risk significantly.

The final layer is audit and observability. It's not just about enforcing access control — it's about understanding what happened, why it was enforced that way, which policy applied, and what evidence exists to prove a given action was approved or denied.

Andrei tied this closely to responsibility and accountability. He described a shift in how work gets done: in the future, humans will be more like "supervisors" managing teams of 10, 15, or more agents. Even if you can't control every step, as long as you issued the instruction, granted the access, and exist as the human-in-the-loop, you are responsible for their activities — just as a manager is accountable for their team. Audit and observability capabilities are precisely what underpins this accountability.

Transaction Tokens are a token mechanism being standardized by the IETF OAuth Working Group (draft: draft-ietf-oauth-transaction-tokens), specifically designed to solve identity propagation in microservice and agent chain call scenarios. The core idea: at the entry point of a call chain, an authorization server issues a tamper-proof token containing the original subject, initiating client, target audience, and call-chain context. Downstream nodes can verify this token to confirm "who, under what authorization, and for what purpose" the current request originated. Compared to directly forwarding user access tokens, transaction tokens offer a key advantage: downstream systems can always distinguish between "user acting directly" and "agent acting on behalf of a user," giving audit logs a complete causal chain. Token exchange (RFC 8693) is then used to issue narrow-scoped tokens for each downstream node, strictly limiting the actual permission range of individual nodes.

How to Get Started: Don't Wait — Start Now

When asked how to begin, Andrei's answer was concise and direct: this space is moving so fast that there's always something new causing confusion — "but don't wait." More important than agonizing over where to start is actually starting AI security work.

He suggested beginning with discovery — using a structured approach to clarify ownership, purpose, and intent. Alternatively, start with a pilot covering a limited number of agents and resources, and first validate what "good" looks like in your own environment. "What matters is not what you do, but that you do it now" — because agents are being created constantly, and they must be brought back under governance as quickly as possible.

This discussion, jointly presented by PlainID and iC Consult, is fundamentally about extending the goals of zero trust architecture to a new class of actors — AI agents. The goal hasn't changed, but the actors have, and the architecture must evolve accordingly.