# AI agent identity: a name each agent can prove, an owner, and who it acts for

> AI agent identity is a verifiable credential issued to one agent that tells every service which agent is calling, which code it runs, who owns it and, on each request, which person it acts for. It replaces shared API keys and borrowed user tokens with short-lived credentials from your cloud, your identity provider or SPIFFE, so every action traces to one agent and one accountable owner.

Source: https://agentfort.net/agent-security/identity · Updated 2026-10-28 · AgentFort

## What AI agent identity is

AI agent identity is a workload credential issued to one agent that lets every service it calls verify which agent is calling. The agent proves it with a short-lived certificate or token, not with a password someone typed or a key someone pasted.

An AI agent is a non-human identity, like a service account, so non-human identity for AI agents starts from the same building blocks. An agent behaves differently, though. It picks which tools to call at runtime. It may act for a specific person. Its behavior changes when its code, model or instructions change. A service account answers one question: which workload is this? An agent identity has to answer four, covered below.

Identity is the base the other controls stand on. [Authorization](/agent-security/authorization) needs a subject to write rules about. An [audit trail](/agent-security/audit) needs a name that means exactly one agent. [Discovery](/agent-security/discovery) needs a key to join evidence on. This page is part of our [practical guide to AI agent security](/agent-security/).

The worked examples below use Northwind, a simulated company from AgentFort's lab demos. Northwind runs an invoice reconciler on AWS and a support triage agent on Kubernetes. It also has a support lead's assistant on a laptop and a batch job with no identity at all.

## Why shared API keys and borrowed user tokens fail

Most agents today authenticate in one of two ways. Both break accountability.

### Shared API keys

A team creates one API key for a service and hands it to every agent that needs the service. The key can usually do everything the service allows. It rarely expires. It lives in an environment variable or a config file that several people can read.

