Is IAM the right tool to control AI agents? It depends on how you build them.

Somewhere in your organisation, a development team has deployed an AI agent. It is built with LangChain or LangGraph, containerised with Docker, running on Kubernetes, and calling internal APIs, databases, and an LLM provider. It was deployed last month. The IAM team was not consulted. There is no SailPoint record. The credentials are a service account that was borrowed from another application. Nobody is quite sure what it can access.

This is not a hypothetical. It is the situation most IAM engineers are walking into as agent deployments accelerate faster than governance frameworks can respond. The question being asked — often urgently, and often after the fact — is: how do we control this?

The instinct is to reach for familiar tools. Service accounts. OAuth tokens. SailPoint provisioning. Access certification. These are the instruments of enterprise IAM, and they have served well for human users and application service accounts for decades. The question is whether they serve for agents — and if so, for which part of the problem.

This article examines that question honestly. The answer is not yes or no. It is: it depends on which layer of the agentic system you are trying to govern. Before any tool can be chosen, a more fundamental question must be answered — what are the layers of the system, and which layer is the control problem actually in?

That is where this article begins.

1. The structural model — three layers, three different control problems

The governance mistake most organisations make with agents is reaching for a tool before understanding the structure of what they are governing. IAM is applied because it is familiar. The result is a governance framework that covers one layer well, partially covers another, and leaves the most dangerous layer entirely unaddressed — while creating the impression that the problem has been handled.

An agentic system has three distinct layers, each with a different control problem. The structure of the system determines which layer is most exposed, and therefore which control approach is most relevant.

┌─────────────────────────────────────────────┐
│        Layer 1 — Identity & access          │
│                                             │
│  Who is the agent?                          │
│  What is it allowed to access?              │
│  Who approved that access?                  │
│  What happens when it is decommissioned?    │
│                                             │
│  Control problem: provisioning & lifecycle  │
│  IAM relevance: HIGH — this is IAM's domain│
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│        Layer 2 — Orchestration              │
│                                             │
│  What tools does the agent call?            │
│  In what order, based on what decisions?    │
│  Who delegated to whom?                     │
│  Is the delegation chain auditable?         │
│                                             │
│  Control problem: tool governance & audit   │
│  IAM relevance: PARTIAL — helps but limited│
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│        Layer 3 — Reasoning & execution      │
│                                             │
│  What did the LLM decide?                   │
│  What inputs did it receive?                │
│  Was it operating on its intended task?     │
│  Was it prompt injected?                    │
│                                             │
│  Control problem: runtime behaviour         │
│  IAM relevance: NONE — different domain    │
└─────────────────────────────────────────────┘

The three layers are not interchangeable. A control that works in layer one has no effect in layer three. An organisation that governs layer one rigorously and assumes it has governed the agent has not governed the agent — it has governed the agent’s identity and access credentials. What the agent does with those credentials, on what inputs, driven by what reasoning, is a different problem that requires different thinking.

The building structure of the agent also determines which layer carries the most risk:

A simple autonomous agent — a batch processing script, a monitoring agent with a fixed system prompt and controlled inputs — carries most of its risk in layer one. If the identity and access are properly governed, the risk is relatively contained. Layer three risk is low because the inputs are predictable and the reasoning is narrow.

A user-delegated agent that handles sensitive documents on behalf of a user carries most of its risk in layer two. The orchestration decisions — which tools to call, in what sequence, based on what the LLM returned — are where the governance problem lives. What the agent does with the document matters as much as what it is permitted to access.

A multi-agent pipeline that ingests external data sources — emails, documents, web content, database records — carries most of its risk in layer three. Prompt injection through those external inputs is the dominant threat. The agent may be perfectly governed at layers one and two and still be redirected by a malicious instruction embedded in a document it was asked to summarise.

The article examines each layer in turn.

2. Layer one — where IAM applies and what it gives you

IAM is the right tool for layer one. This is its domain: identity lifecycle, access provisioning, and governance. The service account model, applied rigorously to agents, is the immediately available baseline that most organisations have not yet established.

The service account model

The pattern is the same one IAM engineers have used for application service accounts for years. The novelty is applying it deliberately and completely to every agent in the estate.

SailPoint (IGA)
    ↓  provisions
AD service account
e.g. svc-agt-{team}-{function}-{env}
    ↓  member of
AD role group
e.g. gApp_FinanceDB_Reader
     gApp_Reports_Writer
    ↓  controls access to
Database · API · File system · Application component

A SailPoint-governed AD service account, named to encode the agent’s purpose and owning team, linked to a human owner, and granted access only through approved AD role group membership — this is the baseline. It gives the organisation named identity, governed access, a revocation path, and an audit trail. When the agent is decommissioned, the service account is revoked and access ends immediately. When the owner leaves, SailPoint surfaces the orphaned account for reassignment or decommission.

For agents calling modern REST APIs, the service account maps to an OAuth 2.0 client registration in Keycloak. The agent authenticates using the Client Credentials grant — no user involved, no browser flow — and receives a scoped access token:

POST /realms/{realm}/protocol/openid-connect/token
grant_type=client_credentials
&client_id=svc-agt-finance-summariser
&client_secret=s3cr3t
→ access_token scoped to approved permissions

For agents acting on behalf of a specific user, Token Exchange (RFC 8693) narrows the user’s token to what the agent specifically needs for the task. The downstream API sees both who the user is and who the agent is:

{
  "sub": "user-123",
  "act": { "sub": "svc-agt-finance-summariser" },
  "scope": "read:finance-summary",
  "exp": 1714336700
}

The act claim carries the delegation explicitly. The downstream service can enforce that the agent is only acting within the scope the user delegated — not the full extent of the user’s permissions.

The agent registry

Before any tooling decision, the most important governance action is to know what agents are deployed. Not in the abstract — a specific, governed record of every agent in the estate:

Name:            finance-summariser
Owner:           john.smith@corp.com
Purpose:         summarises finance reports on user request
Service account: svc-agt-finance-summariser-prod
Approved access: gApp_FinanceDB_Reader, gApp_Reports_Writer
Deployment:      k8s / finance namespace / prod
Last certified:  2025-06-01
Known gaps:      no behavioural controls beyond rate limiting

The last field is the honest field. Most organisations cannot fill it in because they have not inventoried their agents at all. Building the registry — in SailPoint, in a CMDB, or even in a governed spreadsheet — is the first governance act, independent of any tooling decision.

The registry forces the questions that governance requires: who owns this, what can it do, what controls are in place, and what controls are not. An organisation that can answer all four — even if the answer to the last one is “none beyond rate limiting” — is in a materially better governance position than one that cannot.

Most organisations have not done even this much for their agents. Applying the service account model rigorously — one account per agent, named owner, SailPoint governance, AD group membership, certification cycle — is far better than agents running with shared credentials, hardcoded API keys, or unowned service accounts. It is also imperfect in ways the next sections make clear.

3. The in-house reality — why layer one is harder than it looks

The cloud agent platforms — Azure AI Foundry, AWS Bedrock, Google Vertex AI Agent Builder — make layer one manageable. They have agent registries, managed identities, and IAM role bindings built into the deployment model. The governance scaffolding is part of the platform. The IAM engineer configures it; the platform enforces it.

An in-house agent built with LangChain or LangGraph, containerised with Docker, deployed on Kubernetes is a different situation entirely. It is just an application. There is no platform managing the identity layer. The governance scaffolding does not exist unless someone built it deliberately.

Developer's view:          IAM engineer's view:
─────────────────          ────────────────────
LangChain application      Who does this authenticate as?
calls Azure OpenAI         Hardcoded API key in a K8s secret
calls finance DB           Shared service account from another app
calls document store       No one knows
deployed to K8s            No SailPoint record exists
it works                   No owner documented
                           No certification scheduled
                           No decommission process defined

The IAM engineer’s actual problem with in-house agents is not configuring the right controls. It is gaining visibility into agents that were deployed without any governance process at all. Layer one is the right domain for IAM. But getting to layer one requires a process change that the IAM team does not control unilaterally — it requires development teams to engage the IAM process before deployment.

The most important governance control for in-house agents is often not technical. It is a policy: no agent deploys to production without a SailPoint-governed service account, a named owner, and a registry entry. That policy must be adopted before the deployment pipeline, not applied after the fact to agents already in production.

4. Layer two — where IAM partially applies

The orchestration layer is where the agent decides what tools to call, in what order, based on what the LLM returned. IAM has partial relevance here. It governs the ceiling of what the agent is permitted to call. It does not govern the decisions that lead to calling it.

What IAM can contribute to layer two:

Token scopes provide genuine tool-call enforcement. If the agent’s orchestration logic attempts to call an API outside its approved scope, the resource server returns 401. The access boundary holds regardless of what the LLM decided. This is real — it constrains what misbehaviour in the orchestration layer can reach.

Short-lived task-scoped tokens tighten this further. Rather than issuing a long-lived token at agent startup that covers everything the agent might ever need, a task-scoped token is issued for a specific execution — valid only for the duration of that task, covering only the tools that task requires. When the task completes, the token expires or is revoked. The window during which a compromised or misbehaving agent can act is narrowed to the task itself.

Token Exchange carries the delegation chain in multi-agent pipelines. The act claim passes through each hop, and in principle the full chain is auditable — orchestrator delegated to sub-agent, sub-agent called this API, on behalf of this user. In practice, most enterprise deployments do not implement nested act claims beyond one level. The audit trail for a three-hop agent pipeline is, for most organisations, either incomplete or absent.

An agent manifest — a declared list of tools the agent is approved to use, submitted as part of the deployment process — extends IAM’s reach into the orchestration layer without changing the access control model. It does not prevent an agent from attempting unapproved calls; the token scopes do that. But it creates a declaration that can be audited: if the agent calls something not in its manifest, that is an anomaly signal.

What IAM cannot do in layer two:

The orchestration layer makes decisions. IAM governs what those decisions can access — not whether the decisions are correct, intended, or consistent with the user’s original task. An agent that calls the right APIs in the wrong order, calls a legitimate API for an illegitimate purpose, or orchestrates a sequence of individually-permitted calls that together produce a harmful outcome — all of this happens within valid token scopes and correct group memberships. IAM has nothing to say about decision quality.

The layer two gap, stated plainly: IAM controls the ceiling of what the orchestration layer can reach. It does not control the floor of what it actually does within that ceiling.

5. Layer three — where IAM does not apply

The reasoning and execution layer is where the LLM processes inputs, generates decisions, and produces outputs that drive the orchestration layer. This is outside IAM’s scope by design — and by the nature of what IAM is.

IAM controls access to resources. It governs who can reach what and under what conditions. It does not control what an agent does with the inputs it receives, what reasoning the model applies, or whether the agent’s behaviour is consistent with its intended purpose. These are different problems, and conflating them with access control leads to governance frameworks that are confidently wrong.

Four specific gaps live in layer three that IAM cannot address.

The system prompt is invisible to IAM. Two agents with identical service accounts, identical AD group memberships, and identical token scopes can have completely different effective capabilities if their system prompts differ. One agent is instructed to summarise documents conservatively and flag anything unusual for human review. Another is instructed to extract financial data from every document it processes and forward summaries to a designated endpoint. From IAM’s perspective — from the perspective of every access control in the stack — these two agents are identical. The difference is in a string of text that lives in the application code, not in the identity or access model.

Volume and frequency are invisible to the access control layer. The access token says yes to each API call individually. It does not say yes to ten calls, or a hundred, or a million. An agent that reads one database record and an agent that reads one million database records present identical credentials on each call. Both have valid tokens. Both have correct group memberships. The difference — which is the entire difference between normal operation and a data exfiltration event — is invisible to IAM.

Prompt injection bypasses the access model entirely. An attacker embeds malicious instructions in data the agent processes — a document it is asked to summarise, an email it is asked to respond to, a database record it is asked to analyse. The agent treats those instructions as legitimate and acts on them, using its validly provisioned access, with correct credentials, within its approved scopes. The token is valid. The group memberships are correct. The behaviour was never intended by the owner, was never approved through any IAM process, and cannot be detected or prevented by any IAM control.

This is the most serious gap in the agent governance model and the most important to name honestly. Prompt injection is not a failure of IAM configuration. It is outside IAM’s domain. An organisation that invests heavily in layer one governance and treats it as a defence against prompt injection has misunderstood the problem.

Cross-agent delegation decisions are not governed by the access model. In a multi-agent pipeline, the orchestrator decides which sub-agent to invoke and what context to pass. That decision is made by the LLM. IAM can audit that a token was issued for the sub-agent and that the sub-agent called an approved API. It cannot audit whether the decision to invoke that sub-agent was consistent with the original user’s intent, or whether the context passed to the sub-agent was appropriate.

Naming these gaps is itself a governance act. Documenting that layer three is outside IAM’s scope — in the risk register, in the agent registry, in the governance framework — is not an admission of failure. It is an accurate characterisation of where the control boundary lies. Organisations that treat prompt injection as an IAM configuration problem will waste effort and produce a false sense of security. Organisations that name it accurately can begin building the right controls for the right layer.

6. Partial controls for layers two and three

The controls available for layers two and three are partial. None of them is sufficient. Together they are better than nothing, and some of them are immediately deployable with existing infrastructure. Each is named here with what it actually covers and what it does not.

Rate limiting at the API gateway sits at the layer two/three boundary. It controls volume per client ID per time window — a meaningful constraint on the blast radius of a runaway or compromised agent. It does not understand intent. It does not distinguish between a legitimate high-volume operation and an anomalous one. It does not prevent prompt injection. But it caps what a misbehaving agent can do per unit of time, and it is available today in most enterprise gateway products with low configuration overhead.

Scope minimisation sits at the layer one/two boundary. The narrower the approved scopes, the smaller the surface area that bad behaviour in layers two and three can reach. Not read:finance — read:finance-summary:own-department. Not write:documents — write:documents:task-output-folder:append-only. Each reduction in scope is a reduction in what a compromised or misbehaving agent can accomplish, regardless of which layer the compromise originates in. This requires the resource server to support fine-grained scopes — which many enterprise APIs do not currently implement — but it is worth building into new API development as a design requirement.

Short-lived task-scoped tokens sit in layer two. Issuing tokens that are valid only for the duration of a specific task, covering only the tools that task requires, and revoking them on task completion reduces the window during which any compromise can be exploited. A five-minute access token on a task that takes three minutes leaves two minutes of residual exposure. A token issued for “summarise this document” that covers only the document store API and the output write API leaves no path to the finance database regardless of what instructions are injected into the document. The investment is orchestration infrastructure — the system needs to know when a task starts, what it requires, and when it ends. Keycloak supports programmatic token issuance and revocation. The orchestration logic must be built.

Human-in-the-loop gates sit at the layer two/three boundary. For action categories that carry significant consequence — financial transactions, bulk data exports, cross-user writes, external communications — requiring explicit owner confirmation before the agent proceeds introduces a meaningful control at the points that matter most. It breaks full autonomy, which is a tradeoff. For high-risk actions in regulated environments, it is the right tradeoff. The owner’s confirmation is also an audit event — documented intent that the action was authorised.

Audit logging with full correlation spans all three layers. Agent identity, owner, task context, tool calls, input summaries, token claims — logged together for every agent execution. This does not prevent anything. It makes incidents attributable, patterns detectable over time, and investigations reconstructable. The data collected now is the baseline from which anomaly detection can eventually be built. For organisations that have no layer three controls today, comprehensive audit logging is the single highest-value investment available — it costs relatively little to implement and provides the foundation for every subsequent control improvement.

Input and output validation sits in layer three. Validating agent inputs and outputs for known injection patterns, anomalous structures, or unexpected content raises the cost of attack without eliminating it. Signature-based validation does not detect novel injection techniques. It is a partial mitigation — meaningful, worth implementing, but not a defence against a determined attacker with knowledge of the validation rules.

7. The honest assessment — answering the question

The question this article opened with was whether IAM is the right tool to control agents. The structural model now makes a precise answer possible.

IAM is the right tool for layer one. It is what IAM was designed for. Apply it rigorously — service accounts with human owners, SailPoint governance, AD group membership, OAuth tokens, certification cycles, decommissioning on agent retirement. For most organisations, this baseline has not been established for their agents. Establishing it is the first priority.

IAM is a partial tool for layer two. Token scopes and short-lived task tokens help constrain what orchestration decisions can access. The quality of those decisions — whether the agent is doing what it was intended to do — is outside IAM’s reach.

IAM is the wrong tool for layer three. Not because IAM is insufficient, but because the reasoning and execution layer requires a fundamentally different class of control — runtime behavioural observability, anomaly detection, input validation, intent verification — that is still being assembled by the industry. No mature enterprise standard exists for it yet.

That is not a failure of IAM. IAM was designed to control access. Applying it correctly to agents means applying it to the layer it was designed for, knowing precisely where it stops, and being honest about what occupies the gap.

The most dangerous mistake is treating layer one controls as complete governance. “We have service accounts and OAuth tokens” is not “we have governed this agent.” It is “we have governed this agent’s identity and access.” The behaviour of the agent within that access — what it decides, what it processes, how it can be redirected — is a different problem that requires different tools. Conflating the two produces a governance framework that is confident and incomplete.

8. What good enough looks like today

A defensible governance posture for an organisation that is honest about where it is. Not the ideal future state. The achievable present state, built on the three-layer model.

Layer one — apply IAM rigorously to every agent: Every deployed agent has a named owner and a registry entry. Service accounts follow a naming convention that encodes team, function, and environment. AD group membership is approved through the same workflow as human access. OAuth Client Credentials or Token Exchange is used depending on whether the agent is autonomous or user-delegated. Certification reviews run on a defined cycle — agents are not exempt from access reviews. Decommissioning is tied to agent retirement, not to someone eventually remembering to clean up.

Layer two — implement partial controls: Rate limiting is configured at the API gateway per agent client ID. Scopes are as narrow as the resource server supports. Short-lived task-scoped tokens are implemented where the orchestration infrastructure allows. Human-in-the-loop gates are in place for the action categories that carry the most consequence. Audit logging captures agent identity, task context, and tool calls together.

Layer three — document the accepted gaps:

Control: IAM / service account governance
Covers: layer 1 — identity, access, lifecycle
Partially covers: layer 2 — tool call scope enforcement
Does not cover: layer 3 — runtime behaviour,
                prompt injection, intent verification
Residual risk: agent misbehaviour within granted access
Mitigation: rate limiting, audit logging, scope minimisation
Accepted gap: prompt injection, system prompt invisibility
              — no current enterprise control
Review date: [quarterly]

Naming the accepted gap in the risk register is a governance act. An organisation that documents “we have no control for prompt injection and have accepted that risk pending the maturation of layer three tooling” is in a better governance position than one that has not asked the question. The three-layer model gives that documentation a precise, defensible structure.

The honest answer

The governance frameworks for agents are being assembled in real time. No complete solution exists. The field — IAM, security, AI safety, platform engineering — is actively working on it, and the organisations that will adopt mature controls cleanly when they arrive are those that understood the structure of the problem before the tools were ready.

Layer one is governed today using tools that exist today. They are not a perfect fit for agents, but they are the right tools for the right layer. Apply them. Every agent in your estate should have a named owner, a governed service account, and a registry entry. Most do not. That is the gap to close first.

Layer two is partially governed using a combination of token design, orchestration discipline, and API gateway controls. None of it is complete. All of it is better than nothing.

Layer three is not governed by any mature enterprise tooling today. The controls being built — OPA and Cedar for behavioural policy, MCP for agent-to-tool auth, observability platforms for LLM execution tracing — are directionally correct but not yet production-grade for most enterprise contexts. The standards are moving. The organisations best positioned to adopt them are those building the audit infrastructure now, before the detection and prevention tooling exists to consume it.

The question to ask about every agent in your estate is not “do we have IAM controls?” It is: which layer carries the primary risk for this agent, and do we have the right control for that layer?

For now: govern what you can govern, at the layer it belongs to. Know what you cannot. Document both.

This is the third article in a series on enterprise identity and access management. Article one covers how enterprise SSO works with Keycloak — from Active Directory to a secured API. Article two examines how to secure and store OAuth tokens. This article extends the series to AI agents, the third identity type that fits neither the human user model nor the machine-to-machine model cleanly.