If an autonomous agent runs in your environment — a Claude Code instance committing to your repository, an LLM querying your data warehouse, an agentic workflow approving pull requests or paying invoices — it has an identity. The credential is real. The permissions are real. The actions taken using that identity have business consequence. And most security teams treat that identity like a service account, because that is the closest mental model the IAM program already has for it. After working through this evaluation across many cloud security assessments where autonomous agents had been deployed into production, a consistent gap emerges: the controls that work for service accounts do not work for agent identities, and the controls that catch human-user failures do not extend to agents either. The agent identity sits in the middle, governed by neither, and the operational risk has reached the point where it deserves its own category in the IAM program.
This article walks through why the service-account model is wrong for agents, what the agent identity actually does that demands a different control set, how to extend existing IAM controls to cover agent failures, and what good agent identity governance looks like in practice. The framing throughout is operational: what changes in the audit, what changes in the detection logic, what changes in the access review.
Why “service account” is the wrong mental model
The service account model has worked for the better part of two decades because the behaviours of service accounts are predictable. A service account authenticates from a known network range, makes calls against a fixed list of endpoints, runs against a defined schedule, and never makes a judgement about whether to perform an action. The credential is bound to the process; the process is bound to the workload; the workload’s behaviour is encoded in code that was reviewed before deployment. When a service account behaves anomalously, the anomaly is almost always either a compromised credential or a buggy deployment. Both are debuggable.
Agent identities break every one of those assumptions.
An agent identity authenticates from variable network ranges (the agent may run on a developer’s laptop, on a managed cloud runner, on a vendor-hosted execution environment, or on infrastructure the security team has never inventoried). The endpoints the agent calls are not a fixed list — they are whatever endpoints the agent’s reasoning concludes are necessary for the task at hand. The schedule is event-driven rather than periodic, and the events that trigger the agent can include actions taken by users, by other agents, or by external systems the security team does not control.
Most importantly, the agent makes judgements. The credential’s permissions describe what the agent is allowed to do. The agent’s behaviour describes what it decides to do, conditioned on the inputs it receives. Those inputs include data the agent reads, instructions embedded in that data, and the agent’s own memory of prior interactions. When an agent behaves anomalously, the anomaly may be a compromised credential, a buggy deployment, a successful prompt injection, an unintended consequence of the agent’s tool-use policy, or simply the agent making a wrong call about a request it had legitimate permission to evaluate.
The traditional IAM playbook does not have a category for “the credential is fine and the process is fine but the agent made a bad call”. The agent identity needs that category, and the controls that exist around it need to be designed for it.
What the agent identity actually does
Three properties of agent identities deserve specific attention because they break the assumptions IAM controls were built on.
Indirect prompt injection turns data into instructions. An agent reads a JIRA comment, an email, a customer support ticket, a documentation page, or a piece of source code as part of its working context. An attacker who can plant text in any of those sources can attempt to redirect the agent to take actions the agent’s credentials authorise but that the agent’s owner never intended. The credential did not leak. The session is not compromised. The agent is being directed by a third party through the data it reads. The IAM control that is supposed to catch this is “principle of least privilege”, and least privilege has not changed — what has changed is that the principle now needs to be evaluated against the actions the agent could be directed to take, not just the actions the agent’s owner intends.
Tool-use composition produces blast radius the credential summary does not show. A modern agent does not have one set of permissions. It has access to a set of tools, and each tool has its own permission scope. The agent’s blast radius is the union of every tool it can call, multiplied by the actions any sequence of tool calls can produce. An agent with filesystem read, shell execute, and outbound HTTP can exfiltrate the entire codebase. The individual tool permissions look reasonable; the composition is the bug. The IAM access review that examines each credential in isolation does not capture this — the review needs to capture the composition of capabilities the agent identity can exercise across all tools simultaneously.
Memory persists across sessions in ways the credential audit does not. An agent with persistent memory remembers what it did, what it was told, and what its operator approved across many sessions. That memory becomes part of the agent’s effective permission state. A user who once approved the agent reading a specific S3 bucket may have intended a one-time approval; the agent’s memory may treat it as a standing authorisation. The credential’s permission set does not change. The agent’s behaviour changes because its memory state changed. Audit controls that snapshot credential state at a point in time miss this entirely; the agent’s effective behaviour needs to be evaluated against the current memory state, not the historical credential state.
Extending IAM controls to cover agent failures
Existing IAM control categories — provisioning, authentication, authorisation, access review, monitoring, and termination — all need extension to handle agents. The extensions are not exotic. They are specific.
Provisioning. When an agent identity is created, the registration must include not just the credentials and the permission scope, but also the list of tools the agent can invoke, the data sources the agent will be allowed to read, and the human or service owner responsible for the agent’s behaviour. The owner is not optional. Agents without owners are how agents accumulate permissions nobody is accountable for. A registration record without an owner should not be allowed to authenticate. The penetration testing team and the IAM owner should align on registration controls before the first production agent is deployed.
Authentication. Agent identities should authenticate using short-lived credentials tied to a specific session. Long-lived API keys for agents are the same operational risk as long-lived API keys for any service, with the added concern that prompt injection can convince the agent to exfiltrate the credential. Workload identity federation, where the agent’s runtime environment is the credential source, eliminates the static credential entirely.
Authorisation. The agent’s authorisation policy needs to describe not just what permissions the credential carries but also what circumstances the agent is allowed to invoke those permissions in. “Read access to the customer database” is too broad if the agent has tool-use access that lets it write the read result to an outbound HTTP request. Capability-based authorisation, where the agent must explicitly request a capability for each action and the request is logged with the agent’s reasoning, gives the audit trail the IAM program needs.
Access review. Quarterly access reviews against the agent identity must include three new questions beyond the standard “does the principal still need this permission”. First, what actions has the agent taken under this credential in the audit window, and were those actions consistent with the owner’s intent? Second, what data sources did the agent read, and which of those sources are controlled by parties outside the organisation? Third, what tool-use combinations are now reachable that were not reachable at the time of original provisioning?
Monitoring. Detection logic for agent identities needs to focus on action sequences rather than individual actions. A single read of a customer record is unremarkable; a read of a customer record followed by an outbound HTTP request to a domain the organisation does not own, within the same agent session, is a probable indirect injection attack in progress. The detection rules for agents need to look at the agent’s behaviour as a session, not at each call independently.
Termination. When the owner of an agent leaves or the agent’s use case ends, the agent’s credential must be revoked, the agent’s persistent memory must be deleted, and the workflows that depended on the agent must be re-routed. Agents whose owners have left are a quiet source of orphaned permission state; the termination control needs to include “does this agent still have an owner”.
What good agent identity governance looks like
A practical governance pattern that has worked across the engagements observed:
Tier 1 — Read-only agents. Agents whose credentials authorise only read access to non-sensitive data, whose tool-use is limited to a single capability (for example, summarising documents), and whose actions have no downstream effect. These agents need lightweight registration, monthly access review, and standard credential rotation.
Tier 2 — Read-and-act agents. Agents that read from sources the organisation does not fully control (customer-submitted content, public web, vendor APIs) and can take actions that have business effect. These need: explicit owner accountability, capability-based authorisation policy, session-scoped credentials, weekly behaviour review for the first three months after deployment, and a runtime detection rule for the most common indirect-injection patterns.
Tier 3 — Privileged agents. Agents that can take actions with material risk: code commits to production, financial transactions, identity provisioning, infrastructure changes. These require: multi-step approval flows where the agent’s proposed action is shown to a human before execution, per-action capability requests with reasoning logged, dedicated detection rules for each high-risk action class, and a circuit breaker that suspends the agent if a defined behaviour anomaly fires.
The tiers are not exotic. They are the same risk-based pattern used for human user privilege levels, adapted to the agent context. The reason this pattern is rare in production is that most organisations have not yet recognised that the agent identity is a distinct identity category. The recognition is the first step. The control adaptations follow.
The threat model — who attacks agents and how
The defender’s question is always “what does this control catch”. For agent identities, the relevant threat actors and tactics include:
External attackers exploiting indirect prompt injection. The attacker plants content in a source the agent reads — a customer support ticket, a public web page, a vendor’s API response. The injected content attempts to redirect the agent’s subsequent actions. The control that catches this is detection on action sequences plus authorisation policy that requires explicit capability requests.
Insider abuse via the agent’s permissions. An employee with access to the agent’s interface uses it to take actions the employee’s own credentials do not authorise. The agent acts as a privilege escalation path. The control is binding the agent’s authorisation policy to the requesting user’s authorisation policy — the agent cannot do what the requester could not.
Supply chain compromise via the agent’s tools or data sources. A tool the agent uses or a data source the agent reads is compromised at the vendor. The agent inherits the compromise. The control is vendor due diligence on tool providers plus integrity verification on data the agent treats as authoritative.
Credential exfiltration via the agent’s reasoning loop. An attacker convinces the agent to include its credentials in an outbound response or to write them to a location the attacker can read. The control is preventing the credential from being reachable as a string within the agent’s reasoning context — workload identity federation handles this entirely; static credentials require careful sandboxing.
Where this fits in the broader IAM program
The agent identity category does not replace existing IAM categories. It sits alongside them. Human user identities, service identities, and agent identities each need their own provisioning, review, and detection patterns, because each behaves differently and fails differently.
The forcing function for most organisations to recognise this category will be either an audit finding (where the auditor cannot reconcile the agent’s behaviour against the credential’s permission set) or an incident (where the agent’s actions exceeded what the operator believed it was authorised to do). Recognising the category before either of those forcing functions arrives is the cheap path.
The IAM program does not need to be rebuilt. It needs an additional category. The category needs registration, authentication, authorisation, review, monitoring, and termination patterns specific to how agents fail. The blast radius of getting this wrong is large enough that the program-level work is worth doing now, not after the first incident. For teams already running a DevSecOps program, agent-identity controls should be added to the same pipeline that already enforces credential hygiene and least-privilege for human and service principals.