Three problems follow. You can't tell which agent made a call, because every agent presents the same key. You can't revoke one agent without breaking the others. And a leaked key works for anyone, from anywhere, until someone notices. The [OWASP Non-Human Identities Top 10](https://owasp.github.io/www-project-non-human-identities-top-10/2025/) lists both halves of this pattern: NHI7 Long-Lived Secrets and NHI9 NHI Reuse.

### Borrowed user tokens

The other pattern gives the agent a person's session or OAuth token. The agent then calls services as that person. Logs say the person did it. The agent gets every permission the person has, not the few its task needs.

The Model Context Protocol (MCP) specification forbids the MCP version of this. A server must not accept tokens that were not issued for it, and must not pass a client's token through to a downstream API. Its [security best practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) name the audit problem directly: downstream logs can show a different identity from the one that forwarded the request, which makes investigation harder. See [MCP security](/agent-security/mcp-security) for the rest of the protocol's controls.

## What an agent identity must carry

An identity is useful only if it answers the questions a reviewer asks about any action. For an agent there are four.

| Question | What carries the answer | Northwind example |
|---|---|---|
| Who is this agent? | A stable, unique name in your namespace | `spiffe://northwind.example/agents/invoice-reconciler` |
| Which code is running? | Attested workload properties: image digest, binary path, Kubernetes namespace and service account | Container image digest in namespace `finance` |
| Who owns it? | A named person or team, bound to the identity when it is issued | Finance platform team |
| Who does it act for right now? | A per-request subject, kept separate from the agent's own identity | Priya, a support lead, for this one call |

The first three change rarely and belong to the agent. The fourth changes on every request and belongs to the call. Keep them apart. If you fold the person into the agent's credential, you are back to borrowed tokens. If you fold the agent into the person's, the logs blame the person for what the agent did.

Two more properties matter. A short lifetime means a stolen credential expires before it is useful. An audience limits each token to the one service it was minted for.

## Three sources of agent identity

Don't build a new identity system for agents if a working one exists. Use what the agent already has, and issue something new only where nothing exists. In practice there are three sources.

### Existing cloud workload identity

An agent running on AWS can run under an IAM role and receive temporary credentials from AWS Security Token Service (STS). AWS [documents](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) that these can last "anywhere from a few minutes to several hours". After that, AWS rejects them. You don't embed long-term keys in the application. Google Cloud service accounts attached to a workload play the same role. This is workload identity for agents at its simplest: the platform already knows the workload.

Northwind's invoice reconciler runs on AWS under a role. The role is a good identity as long as no other workload shares it. Its limits: a role says which workload is calling, not which person it serves, and it means little outside that cloud without federation.

### An identity provider

Many agents are registered as applications in an identity provider (IdP) such as Microsoft Entra ID or Okta. Services already trust the IdP's tokens. With [workload identity federation](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation), an Entra app can trust tokens from a Kubernetes service account, so the agent stores no secret. Microsoft also lists GitHub Actions, other clouds and SPIFFE/SPIRE workloads as supported sources, as of October 2026.

The IdP is also where acting-for usually starts. An assistant signs its user in and receives tokens for that person. At Northwind, Support Triage is an Entra app that trusts its Kubernetes service account. Priya's assistant signs in with Okta and acts for her.

### Issuing one with SPIFFE and SPIRE

When an agent has neither, issue an identity. SPIFFE (Secure Production Identity Framework for Everyone) is a set of open standards for identifying software. A [SPIFFE ID](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/) is a URI of the form `spiffe://<trust domain>/<workload identifier>`. The agent proves it with an SVID (SPIFFE Verifiable Identity Document), which is either an X.509 certificate or a JWT. The SPIFFE docs advise X.509-SVIDs where possible, because tokens can be replayed. SPIRE is the project's open-source implementation that attests workloads and issues SVIDs.

SPIFFE for AI agents makes most sense where nothing else exists: plain processes, scripts and virtual machines. Northwind's batch job is one. It has no cloud role and no login.

### Comparing identity approaches for agents

| Approach | Identifies the agent? | Long-lived secret on the agent? | Lifetime | Shows who it acts for? | Main gap |
|---|---|---|---|---|---|
| Shared API key | No | Yes | Often none | No | No attribution; revoking one agent breaks all |
| Borrowed user token | No, shows the user | Often, a refresh token | Set by the IdP | Only as impersonation | Agent gets all of the user's rights |
| Cloud workload identity (IAM role, service account) | Yes, if one role per agent | No | Minutes to hours | No | Cloud-specific; roles get shared |
| IdP app with federation | Yes | No with federation; yes with a client secret | Set by the IdP | Yes, with delegated flows | Old client secrets linger |
| SPIFFE SVID from SPIRE | Yes, bound to attested properties | No; short-lived keys from a local API | Short, rotated automatically | No; pair with token exchange | You run the issuer |
| Token exchange (RFC 8693) on top | Adds the agent as actor | Depends on the base credential | Per exchange | Yes, with an `act` claim | Needs an authorization server that supports it |

## Workload attestation and short-lived credentials

### Attestation: proving which code is running

A credential proves possession. Attestation proves what is asking for it. [SPIRE](https://spiffe.io/docs/latest/spire-about/spire-concepts/) splits this into two steps. Node attestation verifies the machine, using evidence such as a cloud instance identity document or a join token. Workload attestation then asks, in SPIRE's words, "Who is this process?" The SPIRE agent asks the node's kernel for the caller's process ID, gathers its properties and matches them against registration entries. Selectors include the Unix user, group and path, and the Kubernetes namespace and service account.

Bind each agent's identity to the narrowest properties you can maintain. A Kubernetes service account used by one deployment is strong. A Unix user shared by 10 scripts is weak. Add the image digest or binary path where your tooling supports it, so a code change shows up as an identity event.

Attestation has limits. It proves which program is running. It doesn't prove the program is safe, or that the text in its context is trustworthy. A correctly attested agent can still be steered by a prompt injection. That is the job of authorization and [sandboxing](/agent-security/sandboxing).

### Short-lived, audience-bound credentials

Issue credentials that expire in minutes, not months. SPIFFE's design calls for keys and certificates that are "short lived, rotated frequently and automatically". The workload fetches a fresh credential from a local API before the old one expires, so nobody rotates anything by hand. A stolen five-minute certificate is a nuisance. A stolen key with no expiry is an incident.

Short lifetimes also simplify revocation. To cut an agent off, stop issuing to it. Its last credential runs out within minutes, without a revocation list every service must check.

Bind every token to one audience as well. A service should reject any token not issued for it, which is exactly what the MCP specification requires of MCP servers. Then a token copied from the CRM's logs can't be replayed against the billing API.

## Acting for a user: delegation with OAuth token exchange

Many agents act for a person: an assistant that updates its user's cases, or an agent that books travel for an employee. For AI agents acting on behalf of users, a service needs to know both parties. The agent is the actor. The person is the subject.

[RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693), OAuth 2.0 Token Exchange, defines how to ask for that token. The client sends a `subject_token` for the person and an `actor_token` for the agent to an authorization server. The RFC separates two outcomes. With impersonation, the holder gets the subject's rights and is indistinguishable from the subject. With delegation, the agent "still has its own identity separate from" the person. Choose delegation for agents.

A delegated token names the agent in an `act` claim:

```json
{
  "sub": "priya@northwind.example",
  "aud": "https://crm.northwind.example",
  "scope": "cases:update",
  "act": { "sub": "spiffe://northwind.example/agents/priya-assistant" },
  "exp": 1793196600
}
```

Nested `act` claims record a chain, such as one agent calling another. The RFC says the outermost `act` is the current actor and nested ones are "informational only" for access decisions. A `may_act` claim states which parties may act for a subject.

Two rules keep acting-for safe. The agent's effective rights are the overlap of its own grant and the person's rights, so Priya's assistant can update Priya's cases but not Lena's. And the person an agent acts for shouldn't approve that agent's risky requests. Route them to someone else, as described in [human approval for agent actions](/agent-security/human-approval). Where downstream services can't read an `act` claim, enforce acting-for at a gateway in front of them.

## Agent ownership and lifecycle

An identity without an owner is a liability. Someone must answer for what the agent does, approve its access and decide when it stops. Microsoft's [Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/agent-owners-sponsors-managers) model is a useful reference, as of October 2026. It separates technical owners, who manage configuration and credentials, from business sponsors, who are "accountable for the agent's purpose and lifecycle decisions". Entra requires at least one sponsor for every agent identity.

Plan the agent identity lifecycle around four events:

1. **Onboarding.** Register the agent from discovery evidence. Record its owner, purpose, code location and the services it needs. Issue the identity only after the owner confirms what it will cover, including the code.
2. **Code change.** Treat a new image digest or binary hash as a change to review. Either reissue through your deployment pipeline with a recorded approval, or suspend the identity until the owner accepts the new code.
3. **Owner change.** When an owner moves or leaves, reassign the agent before their account is disabled. Group ownership absorbs turnover.
4. **Offboarding.** Revoke the identity, remove its grants, delete stored secrets and record the date. Improper offboarding is the first entry (NHI1) in the OWASP Non-Human Identities Top 10.

Orphaned agents are the usual gap. Pick a threshold, such as 90 days without activity or an owner who has left, and treat matches as offboarding candidates. [Discovery](/agent-security/discovery) finds them.

## AI agent identity checklist

- Give every agent its own identity, and retire shared API keys one service at a time.
- Reuse cloud roles and IdP apps where each one maps to exactly one agent.
- Issue a SPIFFE identity to agents that have nothing, after the owner approves.
- Bind each identity to attested properties: service account, namespace, image digest or binary path.
- Set credential lifetimes in minutes, and bind every token to one audience.
- Represent acting-for with delegation and an `act` claim, never by handing the agent a user's token.
- Record a technical owner and a business sponsor for every agent identity.
- Suspend an identity when the agent's code changes, until someone accepts the change.
- Use separate identities for development, test and production.
- Revoke identities of agents with no owner or no recent activity.
- Log the agent, its owner and the person it acts for on every request, as described in [AI agent audit trails](/agent-security/audit).

## How AgentFort handles this

AgentFort Identity follows one rule. If an agent already has an identity, use it. If it signs in through an identity provider, plug into that provider. If nothing exists, AgentFort issues a SPIFFE identity itself. An agent with an AWS role signs a request with its own credentials, and AWS confirms who it is. The agent then gets a certificate named after its role, valid for five minutes. For an agent with nothing, the AgentFort host agent asks the kernel which program is calling. Nothing is issued until the owner approves exactly what they see, including the code. If the code changes, the identity stops until someone accepts it. An agent nobody owns gets no identity. When an agent has several identities, AgentFort picks the strongest and shows why. See [AgentFort Identity](/platform/identity) or [request a demo](/demo).

## Frequently asked questions

### Is an AI agent a non-human identity?

Yes. An AI agent authenticates as software, so it belongs in your non-human identity (NHI) program next to service accounts, API keys and certificates. It needs more than a typical service account record, though: a named owner, the code it runs, and a way to show which person it acts for on each request. Without those, an NHI inventory shows that a credential exists, but not which agent used it or why.

### Should each instance of an AI agent get its own identity?

Usually not. Give one identity to each logical agent: the same code, the same owner and the same purpose. Its replicas or pods share that identity, but each one fetches its own short-lived credential. Record the instance, such as the pod or host, in every log entry so investigators can still find the exact process. Create a separate identity whenever the code, the owner or the permissions differ.

### Can an AI agent have more than one identity?

Often it does: a cloud role, an app registration in the identity provider and perhaps a SPIFFE ID. That is fine if all of them map to one inventory entry and one owner. Use the strongest one for access decisions, meaning the one bound to attested workload properties with the shortest lifetime. Retire the credentials nobody uses, because each extra one is another thing that can leak.

### Can an AI agent use the same identity in development and production?

It shouldn't. Use a separate identity per environment, ideally in separate trust domains. Development identities tend to have looser controls, more people with access and credentials on laptops. If the same identity also works in production, a leak in development becomes a production incident. OWASP lists this pattern as NHI8 Environment Isolation in its Non-Human Identities Top 10 for 2025.

### Do I need SPIRE to use SPIFFE identities for AI agents?

No. SPIFFE is a set of open standards, and SPIRE is the project's open-source implementation that attests workloads and issues credentials. Any issuer that follows the specifications produces identities a SPIFFE-aware service can verify against the issuer's trust bundle. SPIRE is a sensible start when you need to issue identities to plain processes and virtual machines and want to run the issuer yourself.

## Sources

- [SPIFFE Concepts (SPIFFE ID, SVID, trust domain, Workload API)](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/)
- [SPIRE Concepts (node and workload attestation)](https://spiffe.io/docs/latest/spire-about/spire-concepts/)
- [RFC 8693: OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693)
- [Temporary security credentials in IAM, AWS documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
- [Workload identity federation, Microsoft Entra documentation](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation)
- [Agent owners, sponsors and managers, Microsoft Entra Agent ID documentation](https://learn.microsoft.com/en-us/entra/agent-id/agent-owners-sponsors-managers)
- [OWASP Non-Human Identities Top 10 (2025)](https://owasp.github.io/www-project-non-human-identities-top-10/2025/)
- [Security Best Practices, Model Context Protocol (2026-07-28)](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices)