What is AI agent identity?

Most AI agents reach production systems with a key someone pasted into their environment. The database then sees a service account: not the agent, not the session, and not the engineer who started it. AI agent identity replaces that anonymous key with a name the receiving system can verify and a link to the person behind the run.

What does AI agent identity include?

AI agent identity is the verifiable identity an AI agent presents when it calls a database, server or API, together with the identity of the person it acts for. The first part proves which agent, platform and session sent the request. The second part ties the action to a human, so policies and audit logs can use both.

Agentic identity, agent identity and AI identity name the same idea, with different scopes depending on who uses them. Some mean registering agents in an identity provider, some mean the credentials agents carry, others mean the audit trail. This page covers the whole chain: who the agent is, who it works for, and how both show up on each request.

Identity is not the same as a credential or a permission. A credential, such as a token or an API key, is the proof an agent presents. Authorization decides what that identity may do, which is the job of AI access control. Identity sits underneath both: a credential with no named identity behind it only proves that someone holds the key.

Should AI agents have their own identity?

Yes. An agent that borrows a person’s session, or shares one service key with other agents, can’t be told apart from them. Every action looks like the person or like the shared account, so you can’t revoke one agent, scope one task, or explain afterwards which run deleted a row. The risk grows with every agent that shares the key.

The OpenID Foundation reached the same conclusion in its October 2025 whitepaper on identity management for agentic AI. It says enterprises “need to begin treating agents as first-class citizens within their identity and access management infrastructure”. It also names recursive delegation chains and trust across organizations as problems that current frameworks weren’t designed for.

Here’s what matters in practice: an agent’s own identity doesn’t replace the person’s. Most agents act because someone asked them to, so the useful model keeps both, the agent as the actor and the person as the one it acts for. Every later section of this guide builds on that pair.

How are AI agents identified?

An AI agent is identified by whatever its environment can prove about it. Three signals are common, from weakest to strongest:

• A static credential. An API key or a client ID names a configuration, not a run. Every session that copies the key looks identical to the server.
• Platform-signed token claims. Cloud agent platforms and CI systems can sign a short-lived token that names the organization, the session, the repository and often the person who started it. The receiving service checks the signature, then reads the claims as context for its decision.
• A workload identity. SPIFFE gives each workload an ID, a URI such as spiffe://example.org/ns/prod/sa/agent, and signed documents called SVIDs, which expire quickly, to prove it.

Local agents vs cloud agents

Coding agents on a laptop are the hard case. Claude Code, Codex or Cursor run as the engineer’s operating system user, with the engineer’s files, keys and browser sessions, so there’s no separate token to check. At the network layer, the reliable signal is the process itself: its code signature, its executable and the child processes it starts.

Cloud agents are easier. Each session runs in its own sandbox or VM, and platforms such as Devin sign a token for every session. The receiving system gets a distinct identity per run, which a laptop agent sharing the engineer’s login never has. Most teams run both kinds, so they need both kinds of signal.

AI agent identity vs human and non-human identity

An AI agent belongs to the non-human group, but it behaves unlike the rest of it. A non-human identity (NHI) is any identity that isn’t a person: service accounts, API keys, CI jobs and workloads. Machine identity usually means the same set, with a focus on certificates and keys. Agents differ in two ways: they act autonomously, picking their next action, and they usually act for a specific person.

The behavior row is the one that changes the controls. A service account runs the same queries every day, so reviewing its access once goes a long way. An agent’s next query or tool call depends on its prompt and on content it reads, including content an attacker wrote, so its access needs a check on every request, not only at login.

How do AI agents authenticate?

The safest default is a short-lived token that the agent’s platform signs for each session, exchanged for a credential scoped to one service. Static keys stay common because they take a minute to set up. Each of the AI agent authentication methods below trades setup effort for blast radius:

Platform tokens rarely go straight to the database. The usual pattern is an exchange: a broker verifies the agent’s token and returns a narrower credential for one resource, valid for a short time. The platform token then never reaches downstream systems, and each resource gets a credential it can check and expire on its own terms.

How does agentic identity tie an agent to a person?

Delegation is the link between the agent and the human it acts for. The agent’s token carries a claim, such as the email of the person who started the session, and the receiving system resolves it to a known user. Policies and logs then see two identities on every request: the agent as the actor and the person as the end user.

Here’s the catch: the two identities aren’t proven the same way. The receiving system verifies the agent’s token with the issuer’s signing keys, but the person is a statement the agent’s platform makes inside that token. You accept it because you trust that platform, so limit which issuers can make that statement and for which organization.

Three rules keep delegation safe:

• Take scope from signed claims only. Which person and which session a grant covers comes from the verified token, never from text the agent writes in its own request.
• Fail closed. If the person in the claim doesn’t match a known user, issue no credential, rather than falling back to the agent alone.
• Separate requester and approver. The agent can ask for access, but a different identity creates the grant, so the agent can never approve itself.

