The dominant model for enterprise identity and access management was designed around humans: named individuals who authenticate once, maintain persistent sessions within a workday, and whose access needs change on a timescale of weeks to months (onboarding, role changes, offboarding). The access model that follows from this is durable identity, broad role-based permissions, and governance centered on provisioning and deprovisioning events.
AI agent identity does not fit that model in any of its three foundational assumptions. Agents are not persistent across sessions in the way humans are. Their access needs are task-specific, not role-specific in the traditional sense. And the governance questions are not primarily about provisioning cycles but about what the agent can do within a specific execution context.
Trying to manage agent access through the human IAM model creates blind spots that accumulate. This post describes where the models diverge and what a purpose-built agent identity model looks like in practice.
The Persistence Mismatch
A human user's identity is durable. An employee's account persists for the duration of their employment. Their access history is coherent across sessions: you can pull their access log for the past year and see a continuous record of their activity. Anomaly detection in human identity is based on deviation from a known behavioral baseline that builds up over time.
An AI agent session is ephemeral. It starts when a task is initiated and ends when the task completes or errors out. The session has no inherent memory of previous sessions. Two consecutive runs of the same agent type may share no state at all.
This ephemerality has access control implications. In a human model, once access is granted to a resource, it persists until explicitly revoked. For an agent, access should conceptually be granted for the session, bounded to the specific task context, and then released. Most enterprise IAM systems do not support this model natively. The agent gets a service account credential, and the credential persists with the permissions it was provisioned, because the IAM system has no concept of "this access was for a single task execution, not for ongoing use."
The result is credentials that outlive their task context, accumulating into a persistent permission set that is broader than what any individual agent run legitimately needs.
The Aggregation Problem in Reused Identities
When multiple agents share a single service account, or when the same service account is reused across agent deployments that do different things, the access log for that credential is no longer interpretable without external context. The log shows "[email protected] read records X, Y, Z, then wrote to table W." You cannot tell from the log whether this was a single agent session executing a coherent workflow, multiple agent types using the same credential in parallel, or a legitimate operation interleaved with an anomalous one.
This is the aggregation problem: shared identities aggregate access events from different sources in a way that makes the individual access events unattributable. It is the same problem that arises when developers share root credentials on a system, but it manifests more severely with agents because agent activity volumes are higher and the operations are more varied.
The solution is agent-type-specific identities, not shared service accounts. If your document processing agent and your data extraction agent use different service accounts, you can attribute access events to a specific agent type, version, and task context. The access log is now interpretable.
The Just-in-Time Credential Model
The most principled approach to agent access is just-in-time credential issuance: the agent does not hold long-lived credentials at all. Instead, when a session starts, the agent requests a short-lived credential scoped to the specific resources it needs for that task, with a TTL that matches the expected session duration (say, 15 to 60 minutes depending on the task type).
This maps onto existing infrastructure: AWS IAM roles with assume-role tokens, Azure Managed Identities with short-lived tokens, GCP Workload Identity Federation. The primitives exist. The configuration discipline required to use them properly for agent workloads is what most teams have not fully implemented.
Concretely, this means defining resource scopes per agent type (what can "doc-processor-v2" access?), mapping those scopes to IAM role definitions, and having the agent session initiation process request the appropriate role token rather than using a static API key. The credential is scoped at the IAM layer, not just at the application layer. If the application layer policy is bypassed or fails, the IAM scope prevents the agent from reaching resources outside its defined range.
We are not saying JIT credentials are feasible for every agent in every deployment today. Legacy systems, third-party APIs that do not support short-lived tokens, and complex orchestration frameworks all create practical constraints. The point is that the architecture should be moving in this direction, and where JIT is not immediately feasible, compensating controls (narrow permission sets, session-level logging, anomaly detection) should fill the gap.
Task-Scoped vs. Role-Based Access
Human access control is typically organized around roles: a person in the "finance analyst" role gets access to the set of systems that finance analysts need. Role membership is relatively stable, and the access model is designed for that stability.
Agent access needs are task-scoped, not role-scoped in the same sense. An agent doing AP reconciliation needs different access from an agent doing variance analysis, even though both might reasonably be grouped under "finance automation." Treating them as the same role because they both touch finance systems gives each agent more access than it needs for its specific task.
The difference is not just philosophical. Consider an agent running AP reconciliation that needs to read invoice records and match them against GL entries. It has no business writing to the GL. Putting it in a "finance-automation" role that includes write access to financial records because another agent in that role needs write access is a policy gap. The role abstraction is too coarse for agent workloads.
Purpose-built agent access models define access at the task type level, not the role level. "AP-reconciliation-agent" has a specific permission set that maps to exactly what that task requires. "Variance-analysis-agent" has a different one. They are not grouped into a broader role that grants the union of their access needs.
Accountability and Attribution
Human identity carries with it a natural accountability mechanism: the person who performed an action is identifiable, and there are organizational and legal consequences for that person if the action was unauthorized or harmful. This accountability is part of what motivates humans to follow access control policies.
Agents have no intrinsic accountability mechanism. An agent that takes an unauthorized action is not penalized and does not learn from the event. Accountability for agent actions must be structurally embedded in the access model: every agent action must be attributable to a specific agent type and version, a specific session initiated by a specific user request, and a specific policy configuration that was active at the time.
This attribution chain is what enables human accountability for agent behavior. The engineer who provisioned the agent with excess permissions is accountable for the consequences of those permissions. The product manager who approved the tool manifest that included a write capability is accountable for any misuse of that capability. Attribution makes accountability possible; without it, "the agent did it" becomes an explanation that terminates rather than directs accountability.
What the IAM System Needs to Know About Agents
Most enterprise IAM systems treat agents as service accounts: static identities with assigned roles. To support a purpose-built agent access model, the IAM system needs to track several things it currently does not.
Agent type and version: not just "agent-service-account-7" but "doc-processor v2.3". When versions carry different permission requirements, the IAM system needs to track versions as distinct entities, not update the same account in place.
Task context: the specific workflow type the agent is executing in a given session. A single agent type may have different access requirements for different task types (read-only review tasks vs. write-enabled processing tasks). The IAM system should support expressing this as distinct permission profiles rather than a single permission set that covers all task types.
Session bounds: when a session starts and ends, so that session-scoped credentials can be issued and revoked automatically rather than relying on TTLs that may not match actual session durations.
These are not features that most enterprise IAM vendors have fully implemented for agent workloads. Building the agent access model often means supplementing the existing IAM system with an agent-specific policy layer that handles the task-context and session-bound dimensions that the underlying IAM system cannot express natively.
Starting the Transition
If your current agent deployments are using shared service accounts or role-based access that was originally designed for humans, the transition to a purpose-built model does not need to happen all at once. The highest-value first step is usually creating distinct identities for each agent type, even if the initial permission sets are the same as the shared account they replace. Separation of identity without narrowing permissions still delivers the attribution and accountability benefits that make auditing meaningful. Narrowing the permissions per type is the next step, done incrementally as you confirm what each agent actually needs.
Audit your AI agents with Arrakis.
Arrakis gives security and platform teams a complete audit trail of every action your AI agents take, with policy enforcement that stops overreach before it reaches your data.
Request a Demo