machine identity

Most teams authenticate AI agents the way they authenticate cron jobs: one API key, one service account, shared by everything that calls the CRM. That works on launch day. It fails the first time someone asks which agent did something, for whom, and with what authority.

This article covers what agent identity refers to, why a shared credential erases the answer, and what a workable design looks like.

Key takeaways

• A shared service account records which credential acted, not which agent. Four agents on one credential look identical in the logs.
• “Agent identity” spans layers: workload identity, OAuth client identity, cryptographic proof, and delegated user authority. Say which one you mean.
• Agent identity and user identity answer different questions. Merging them gives you an agent that is the user, or one nobody can attribute.
• Short-lived, audience-bound, scoped credentials shrink a stolen token’s window and reach. They do not stop theft or in-scope misuse.
• Delegation keeps the agent’s identity apart from the user’s. Impersonation erases it (RFC 8693).
• Identity complements prompt-injection defenses and sandboxing. It limits and explains damage. It does not prevent manipulation.

---

Quick Navigation

---

The Audit Log That Tells You Almost Nothing

Start with a hypothetical. This is not a real incident.

A company runs four agents: support, finance, sales and engineering. All four authenticate as agent-prod-service-account. A support ticket arrives with hidden instructions, and the support agent is talked into exporting a customer list. The security team pulls the logs:

09:14:07Z  principal=agent-prod-service-account  action=crm.contacts.export    result=allowed
09:14:09Z  principal=agent-prod-service-account  action=storage.objects.create result=allowed

The logs say which credential acted. They do not say which agent, which user’s request triggered it, or what that agent was meant to be allowed to do. Answering any of that means reconstructing intent from application logs, if they exist.

Google Cloud’s guidance notes that audit logs name the service account but not the application using it, so activity behind a shared account may not trace to the right application. The joint CISA, NSA and partner guidance (May 2026) warns that static credentials shared across agents are easy to steal, and that actions under a trusted agent identity produce logs that look legitimate.

“service-account-1 accessed the CRM” is not a finding. It is the start of an investigation with no leads.

What Agent Identity Actually Means

Agent identity is the mechanism used to distinguish one autonomous software workload from another for authentication, authorization, and auditing.

The phrase covers several things, and teams talk past each other when they don’t say which:

1. A workload identity for the agent’s runtime: a Kubernetes ServiceAccount, cloud IAM role or SPIFFE ID. Which running workload is this?
2. An application (client) identity, such as an OAuth client registered with an authorization server. Which application is requesting tokens?
3. A cryptographic identity: a certificate or key the workload uses to prove it holds the identity it claims.
4. A delegated identity representing a user: authority a person granted the agent. Strictly, this is what the agent may do for someone, not the agent’s own identity.
5. A combination, which is what most deployments need.

Terms worth keeping apart:

Term	Meaning	Not the same as
Service account	A non-human principal in an IAM system	An API key, which is a static secret
Delegation	The agent acts for a user and keeps its own identity	Impersonation, where it acts as the user

OAuth defines how clients obtain tokens. It does not give an AI agent its own client registration, and no token is an agent identity by itself. Service accounts are not inherently insecure either. The trouble is sharing them, giving them long-lived keys, and over-granting.

Authentication answers “who are you?” Authorization answers “what are you allowed to do?” Auditability answers “what happened, and under whose authority?”

Agents need all three. A name in a config file proves nothing, so authentication needs proof. Behavior isn’t fixed by code, so authorization must be enforced outside the model. Actions fan out across tools and sub-agents, so the audit record must carry user, agent and authority.

Why Agent Identity Breaks the Old Backend Model

A traditional backend is deterministic where access control cares: its code fixes the calls it can make. A reviewer can read the source, list the APIs, and write a matching permission set.

An agentic workload breaks that link. The model picks tools at runtime from its context, and that context can include untrusted text: tickets, emails, web pages, tool output. The same binary and credential can make different calls depending on what it reads. That is an architectural property, not a claim about intent.

More differences compound it:

• Asynchronous and event-driven work runs after the human leaves, or with no human at all.
• Delegation chains form as agents hand work to sub-agents and tools, which the CISA-led guidance says operators may not see.
• Stale decisions accumulate when permissions are checked once at startup, leaving an old “allow” an attacker can reuse.

The OpenID Foundation’s October 2025 whitepaper, Identity Management for Agentic AI, argues that enterprises should treat agents as first-class citizens in their identity systems, and lists workload differentiation and delegated authority among the open questions. NIST’s NCCoE raised related questions in a February 2026 concept paper. It proposes a possible project. It is not a standard.

Agent Identity Is Not User Identity

Five questions are in play when an agent calls an API, and each can have a different answer:

• Who is the human? The user whose request or consent started the work.
• Which agent is acting? The distinct software actor.
• What runtime executes it? The service, version and instance.
• What resource is accessed? The API or data targeted.
• Who authorized the action? The grant or policy that allowed it.

