When a human employee logs into a corporate system, their identity is established through a combination of credentials, device trust, and contextual signals — and that identity determines what they are permitted to do. When an agent accesses the same system, none of those signals are available: the agent has no human presence, no device, and no behavioral baseline that a conventional identity system knows how to interpret. Yet the actions the agent takes under an assumed identity can be as consequential as any human action — or more so, given that agents can act at a speed and scale that humans cannot. Identity for agents is not a marginal extension of existing IAM practices; it is a rearchitecting of the identity model for a world in which the actor is autonomous software rather than a human being.
The Problem with Human Credentials
The most common anti-pattern in early agentic deployments is the use of human credentials to authenticate the agent to downstream systems. A developer configures the agent with their own username and password, or their personal API key, and the agent acts with the developer's full permissions in every system it accesses. This is dangerous for several reasons. The credential scope is almost certainly too broad: the developer has permissions that were granted for their human work, not for the specific task the agent is performing. The credential is not rotated on a schedule appropriate for an automated system: a compromised agent with a long-lived human credential gives an attacker persistent, broad access. And the audit trail is contaminated: actions taken by the agent are attributed to the human in the system logs, making it impossible to distinguish the human's actions from the agent's.
The correct approach is to provision a dedicated identity for each agent — not a human identity with reduced permissions, but a service account that is designed specifically for autonomous, programmatic use. AWS IAM and equivalent services in Azure and Google Cloud provide the infrastructure for this: roles with explicitly defined permission sets, time-limited credentials that are automatically rotated, and audit logging that attributes every action to the specific role that took it. The service account for an agent should be provisioned with only the permissions required for the agent's defined scope of action — nothing more — and those permissions should be reviewed and recertified periodically.
Service Accounts and Workload Identity
A service account is a non-human identity — an account in an identity provider that represents a workload rather than a person. Service accounts have existed in enterprise IT for decades, primarily for batch jobs, scheduled tasks, and system-to-system integrations. The adaptation of this model to agentic systems requires three extensions. First, dynamic scoping: an agent's permission scope should vary based on the task it is executing, not be fixed at account creation time. An agent processing low-sensitivity documents should have narrower permissions than the same agent processing high-sensitivity documents, even though the underlying identity is the same. Dynamic scoping requires a permission management system that can issue time-limited, task-specific credentials at runtime rather than providing a single set of standing permissions.
Second, task attribution: every credential issued to an agent should be associated with a specific task context — the agent run ID, the human who initiated the run, the use case the run belongs to — so that every action taken with the credential can be attributed back through the chain to the human instruction that originated it. This task attribution chain is required by both the EU AI Act's Article 12 logging obligations and the forensic needs of the incident response process. Third, cross-tenant isolation: an agent that handles data for multiple customers or organizational units must be prevented from allowing data from one customer to be accessible to another, even within the same agent run. This requires credential isolation between tasks, not just between agents.
OAuth 2.0 and On-Behalf-Of Flows
Many enterprise systems use OAuth 2.0 for authorization, and the agent's interaction with those systems must be mediated through OAuth token flows that express the correct relationship between the agent, the human user, and the resource being accessed. The standard OAuth flows were designed for human users delegating access to applications; agentic systems require a variation that is sometimes called the on-behalf-of (OBO) flow: the agent acts on behalf of a named human user, with the human's authorization, but with permissions that are further scoped by the agent's own permission set.
The RFC 8693 token exchange specification provides the technical foundation for OBO flows in agentic contexts: a subject token representing the human user is exchanged for an actor token representing the agent, with the resulting access token scoped to the intersection of the human's permissions and the agent's permitted scope. This token structure preserves the human attribution chain — the access token records both who authorized the action and which agent executed it — while enforcing the principle of least privilege on both dimensions simultaneously. Implementing OBO flows correctly requires cooperation between the identity provider, the integration spine, and the orchestration framework, which is one reason why identity for agents is best addressed at the infrastructure level rather than in per-agent code.
"The identity of an agent is not an afterthought — it is the fulcrum on which the entire access control model balances. Get it wrong, and every other security control in the stack is weakened."
Credential Lifecycle Management
The credential lifecycle for an agent is different from the credential lifecycle for a human in one critical respect: the agent cannot self-serve. A human whose password is about to expire receives a notification, logs in, and changes it. An agent whose credential is about to expire will either fail silently — producing incorrect outputs because it can no longer access the data it needs — or fail noisily — throwing authentication errors that alert the monitoring system but interrupt the task in progress. Agent credential lifecycle management must therefore be fully automated: credentials should be rotated on a defined schedule, the new credentials should be delivered to the agent through a secrets management system (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault), and the rotation should be transparent to the agent's operation.
Revocation is the other critical lifecycle event. When an agent is decommissioned, its credentials must be revoked immediately — not deprecated, not allowed to expire naturally, but actively revoked so that they cannot be used by an attacker who has retained a copy. The governance charter should specify the maximum time between an agent's decommissioning decision and the revocation of its credentials; for high-privileged agents, that window should be measured in hours, not days.
The Principle of Minimal Identity Surface
The sum of all the identities in an agent program — every service account, every OAuth token, every API key — constitutes the program's identity surface: the attack surface that an adversary can target through credential theft, token injection, or privilege escalation. A program that has minimized its identity surface — through careful permission scoping, short credential lifetimes, and aggressive decommissioning of unused identities — presents a significantly smaller target than one that has accumulated credentials without discipline. The principle of minimal identity surface is the aggregate expression of least privilege: applied not just to individual credentials but to the entire population of credentials that exists in the program at any given time.