A user sends an AI agent into a production incident. It reads logs, queries cloud configuration, starts a worker to inspect a suspicious deployment, and changes a setting before the run ends.
Later, security asks the question that decides whether the audit trail means anything: who made the change?
"The application role" is a technically valid answer. It is also a bad answer.
Traditional IAM was built around two familiar actors: humans and workloads. An AI agent sits between them. It runs as software, works for people, hands work to other agents, and may need one permission set at 10:01 and a different one at 10:04.
The prompt describes intent. The token carries power. A model can propose an action, but identity and policy decide whose authority the system will honor.
The controls, up front
- Give every production agent a unique identity. Retain evidence of the agent inventory, identity issuer, credential configuration, owner or sponsor, and creation and decommission records.
- Do not hide different agents behind one shared execution identity. Retain evidence showing per-agent principals, service-account usage, logs identifying the executing agent, and proof that one agent can be revoked without disabling unrelated agents.
- Use short-lived, narrowly scoped credentials. Retain token lifetime, audience, scopes, refresh or exchange architecture, vault or broker configuration, and evidence that static API keys and embedded credentials have been eliminated or explicitly tracked as exceptions.
- Deny by default and grant access just in time. Retain baseline roles, policy definitions, task-specific grants, approval records where applicable, expiration, and revocation events.
- Re-authorize every delegation hop. Retain the agent delegation topology, parent and child scopes, token exchange records, identity lineage in downstream logs, and a test proving that a worker cannot exercise permissions reserved for its parent.
One acceptance test captures the design: pick a sensitive production action from yesterday. Can you identify the initiating human or service, exact agent, every delegation hop, permissions available at that moment, credential audience and lifetime, and the policy or approval that authorized it? A missing answer means the identity design is incomplete.
IAM's two-actor model breaks when software starts acting for people
Classic IAM draws a hard line. Human identities represent people; workload identities represent software such as service accounts, IAM roles, or managed identities. Agents make that split messy.
An agent is software, but its authority may come from a human. It may call one tool with its own permissions, another with delegated user permissions, and a third with a temporary grant. It can keep running after the user closes the browser. It can create workers that act on its behalf. One deployed agent can serve thousands of users.
The old audit question, "Who authenticated?", leaves too much out. Agentic IAM has to keep three facts separate: Identity: Who is executing the action? Delegation: On whose behalf is that identity acting? Authorization: What is that identity allowed to do right now?
Commercial identity platforms are moving this way. Microsoft Entra Agent ID treats agents as a distinct identity type with ownership and sponsorship relationships. AWS AgentCore Identity gives agents workload identities that remain stable across downstream authentication mechanisms.
The shared lesson is plain enough: an agent should be a first-class principal instead of an anonymous process borrowing the application's credentials.
Give the agent a real identity before you give it authority
An agent name is just metadata. So is a YAML label or a framework role such as "researcher".
Calling an agent "billing-agent" only helps a runtime route work. Security systems still need a real principal for that agent. A useful agent identity has to stand on its own: unique, cryptographically rooted, tied to an issuer or trust domain, connected to an owner, represented in policy and audit records, and independently revocable.
There are several ways to get there. Cloud-managed workload identities, SPIFFE/SPIRE, Entra Agent ID, and AgentCore Identity all provide a version of the same property: a sensitive system can cryptographically distinguish one workload or agent from another.
Imagine three agents: support-agent, billing-agent, and refund-agent. All three run under customer-automation-role.
That role can read the CRM, access billing data, and issue refunds. When a refund is issued incorrectly, the cloud audit log may report that customer-automation-role performed the action. The log is accurate, and it leaves the follow-up questions unanswered.
Which agent used the role? Which run? Which user initiated the task? Was the refund agent supposed to have that permission? Did a worker spawned by another agent inherit it accidentally?
"It ran under the application's role" gives process-level attribution and leaves the actual actor unresolved.
Useful identity is a chain
An agent identity answers only part of the audit question. The downstream system also needs to know whose authority the agent is using.
If an employee asks an expense agent to investigate a duplicate charge, the expense API should see both sides: the agent identity and the human authority behind the task. The chain is Human -> Agent -> Task -> Tool -> Resource.
For a sensitive action, the system should preserve enough context to reconstruct that chain: originating principal, agent identity, current actor, tenant, task ID, delegated scope, token audience, expiration, and any policy or approval that authorized elevation.
OAuth already has machinery for this. OAuth 2.0 Token Exchange, standardized in RFC 8693, allows one security token to be exchanged for another.
Conceptually, a downstream token can represent several facts at once: Peter is the subject. expense-agent is the actor. expenses-api is the audience. expenses.read is the delegated scope. The token expires in ten minutes.
That design avoids two common failures. The first is calling every downstream system with the agent's broad service identity, which destroys user attribution. The second is forwarding the user's original bearer token unchanged, which ignores audience boundaries and increases replay risk.
Token exchange creates a credential for one downstream service while preserving the identity context needed for audit and policy.
AWS AgentCore Gateway now implements this pattern through on-behalf-of token exchange. An inbound user token can be exchanged for an audience-bound downstream token while preserving the user's identity and recording the agent as the actor.
AgentCore can provide the plumbing, but the principle is broader:
Follow the authority behind the action.
Every hop gets a fresh authorization decision. Delegation should narrow authority at each step.
Short-lived tokens bound the blast radius
Static API keys are convenient because they let applications avoid identity work. That convenience becomes a liability in agent systems.
A long-lived key is reusable, hard to tie to one execution, usually broader than the task requires, and valuable long after the run ends. Put it in a shared environment and new workers may inherit it without asking for it.
Agents should receive short-lived, narrowly scoped credentials. For sensitive access, token lifetimes should generally be measured in minutes.
Tokens should be audience-bound, carry only the required scopes, and have a controlled refresh path. Where supported, mTLS or DPoP can reduce the usefulness of a stolen bearer token. RFC 9700 captures current OAuth security best practices.
Short-lived credentials lose their value if a durable refresh token sits inside the agent. The runtime or identity broker should handle refresh and token exchange without exposing durable secrets to model context.
The model needs a capability; the runtime should hold the credential that implements it.
AgentCore Identity is one example: its workload access token can bind agent and end-user identity while its token vault manages downstream OAuth credentials. Similar patterns can be built with an authorization server, STS, secrets broker, or workload identity platform.
If a production agent still carries static API keys or embedded long-lived credentials, record that as an open IAM gap instead of a temporary implementation detail.
Least privilege has to move during the run
Least privilege often starts with a service role: choose the smallest role this service needs. Agents need that baseline, then more runtime control on top.
An agent may perform many functions. A specific run should usually exercise only a subset of them. Least privilege becomes a runtime authorization problem layered on top of static role design.
Consider an expense agent whose baseline role can read expenses. A request to investigate charge 8392 fits that baseline. Preparing a refund can receive a temporary permission limited to that expense; executing it may require human approval and a grant capped to the approved amount. When the task ends, the permission disappears.
A practical model is baseline authority + task-scoped authority + just-in-time elevation.
The baseline should be deny-by-default and limited to the agent's normal function. Task permissions should be narrowed by resource and purpose when the underlying systems support it. Higher-consequence actions should trigger policy checks, approvals, or both.
Elevation should be logged, expire automatically, and be revoked when the task ends.
Least privilege for an agent means keeping tomorrow's permission out of today's task.
Child agents need fresh authorization
Multi-agent systems create another identity failure mode: privilege cloning. A manager agent might be able to read GitHub, write Jira tickets, read AWS configuration, and send Slack messages.
Now the manager delegates one task to a worker: inspect CloudWatch logs. A naive implementation starts the worker inside the same runtime and gives it the same environment.
The worker gets the manager's full credential set. It inherited the job and every privilege the parent had.
That is credential sharing with extra steps.
Each agent-to-agent handoff should create a new authorization decision. The child should authenticate independently. The delegated task should be translated into the smallest permission set required to perform that task, scoped to the relevant resources, and expired with the work.
As a design rule: child authority ⊆ parent delegable authority.
A parent can delegate only the authority it actually holds. A child should receive a smaller, task-specific grant.
The standards work here is still developing. Current IETF work is applying workload identity and OAuth delegation to user-to-agent and agent-to-agent flows, while other proposals explore tokens that can only lose authority as they move through a delegation chain.
Those formats are still emerging, but the production rule is already clear: re-authorize every hop and monotonically reduce privilege.
Lifecycle becomes the hard part
Per-agent identity creates a volume problem. A company may move from dozens of service accounts to hundreds of durable agents and thousands of short-lived workers.
Shared credentials only make that harder. Lifecycle management has to be automated.
A useful lifecycle looks like this: register -> attest -> assign ownership -> provision -> authorize -> rotate -> observe -> suspend -> retire.
The inventory should include an immutable agent ID, type or blueprint, technical owner, business sponsor, creator, environment, purpose, allowed delegation, tools, credential issuer, permissions, creation time, review period, and recent activity.
Microsoft Entra Agent ID now distinguishes owners from sponsors. Owners are technical administrators responsible for configuration and credential management, while sponsors provide business accountability for an agent's purpose, access reviews, and lifecycle decisions.
Entra requires sponsorship for agent identities and blueprints. Every agent should have someone who can administer it and someone accountable for whether it should exist.
The harder lifecycle problem is deciding whether a thousand principals should still exist.
Frameworks provide plumbing for your identity model
Amazon Bedrock AgentCore provides much of the IAM plumbing directly: workload identities, credential providers, a token vault, user-delegated and machine-to-machine OAuth flows, and token exchange. Gateway can authenticate at the tool boundary and perform on-behalf-of exchanges.
That removes infrastructure work. It still leaves permission scope, delegation, approval, ownership, and evidence requirements for the organization to define.
LangGraph sits much lower in the stack. It handles orchestration, so you bring your own IdP, workload identity, token broker, policy engine, credential injection, and lineage.
CrewAI is similar: its agent roles give the runtime metadata without creating IAM principals.
An agent framework can tell software which worker should perform the task. IAM still has to tell the infrastructure who that worker is.
The standards stack is mostly here
Agent identity builds on existing standards. OpenID Connect is mature for user authentication. OAuth is mature for delegated API authorization. RFC 8693 gives us standardized token exchange and actor context.
RFC 9700 captures current OAuth security best practices. SPIFFE provides a mature model for cryptographic workload identity and short-lived SVIDs.
MCP also now defines an OAuth-based authorization model for HTTP transports, including protected-resource metadata and authorization-server discovery. That helps secure the MCP client-to-server boundary.
MCP leaves the organization's delegation model open: who created the agent, which human is behind the current task, whether a manager agent may delegate to a worker, what the worker's permissions should be, and when those permissions should disappear.
MCP can carry an authorization decision; your organization still defines the delegation model.
The moving pieces are primarily the agent-specific profile layered on top of mature primitives. The IETF's WIMSE work is developing workload-identity patterns across multi-system environments, while newer agent-specific drafts apply those primitives to delegation and multi-agent chains.
Teams should watch those efforts while building the core controls now.
Teams can build the needed properties now: unique workload identities, short-lived credentials, audience restrictions, token exchange, user-and-agent attribution, policy enforcement, independent child identities, lifecycle automation, and auditable delegation.
The common vocabulary and interoperable representation are still settling for agent purpose, task context, multi-hop delegation, attenuation, and lifecycle metadata.
Who is this agent, and who sent it?
Agentic IAM extends IAM by making workload identity, delegated authorization, ephemeral credentials, policy enforcement, lifecycle governance, and auditability operate as one system.
The dangerous design is an agent where nobody can answer three questions:
- Who is this?
- Who sent it?
- Why does it have this authority right now?
That is the bar production agent identity should meet.
Cloud Security Partners' Agent Security Assessment reviews the identity and permission boundaries around real agent workflows, including authentication, tool access, privilege scope, delegation, and revocation. If agents are moving beyond pilot environments, this is one of the first control areas worth testing.
You can also use our Agent Security Controls Checklist to evaluate these identity controls alongside the rest of the controls required to deploy agents safely.
About the Author
Peter Karman is a Senior Principal AI Engineer at DryRun Security. He builds agentic, LLM-powered code-review systems that review PRs, ground findings in evidence, and alert of potential security issues. With 17+ years across infrastructure, networking, and software engineering, he designs dependable review pipelines, grounds findings in evidence, and instruments the process so performance meets real-world cost and latency constraints. He previously led engineering and AppSec initiatives as a Principal Engineer at companies like Leafly and AnyRoad.
Cloud Security Partners partnered with DryRun Security for this blog. DryRun Security is the industry’s first AI-native, agentic code security intelligence solution. Powered by their proprietary Contextual Security Analysis engine, they secure software built for the future by helping security and developer teams quiet noise, gain insights, and surface risks that pattern-based scanning tools inherently miss.
Stay in the loop.
Subscribe for the latest in AI, Security, Cloud, and more—straight to your inbox.