Standards are catching up. OAuth 2.0 Token Exchange (RFC 8693) defines an act (actor) claim, so one token can name both the subject and the party acting for it. Approving access per session, with an expiry, is the subject of just-in-time access: each grant covers one task and ends on its own.

AI agent identity management and governance

AI agent identity management is the lifecycle of each agent identity. AI agent identity governance is the set of owners, rules and reviews that keeps that lifecycle under control. Both reuse what identity security teams already do for privileged human access, on a shorter clock:

• Register with an owner. Every agent identity has a named owner and a stated purpose. An identity nobody owns is an identity nobody revokes.
• Issue short-lived credentials. Prefer minutes or hours to months. A credential derived from a platform token should never outlive the token it came from.
• Scope to the task. Grant the least privilege the task needs, and keep sensitive access behind an approval so nothing sensitive is held by default.
• Record both identities. Each log entry names the agent identity, the person it acted for and the claims behind them, so the audit trail shows who asked for what.
• Review and expire. Review agent identities on a schedule, and remove those whose owner left or whose platform you no longer use.

Scale changes the method, not the rules. A team with a few agent platforms needs one trust configuration per platform, not one credential per agent: each platform signs tokens per session, and the receiving system maps them to an agent identity plus the person. A new engineer who starts using agents then needs no new secret.

Agents that run queries, read sensitive data or run shell commands hold privileged access, so the usual PAM controls apply to them as well: brokered credentials, approvals for sensitive actions and recorded sessions. Treat each agent identity as a privileged account from the day it gets production access.

Common agentic identity mistakes

• One key for every agent. A single API key in a shared environment makes every agent run the same identity. Rotating it breaks all of them, and logs can’t separate one run from another.
• Secrets baked into images or environment variables. Anything in the agent’s environment is readable by the agent, and by any instruction that convinces it to print or send that value.
• Borrowing an engineer’s personal token. The agent inherits every permission the engineer has, and the logs blame the engineer for what the agent did.
• Trusting the agent’s word about who it works for. A user name in a request body is input the agent controls. Only a claim signed by a trusted issuer should set the end user.
• No end user in the logs. Without the person recorded next to the agent, an investigation stops at “the agent did it”.
• Identities with no owner or expiry. Test agents and one-off integrations outlive their projects, keeping access nobody remembers granting.
• Agents that can grant their own access. If the agent’s identity can create the exception that unblocks it, the approval step protects nothing.

How does Formal handle AI agent identity?

Formal doesn’t issue identities to agents. It trusts the identity the agent’s platform already issues, maps it to a Formal identity, and enforces policy on every request that identity makes, at the Formal Connector in front of resources and at the Formal Endpoint on hosts.

Formal identities are users and groups, and every user is human or machine. Agents get machine users: the identities docs list AI code agents next to BI tools and CI/CD pipelines. An OIDC integration checks a platform-signed JWT’s issuer, its audience and a CEL claim condition, then runs the caller as the integration’s machine user.

The same trust mints a federation token: a short-lived Connector credential that carries the source claims. It expires at the earlier of the upstream token’s expiry and one hour, and only OIDC-authenticated machine users can mint one; API keys and human sessions can’t. The Connector accepts it on protocols such as Postgres and SSH.

An End-User Email Expression adds the person. It reads a claim from the verified token and resolves it to a Formal user. If no user matches, minting fails closed and Formal issues no token. Sessions then use the machine user for credentials and the person as the end user for policy and audit.

Connector policies see both identities: input.user.type (human or machine), input.end_user for the person, and the verified claims under input.user.oidc.claims. Upstream secrets stay on the Connector: with Native Users, Formal identities never need to know or send the database password or SSH key.

On hosts, the Formal Endpoint logs in with OIDC from token sources including AWS, Azure, GCP, GitHub Actions, SPIFFE, an environment variable or a file (Endpoint OIDC docs), so no long-lived Formal credential sits on the host. For laptop agents, network rules recognize known agents by code signature on macOS, so a rule can inspect an agent’s traffic and leave the engineer’s browser alone.

The Devin integration shows the full loop on a database: a policy denies Devin until the human behind that session says yes in Slack, and the exception covers that one session. The Cursor integration covers Cloud Agents through the Endpoint, with no Formal API key in the environment. Formal PAM applies the same identities to databases, SSH and Kubernetes.

At Cursor, Cloud Agents connect through a dedicated Formal identity with limited access, and end-user identity propagation adds the employee who started the task (case study). That gives the security team two separate levers: the workflow’s own access and the employee’s permissions.

“We’ve limited the amount of data that those cloud agents can access and we’re able to tie that back to the specific user who is using that cloud agent, which is a feature that I’m only aware of Formal having.”

— Roy Xu, Software Engineer, Security @ Cursor

The reasoning behind this design, including the trust trade-off in the human claim, is in Giving Cloud Agents Production Access with OIDC, Not Secrets. The authorization policies that decide what an identified agent may do are covered on the platform page.