Quick Answer: AI agent identity is the agent's own name and credential in your systems, plus a record of who it acts for and which human answers for it. Without it, every action an agent takes looks like it came from a person or from nobody.
At 03:12 on a Tuesday, a hundred rows disappear from the CRM. The audit log says j.smith. Was it J. Smith, or the agent she connected with her token last month? If you can't answer that in one query, you don't have an AI agent identity problem waiting to happen. You already have one.
AI agent identity is the part of agent security that comes before everything else. Before you can decide what an agent may touch, you have to know which agent is asking, who it is asking for, and who to call when it misbehaves. In September 2026 four vendors shipped or announced products built around exactly those questions. This guide explains the model behind them, how it differs from the non-human identities you already manage, and how to put it in place without buying a platform.
We build cowork.ink, where every AI coworker has its own computer and shows up in Slack or Telegram under its own name, so this question isn't theoretical for us. The principles below apply to any agent you run.
What is AI agent identity?
AI agent identity is a unique, verifiable identity for one agent, which systems use to authenticate it, authorize it and attribute its actions to it. It is the agent's equivalent of an employee's account: a name in a directory, a credential nobody else holds, and an entry in every log line it produces.
A useful agent identity answers three questions on every request:
- Who is this? A stable, unique identifier for this agent, not a shared key used by five of them.
- Who is it acting for? Sometimes itself (a scheduled report), sometimes a person (a request in Slack), sometimes another agent (a sub-task). The answer can change from one request to the next.
- Who answers for it? A named human, often called the owner or sponsor, who is accountable when it misbehaves and decides when it retires.
The title of this article adds a fourth question: what may it touch? That one is about permissions, and it depends entirely on the first three. A permission attached to an identity nobody can trace isn't a control. It's a hope. We cover scoping in depth in our guide to AI agent permissions; this article covers the identity those permissions hang on.
If you can't name the agent, the person it acted for and the human who owns it from a single log entry, you don't have agent identity yet. You have authentication.
How is an AI agent different from other non-human identities?
An AI agent is a non-human identity that decides what to do next at runtime, so the controls built for static service accounts under-describe it. Non-human identity (NHI) is the umbrella term for every identity that isn't a person: service accounts, API keys, OAuth clients, CI/CD pipelines, workloads, bots and now AI agents.
The category was already large before agents arrived. CyberArk's 2025 Identity Security Landscape counted 82 machine identities for every human in organizations worldwide, and 68% of respondents said their organization lacked identity security controls for AI (CyberArk, April 2025).
What makes an agent different from the other NHIs is not what it authenticates with. It's how it behaves once it's in:
| Human user | Service account / API key | AI agent | |
|---|---|---|---|
| Who decides the next step | The person | Code written in advance | The model, at runtime |
| Typical credential | Password + MFA, SSO | Long-lived secret or certificate | Should be its own short-lived token |
| Acts for | Itself | The application | Itself, a person or another agent — per request |
| How it goes wrong | Gets phished | Key leaks and never expires | Does something plausible nobody asked for |
| Who answers for it | The person | Whoever owns the app (often nobody) | Its sponsor, if you named one |
A service account runs the same code path every time, so you can reason about it by reading the code. An agent plans, picks tools, chains calls and retries in a different way when a step fails. Two runs with the same prompt can touch different systems. That is why the identity has to travel with every action, not just sit at the front door.
Why can't the agent just use a service account?
It can, but you lose the two things that make agent identity useful: per-agent attribution and per-agent revocation. A service account shared by every agent in a project tells you that "the AI" deleted those rows. It doesn't tell you which agent, which run, or which person's request started it. And if one agent goes wrong, revoking the shared account stops all of them.
The fix is boring: one identity per agent, the same way you'd never give three contractors one badge.
Why do borrowed logins and shared keys fail?
Because they make an agent indistinguishable from someone else, which breaks attribution, revocation and least privilege at the same time. Three patterns cause most of the damage.
The agent logs in as you
The fastest way to get an agent working is to hand it your credentials or your OAuth token. It works on day one. From then on, every action it takes is logged as you, it inherits every permission you hold, and you can't switch it off without locking yourself out.
The OpenID Foundation's whitepaper on agent identity names this directly: "User impersonation by agents should be replaced by delegated authority. Currently, agents often act indistinguishably from users, creating accountability gaps and security risks" (OpenID Foundation, October 2025).
One API key for the whole team
A single model-provider key or SaaS token, pasted into five agents and two notebooks, is the agent version of a shared admin password. When it leaks, you rotate it and break everything. When something goes wrong, the provider's logs show one caller.
The "god mode" service account
Someone creates svc-ai-agents with broad access so nothing gets blocked during the pilot. The pilot ends, the account stays. Six months later nobody remembers which agents use it, and nobody wants to be the one who removes access and breaks them.
All three patterns save an hour at setup and cost you the ability to answer "which agent did this?" for as long as they stay in place.
What does a complete agent identity contain?
A complete agent identity has five parts: a name, its own credential, a record of who it acts for, a human sponsor, and a lifecycle. Most teams have the first two and skip the last three, which are the parts that matter during an incident.
| Part | What it is | What breaks without it |
|---|---|---|
| Name | A unique, stable identifier in a registry or directory | You can't tell agents apart in logs |
| Credential | A secret or token only this agent holds, short-lived where possible | One leak compromises every agent that shares it |
| On-behalf-of | Per request: the person or agent whose authority it's using | You can't tell an agent's own action from one it did for someone |
| Sponsor | A named human accountable for the agent | Nobody to call, nobody to approve changes, nobody to retire it |
| Lifecycle | Created, reviewed, suspended, retired — with dates | Orphaned agents keep running after their purpose ends |
Name and registry
Every agent gets one entry in one list, with a name a human can read: finance-weekly-report, not agent-7f3a. The registry is where you enforce everything else, because an agent that isn't in it shouldn't be able to get a credential at all. It's also Pillar 1 of our AI agent governance framework: identity and scope are defined before the agent ships.
Sponsor
The sponsor is the most overlooked part, and the one identity platforms are now building in. Microsoft's Entra Agent ID, now generally available, separates the owners, sponsors and managers of an agent identity, and ships lifecycle workflows that reassign sponsorship when a sponsor changes roles or leaves, explicitly "to prevent orphaned agents" (Microsoft Learn).
That is the right instinct. Agents don't quit, so the only thing that ends their access is a human deciding it should end. If the human who set it up has left, that decision never happens.
Lifecycle
An agent's identity should be born with an end in mind. When the task ends, the pilot ends or the sponsor leaves, the identity is suspended and then deleted, and its credentials die with it. Write that rule down before you create the agent, not after the audit finds it.
How do AI agents authenticate?
Agents should authenticate with their own short-lived credentials, issued by a system you control, never with a human's password. The mechanics depend on where the agent runs and what it's calling, but the building blocks are standard.
- OAuth 2.1 client credentials. The agent is registered as its own OAuth client and gets tokens in its own name. This is the default for an agent acting for itself.
- Workload identity. Standards such as SPIFFE issue short-lived, automatically rotated credentials to running workloads based on where they run, so no long-lived secret sits in a config file.
- Gateway-issued tokens. A gateway verifies the agent, then mints a narrow token per connection, so the agent never holds the downstream system's credentials at all.
- MCP authorization. The Model Context Protocol's authorization spec builds on OAuth 2.1, so an MCP server can demand a token tied to a specific agent. Our MCP security best practices cover the server side.
The OpenID Foundation whitepaper is blunt about where this works: for agents operating inside a single trust domain, "existing OAuth 2.1 flows with PKCE, combined with protocols like MCP, provide robust security." The hard cases are agents that cross organizational boundaries, run asynchronously for hours, or spawn other agents.
How does an agent act on someone's behalf?
Through delegation: the agent exchanges its own token and the user's token for a new, narrower token that names both. The standard for this is OAuth 2.0 Token Exchange (RFC 8693).
The result is a token in which the user is the subject (sub), whose authority is being used, and the agent is the actor (act), who is doing the work. Every downstream system and every log line can then say "agent X, acting for Maria," instead of "Maria" or "agent X" alone.
Two properties make this better than handing over a user token:
- It's narrower. The exchanged token carries only the scopes this task needs, for as long as this task takes.
- It's attributable. The agent's identity is in the token, so the action is traceable to it, and revoking the agent doesn't revoke the user.
Identity platforms now treat the two cases separately. Entra Agent ID ships distinct Conditional Access templates for autonomous agents without user context and for agents acting on behalf of users, because the risk in each is different.
What about agents that spawn other agents?
Each hop in a delegation chain should carry less authority than the one before it. The whitepaper calls this out as an open problem: "Agents spawning sub-agents or communicating tasks to other agents create complex authorization chains without clear scope attenuation mechanisms."
Until standards settle, enforce it by policy. A sub-agent gets its own identity, inherits a subset of its parent's scopes, never a superset, and logs its parent's identity alongside the original user's. Our guide to AI agent audit trails shows how to log delegation chains so you can reconstruct them later.
What may the agent touch?
Exactly what its role needs, granted to its own identity, and nothing it can grant itself. This is where identity hands off to permissions, and the hand-off only works if the identity above is in place.
Four checks connect the two:
- Scopes attach to the agent, not to a shared role. If two agents need different access, they get different identities.
- Delegated access never exceeds the delegator's. An agent acting for Maria can do at most what Maria can, and usually much less.
- The agent can't edit its own access. Permission changes go through the sponsor, not through a tool the agent can call.
- Irreversible actions need a human. Sending money, deleting data and contacting customers go through approval; see our guide to human-in-the-loop agents.
Least privilege, role design, just-in-time access and approval thresholds are covered step by step in AI agent permissions. The short version: identity tells you who to scope; permissions tell you how much.
What did vendors launch for agent identity in September 2026?
Four vendors shipped or announced agent inventory, identity or credential controls within the same four weeks, and together they describe one model: find the agents, name them, scope their credentials. The timing isn't a coincidence. Enterprises now run agents built on half a dozen platforms, and nobody has one list of them.
| Launch | Date | What it does for agent identity |
|---|---|---|
| CrowdStrike Falcon Guardian | Sep 1 | Discovers known and shadow agents on Windows and macOS, keeps "a live inventory of every running and dormant agent across the enterprise, who deployed it, and its security status," and blocks agents not on an approved list (CrowdStrike) |
| WSO2 Agent Manager | Sep 15 (GA) | "Verifiable identity, role-based access, delegation, and token exchange for every agent, with instant revocation," plus one-click suspension; built on an OAuth 2 extension for MCP that WSO2 co-authored (WSO2 via GlobeNewswire) |
| ServiceNow AI Gateway | September release | "Verifies agent identity, issues scoped short-lived OAuth 2.1 tokens on every connection, and rotates server credentials centrally"; server credentials are never exposed to the agent (ServiceNow Community) |
| Dataiku Agent Management | Sep 24 (GA slated for October) | Builds one inventory of agents across AWS Bedrock, Databricks, Google Vertex, Copilot Studio and Azure Foundry, Agentforce, Snowflake Cortex and Dataiku, and flags the riskiest (Dataiku) |
Read across the right-hand column and the pieces add up to one sequence: find the agents, give each one a name, issue it narrow credentials, and keep an off switch. That is the identity model in this article, sold as four products.
The inventory step is the one most organizations skip. Dataiku's announcement cites IBM research finding that fewer than one in five organizations maintain a complete, current inventory of their AI systems. You can't issue identities to agents you don't know exist.
Each of these products automates a step you can do by hand for your first ten agents: a list, a name per agent, a credential per agent, a sponsor per agent, and a tested way to switch each one off.
How do you give identity to an agent that uses a browser?
Give it its own account in each tool it signs into, the same way you'd onboard a new hire. Browser-driven agents are the hardest identity case, and the most common one in real teams.
An agent that calls APIs can be handed a scoped token. An agent with its own computer opens a browser, goes to the CRM's login page and signs in like a person. The OpenID Foundation's whitepaper puts it plainly: "Browser and computer-use agents break the current authorization paradigm," because agents driving a user interface "bypass all traditional API-based authorization controls."
That doesn't make browser agents unsafe. It moves identity to the application layer, where it has lived for people all along. The tool's own account system becomes the agent's identity provider:
- One account per agent per tool. Create a seat for the agent itself, named for it, and never let it use yours. The tool's audit log then attributes every click to the agent.
- The tool's role system is the permission system. Give that seat a role that fits the job: read-only in the CRM, editor in one shared folder, no admin anywhere.
- Its own inbox closes the loop. Sign-up confirmations, password resets and shared links go to the agent's address, not to a human's mailbox.
- Removing the seat is the off switch. Offboarding the agent works exactly like offboarding a contractor.
- Check the terms. Some tools restrict automated or shared accounts; read them before you create the seat.
This is why we argue that an AI coworker should be treated like a hire rather than a plug-in (see coworker AI). A hire gets a desk, a laptop, their own logins and a manager. A coworker that borrows yours is not a coworker. It's an impersonation with good intentions.
How to set up AI agent identity: a 10-step checklist
Start with an inventory, end with a tested off switch, and put a human name on everything in between. This works for three agents or three hundred; at scale you automate it with the tools above.
- Inventory what's already running. Check model-provider keys, OAuth grants in your SaaS admin panels, browser extensions and scheduled jobs. Agents someone connected "just to try it" are the ones nobody will remember.
- Register every agent under a readable, unique name. One registry, one entry per agent, no anonymous agents allowed to get credentials.
- Assign a human sponsor. One person per agent, recorded in the registry, with a named backup.
- Issue the agent its own credential. No human passwords, no shared team keys, no reused service accounts.
- Make credentials short-lived. Prefer tokens that expire in minutes or hours over secrets that live for years; rotate whatever can't be short-lived.
- Use delegation, not impersonation, when it acts for a person. Token exchange with the person as subject and the agent as actor, scoped to the task.
- Narrow authority at every hop. Sub-agents get their own identities and a subset of the parent's scopes.
- Log subject, actor and run in every entry. Agent ID, the person it acted for, the run or session ID, and the tool call. This is what turns an incident into a query.
- Build and test the off switch. Suspending one agent should take one action and not affect any other agent or any human. Test it before you need it.
- Review and retire on a schedule. Quarterly, check each agent's sponsor, last activity and access. Retire anything with no sponsor or no recent use.
Steps 2, 3 and 9 take an afternoon and fix most real incidents: you'll know which agent did it, who to call, and how to stop it without stopping everything else.
Common AI agent identity mistakes
Most identity failures with agents come from treating them as either a user or a script, when they are neither. These are the patterns we see most often.
| Mistake | Why it happens | Fix |
|---|---|---|
| Agent uses a person's login | Fastest way to get a demo working | Its own seat in each tool, scoped to the role |
| One key shared by every agent | One billing account, one secret | One credential per agent; separate keys per agent where the provider allows |
| No sponsor | The person who set it up "owns" it informally | Sponsor field is mandatory in the registry |
| Logs record only the user | Agent calls go out under the user's token | Token exchange, or at minimum log agent ID alongside user |
| No off switch | Revoking means rotating a shared secret | Per-agent credentials make per-agent revocation possible |
| Orphaned agents | Sponsor left; agent kept running on schedule | Tie agent lifecycle to sponsor's offboarding checklist |
Identity is also one of the controls that make other defenses work. An agent hit by prompt injection can only do what its identity allows, and the damage only shows up in the logs if the identity is recorded there. Our broader AI agent security guide lists identity management as one of the seven controls that hold up in production.
Where is AI agent identity heading?
Toward standards, and toward treating agents as a third kind of principal next to people and services. The direction is clear even if the details aren't settled.
In February 2026, NIST's National Cybersecurity Center of Excellence published a concept paper on software and AI agent identity and authorization, asking industry how to handle the "identification, authorization, auditing and non-repudiation of AI agents." The OpenID Foundation's community group is working on the cross-domain and recursive-delegation problems that today's OAuth flows don't solve. Vendors are shipping ahead of both.
Three things are worth planning for now:
- Agent directories next to user directories. Agents will get first-class objects in identity providers, with their own sign-in policies, risk scores and lifecycle rules.
- Consent at scale. The whitepaper warns that users "will face thousands of authorization requests as agents proliferate," which means approval has to move from per-action prompts to policies set by sponsors.
- Identity in every log by default. Subject and actor in one record will become the expectation for any system that accepts agent traffic.
None of this requires waiting. A list, a name, a credential, a sponsor and an off switch per agent get you most of the way today.
Hire Your First AI Coworker
At cowork.ink you set up as many AI coworkers as you need, in whatever roles you need. Each one has its own computer — browser, files, inbox and code runtime — and shows up in Slack or Telegram under its own name, so you always know which coworker did what. Every run leaves a transcript of the steps it took and the pages it opened, which you can read and correct.
Treat it like a new hire: give it its own logins in the tools its role needs, hand it the docs a person would get on their first morning, and give it the first task in plain language. Setup takes about three minutes, and one flat price covers every coworker and its machine: $25/month billed yearly, or $29 monthly, with a 15-day money-back guarantee.