The 5 Decisions IAM Cannot Make (But AI Agents Force You To)

Identity and Access Management has spent two decades getting good at a specific problem. Authenticate the user. Establish the workload identity. Issue a scoped token. Provision and deprovision accounts on a defined lifecycle. For human users, applications, and services that follow predictable execution patterns, IAM works.

AI agents are different.

They reason. They plan. They adapt their actions based on intermediate results. They call APIs they were not explicitly told to call. They delegate work to other agents. They accumulate context that persists across sessions. The execution path of a single agent task is not a predetermined code flow; it is a sequence of decisions made at runtime by a model whose reasoning is opaque to the systems trying to govern it.

The governance gap this creates is not an identity gap. The agents are authenticated. Their tokens are valid. The accounts are provisioned correctly. The gap is behavioral, and it lives in the runtime.

This Is Not an Argument Against IAM

Before going further, the foundational point: this post is not arguing against IAM. OIDC for agent authentication, OAuth for scoped token issuance, SCIM for lifecycle provisioning, and SPIFFE/SPIRE for workload identity in containerized environments all remain essential. Any AI agent governance architecture will rest on these standards. They are not optional, and they are not being replaced.

The argument is narrower and more specific. The standards above answer who an agent is and what it has been granted permission to access. They were not designed to answer whether an authenticated, properly tokenized agent should take a specific action at a specific moment in execution.

That is a different class of question. AI agents force enterprises to confront it. Below are five concrete decisions that illustrate the gap.

Decision 1: Should this agent call this API right now with these exact parameters?

A claims-processing agent at an insurance company is authorized to call the payment service to issue refunds. Its OAuth token has the correct scope. Its service account is in good standing. The API gateway accepts the request.

The agent is about to issue a $12,000 refund to a customer whose policy limits automatic refunds to $500 without human review. The token is valid. The scope is correct. Nothing in the IAM layer evaluates whether this specific call, with these specific parameters, in this specific business context, should be permitted.

What's needed is runtime evaluation: the action, the parameters, the agent's declared intent, and the applicable policy assessed together at the moment of execution. IAM gave the agent permission to call the API. It did not give it permission to call this API with these arguments under these conditions.

Decision 2: Should this agent continue execution after discovering something unexpected?

A research agent is asked to summarize a customer's recent support history. It pulls the support ticket data as expected. While doing so, it encounters a flag indicating the customer is a minor. The agent's plan was to generate a summary and email it to the support team. It now has data subject to additional handling requirements that did not apply when its authority was originally granted.

A traditional service following a fixed code path would either succeed or fail in a predictable way. An agent will adapt. It might still generate the summary. It might decide to redact certain fields. It might continue to the email step without flagging the situation.

IAM was not designed to govern mid-execution decisions. The agent's authority was evaluated when it started the task. There is no native mechanism to re-evaluate whether continuing execution is appropriate given what the agent has discovered along the way. That requires runtime governance that observes the agent's lifecycle and can intervene at any phase.

Decision 3: Should this agent act on behalf of another agent, user, or workflow?

An orchestrator agent receives a task from a user and decomposes it into sub-tasks. It delegates one of those sub-tasks to a worker agent. The worker delegates further to a tool-execution agent. By the time an action reaches an enterprise system, the actor performing it is three delegation hops away from the human who initiated the workflow.

The question every CISO will ask is straightforward: who authorized this? But there is no straightforward answer in traditional IAM. Each agent in the chain has its own service account. Each token is technically valid. Whether the action is appropriate depends on whether the delegation chain itself is valid: whether each link narrowed the scope of authority appropriately, whether the original user authorization permitted this kind of downstream action, and whether the chain's purpose still matches what the user intended.

IAM models authentication and access. It does not model multi-hop delegation chains across agents in real time. That requires a runtime governance layer that maintains the delegation graph and validates it on every action.

Decision 4: Should this agent access this data in the context of this task?

An analytics agent has read access to the customer database. The access grant is correct. The agent uses it appropriately when generating quarterly reports. Today, the same agent is performing a different task: drafting a customer-facing email response on behalf of a support team.

The data the agent needs for the email is a small subset of what its database access grant allows. The risk profile of the email task is different from the risk profile of the analytics task. The same access grant, used in two different task contexts, carries two different risk levels.

Static entitlements were designed for the assumption that the user or service has a stable, well-defined purpose. Agents do not have a stable purpose. They have multiple goals, and they shift between them. Access decisions need to consider not just what the agent is permitted to access in the abstract, but what it should access in the context of its current task.