A shared credential typically answers at most one. Collapse them and you lose boundaries.

Borrow the user’s token and you get impersonation: the agent inherits everything the user can do, and the user’s history fills with actions they never took. Use a shared service account and the API sees neither user nor agent. Give the agent its own identity but ignore the user, and it may read data the requester was never cleared for. That is the confused deputy problem, which the CISA-led guidance gives as an example of privilege risk.

Separate identities let you limit or revoke the agent without touching the human, and tell you afterward whose authority an action rode on.

How Agent Identity Changes the Audit Trail

Here are the weak and stronger patterns:

Weak:      User → Agent → Shared Service Account → API
Stronger:  User → Delegated Authorization → Specific Agent Identity → Scoped Token → API

Don’t treat the second line as the one correct flow. Some systems use OAuth token exchange, others workload identity federation or a credential-minting gateway. The principle is what matters: the authorization decision should preserve enough identity context to answer who initiated the action, which agent executed it, and what authority was granted.

Illustrative log lines, not from a real system:

Weak:
principal=agent-prod-service-account  action=crm.contacts.export  result=allowed

Stronger:
subject=user:a.rao  actor=agent:support-triage  runtime=pod/support-triage-7f9c
audience=crm-api  scope="tickets:read tickets:update"
action=crm.contacts.export  result=denied  reason=scope_not_granted

Here the injected export may simply have been denied, because the support agent’s grant never included it. Had it succeeded, the log would still name the agent, the user and the grant. That is the gap between an incident you scope from the log and one you reconstruct from guesses.

Short-Lived Credentials and Scoped Tokens

Long-lived API keys fail predictably. They get pasted into configs, CI variables and tool definitions. Anyone holding a bearer credential can use it, and rotation is painful enough to be skipped. Google adds the audit angle: when a service account key authenticates, there is no reliable way to tell who used it.

Short-lived, scoped credentials change that:

• Expiration shortens the window for a stolen token.
• Scope limits the token to the operations the task needs, like tickets:read.
• Audience limits it to a named resource server. RFC 9700, the OAuth security best current practice, treats audience-restricted tokens as a defense against stolen-token misuse. The MCP authorization specification builds on RFC 8707 resource indicators and forbids token passthrough.
• Sender constraint (mutual TLS, DPoP) binds a token to a key, so a copy is useless alone.
• Rotation versus revocation: rotation replaces credentials on a schedule, revocation kills one now. RFC 8693 says propagating revocation across exchanged tokens is implementation-specific, so short lifetimes are your backstop.

Platforms lean this way. AWS recommends temporary credentials via IAM roles over long-term keys. Kubernetes projected tokens are time-bound, audience-bound and kubelet-rotated.

But a ten-minute token is plenty for an automated export, a compromised agent can request fresh ones, and an injected agent uses its legitimate credentials inside its granted scope. Short-lived credentials reduce exposure. They don’t remove the compromise.

Delegation: Acting on Behalf of a User

There is a real difference between “the agent is the user” and “the agent is acting on behalf of the user.”

RFC 8693 names both. Under impersonation, the acting party holds all the user’s rights in some context and is indistinguishable from them. Under delegation, the agent keeps its own identity, the user hands over some rights, and actions are understood as the agent representing the user. In token terms the user is the subject, the agent appears in an act claim, and a may_act claim states who may act for whom. The authorization server decides by policy whether to issue such a token.

Take a finance employee who asks an expense agent for approved expense reports. The agent shouldn’t inherit everything the employee can reach, which may include payroll exports and cloud consoles. The authorization should capture:

• Who: the employee, as subject.
• Which agent: the expense agent, as actor.
• Which resource: the expense API, as audience.
• Operation and scope: read approved reports for that cost center, for this task.

Teams usually aim for the overlap of what the user may do and what the agent is meant to do. Delegation doesn’t compute that for you. Policy does.

Two caveats. RFC 8693 says only top-level claims and the current actor count in access decisions, and earlier actors in a nested act chain are informational. And support varies: Microsoft documents an on-behalf-of flow for Entra Agent ID, and Google Cloud Agent Identity supports user-delegated OAuth, but those are vendor implementations.

What a Stolen Agent Credential Can Reach

Take the shared agent-prod-service-account. These examples are illustrative.

	Before: shared credential	After: distinct identities
Reach if the support agent’s credential is stolen	CRM, email, database, internal APIs, storage, cloud resources	Only what the support agent was granted
Support agent can	Everything the account can	Read tickets; update ticket status
Support agent cannot	Nothing is structurally blocked	Access payroll; modify cloud infrastructure; read customer payment credentials
Finance agent	Same as above	Can read approved financial records; cannot modify engineering infrastructure
Containment	Disable the account and every agent stops	Disable one identity; the others keep running

Why is “before” so wide? Shared accounts drift toward the union of every agent’s needs, and Google observes they keep gaining access as applications diverge.

Separate credentials don’t create least privilege on their own. Copy an overbroad role onto four identities and you have four overbroad agents. Identity gives you the unit to attach narrow grants to and the attribution to prove they held. The policy work remains. The CISA-led guidance also flags lateral movement across poorly segmented environments, so a narrow identity inside a flat network is no fix.

Agent Identity Is One Layer, Not the Whole Defense

Three controls get conflated, and they do different jobs:

• Prompt-injection defenses ask whether the agent can be manipulated. Our piece on testing agents for prompt injection covers that layer.
• Sandboxing limits what the agent can reach. Our look at NVIDIA’s open agent safety platform covers one approach.
• Identity and authorization decide what the agent may do and who answers for it.

None replaces the others. Identity doesn’t stop injection: a manipulated agent still acts inside its grants. A sandbox can’t tell a legitimate call from a malicious one carrying a valid credential. And identity weakens if the sandbox leaks the credential. On Google Cloud VMs, any code on the machine can by default request tokens for the attached service account from the metadata server.

That is defense in depth, which the CISA-led guidance asks for. OWASP’s agentic Top 10 lists identity and privilege abuse (ASI03) separately from goal hijacking. For tooling choices, see our review guide to ten agent frameworks.

The Agent Identity Architecture Teams Should Aim For

No single product defines this, but the shape is consistent.

Each hop should log, where supported: user, agent, session or request ID, resource, action, authorization scope, timestamp and outcome. The CISA-led guidance adds a central policy decision point on every request, a trusted registry of agents, and fresh cryptographic proof before privileged calls.

The right build depends on your stack:

Pattern	Strength	Tradeoff
IAM role or service account per agent	Native policy and logs	Per deployment; doesn’t separate users or sessions
Kubernetes ServiceAccount per agent	Bound, expiring tokens	Agents sharing one ServiceAccount share an identity
SPIFFE / SPIRE	Attested, short-lived, cross-platform	Gives authentication, not authorization; more to run
OAuth client plus token exchange	Expresses delegation	Needs authorization server support
Vendor agent-identity services	Integrated governance	Not portable

Microsoft’s Entra Agent ID guidance recommends a unique identity per agent instance under a blueprint that holds the credential, with a named sponsor. Disabling a blueprint blocks all its identities, which is useful and coarse. Google’s Agent Identity gives each agent a SPIFFE-based principal with certificate-bound tokens.

A Checklist for Agent Identity You Can Apply This Week

Identity

• List every independently acting agent, including sub-agents and scheduled jobs. Does each have its own identity?
• Pull yesterday’s logs. Can you tell agents apart by principal alone?

Credentials

• Search repos, CI variables and configs for long-lived shared keys.
• Swap in short-lived, audience-bound credentials where the platform allows.

Authorization

• Compare each agent’s needs with what it can do today.
• Evaluate user and agent permissions separately, on every request.

Delegation

• Name the human behind one recent action.
• Record “on behalf of” as subject plus actor, not a reused user token.

Auditability

• Reconstruct one action: initiator, executing agent, permission used, resource touched.

Incident response

• In staging, revoke one agent’s credential. Do the others keep working?
• Rotate one credential alone, and time it.
• Give each agent a named owner.

If you do only two, do the log test and the revocation test. They show quickly whether you have agent identity or a shared account with extra names.

FAQ

What is agent identity?

Agent identity is the mechanism used to distinguish one autonomous software workload from another for authentication, authorization, and auditing. In practice it combines a workload or client identity, cryptographic proof and, where relevant, delegated user authority.

Why shouldn’t AI agents share a service account?

A shared account hides which agent acted, merges every agent’s permissions, and means containing one agent disables all of them. Distinct identities restore attribution, narrow grants and per-agent revocation.

Should every AI agent have its own service account?

Not necessarily. Each independently acting agent should be attributable and hold only the authority it needs, whether through a service account, Kubernetes ServiceAccount, OAuth client, SPIFFE ID or vendor agent identity.

What is the difference between agent identity and user identity?

User identity says which human is involved. Agent identity says which software actor is acting. Delegation links them, so the agent acts for the user while keeping its own identity.

What are short-lived credentials for AI agents?

Credentials that expire quickly, often in minutes to hours, with narrow scope and audience. They shorten a stolen credential’s useful life but don’t prevent theft.

How does delegated authorization work for AI agents?

A user grants an agent limited authority. With OAuth token exchange (RFC 8693), the token can name the user as subject and the agent as actor. Support depends on your authorization server.

Does agent identity prevent prompt injection?

No. It limits and explains what a manipulated agent can do. Pair it with injection defenses and sandboxing.

How can organizations audit AI agent actions?

Record user, agent, request, resource, action, scope, timestamp and outcome for each call, alert on identity and privilege changes, and test by reconstructing a past action.

---

Keep reading

Here are the latest posts from the blog.