Decision 5: Should this action proceed without human approval?

An operations agent has been given authority to apply infrastructure patches. Most patches are routine: a small dependency update, a configuration change, a security fix. The agent applies them autonomously. This is appropriate, and the volume would be impossible for humans to review.

Today, the agent is about to apply a patch that touches the production database schema during business hours. The action is technically within its scope. The IAM permission allows it. But this specific action, in this specific context, has a risk profile that warrants human review.

There is no native mechanism in IAM to evaluate when an action requires escalation. That decision depends on the action's blast radius, the agent's confidence, the timing, and the organization's escalation policy. Determining when to invoke human-in-the-loop is a runtime governance decision, made dynamically based on the action being attempted, not a static permission setting.

IAM and ARG: Different Questions, Different Layers

The diagram makes the boundary explicit. IAM evaluates four foundational questions at authentication time. Agent Runtime Governance evaluates five behavioral questions at every action. Both layers feed a unified audit trail. They answer different questions because they were designed for different problems.

What Is Missing

Each of these five decisions points to capabilities that traditional IAM does not provide and was never designed to provide. Building these capabilities requires a layer of infrastructure focused specifically on runtime control:

Runtime policy evaluation. Formal policy (Cedar, OPA, Rego) evaluated on every action, not just at authentication time. The same agent can be permitted to take an action under one set of conditions and denied under another.

Intent-aware authorization. The agent declares its purpose for the current task. Authorization decisions reference the declared intent. Actions that drift from the intent are flagged or denied.

Delegation-aware enforcement. The full delegation chain from the originating human to the current agent is maintained, validated, and used in authorization decisions. Authority narrows at every hop. Chains can be evaluated for scope drift.

Human-in-the-loop checkpoints. The governance layer determines when an action requires human approval based on the action itself, the agent's authority, the delegation chain, and the policy. Escalation is dynamic, not statically configured.

Execution lineage and audit trail. Every action is recorded with full governance context: which agent, what intent, what authority grant, what policy decision, what delegation chain. The record supports forensic reconstruction and compliance evidence.

Scoped credential brokering. Agents do not hold raw credentials. Short-lived, purpose-bound capability tokens are issued per action. Credentials are mediated by the governance layer, not held by the agent.

Continuous evaluation during multi-step execution. The agent's authority is re-evaluated as the task progresses. Mid-execution discoveries that change the risk profile trigger re-authorization or escalation.

This Is Where Agent Runtime Governance Fits

Agent Runtime Governance (ARG) is the layer that provides these capabilities. It is not a replacement for IAM. It is not another identity silo. It is a runtime governance plane that sits between the enterprise identity systems and the agent execution environment.

The relationship is compositional. IAM establishes who the agent is and what it has been granted in the abstract. ARG evaluates whether a specific action should proceed in the context of the agent's current task, declared intent, delegation chain, and applicable policy. The two layers consume the same identity signals. They answer different questions.

When an agent attempts an action, the governance layer pulls the agent's verified identity from IAM, the current authority grant for the task, the active delegation chain, and the applicable policy. It evaluates them together against the specific action being attempted. It either permits the action, denies it, or escalates it for human approval. The decision is recorded with full context.

This is the layer that the five decisions above all require. It does not exist in traditional IAM not because IAM is lacking, but because IAM was never designed to operate at this granularity or with this kind of runtime context.

Authentication Is Not Enough

Enterprises adopting AI agents in production do not just need authenticated agents. They need governable agents. The two are not the same.

IAM remains necessary. The standards we have built over two decades are foundational and will continue to be foundational. But for autonomous systems that reason, plan, adapt, and delegate at machine speed, identity is the floor, not the ceiling. Runtime governance is the layer that makes the floor matter.

The organizations that recognize this gap and build the governance infrastructure now will be the ones that can adopt AI agents at scale with confidence. The agents are already running in most enterprises. The governance layer is what comes next.

---

If your team is designing the runtime governance layer for AI agents and wants to compare notes on what is working in production, we would welcome the conversation. We are also actively working with Founding Design Partners on these architectural patterns.

Need help designing your runtime governance architecture? Our Agent Authorization & Runtime Control Architecture engagement helps enterprise teams design agent identity, scoped authority, delegation chains, and runtime policy enforcement that fits alongside their existing IAM stack. Download the one-pager (PDF) or discuss an engagement.