Should AI Agents Have Their Own Identity? The Hidden Security Risks

For most production AI agents, yes. An agent that acts on its own should have an identity you can name, scope, audit and revoke.

That doesn’t mean handing it broad access. The setups that hold up best tie each agent’s permissions to a single task, and to the intent of one person who answers for it.

Most organizations still can’t say who did what. In a Cloud Security Alliance survey commissioned by Aembit, published in March 2026, 68% of organizations said they could not clearly tell AI agent activity apart from human activity. When an agent works under someone else’s credentials, its actions blend into theirs.

What follows covers why borrowed accounts break down, what an agent identity record should hold, and when a dedicated identity is more trouble than it’s worth. After that comes where the standards actually stand in October 2026, and an order of work for teams starting from scratch.

Standards bodies are still working this out, and much of the practical guidance comes from identity vendors who sell the fix. Where a recommendation comes from a vendor or from this article’s own analysis, the text says so.

Why user accounts and service accounts fail for AI agents

An AI agent can run on an identity type you already have: a workload identity, a service principal or a user’s delegated access. Trouble is, almost none of them were set up to record which agent acted, on which task, and on whose say-so.

Traditional identity patterns assume a predictable actor. A human user logs in, works in a bounded session, and answers for what they do. A service account usually runs code whose behavior someone reviewed before it shipped. An AI agent chooses its next tool call at runtime, which is the core difference between rules-based automation and agents.

Auth0’s engineering team describes agents as non-deterministic by design. Agents also spawn sub-agents more often, so one user request can fan out across many separate contexts before it finishes.

Two failure patterns that keep repeating

• Inherited user permissions. A user connects an agent to their CRM. The agent now holds every scope that user holds, across every future action, whatever task it is actually doing.
• Shared service credentials. The agent gets its own key, but the key is static, broadly scoped and disconnected from any user. A key that never expires grants access that never expires.

Both patterns are common. In the same CSA survey, 43% of organizations said agents run on shared or generic service accounts, and 31% let agents operate under human user identities; many organizations use both. A CSA research note on the survey adds that only 36% assign dedicated AI-agent identities.

Either way, you end up with the same blind spot. Nobody can say which actions a person chose and which ones the agent picked on its own.

What a borrowed credential did at PocketOS

On April 24, 2026, a Cursor coding agent at PocketOS was working on a routine task in a staging environment. It hit a problem, found a long-lived API token in an unrelated config file, and used it.

One API call to the hosting provider Railway deleted the production database volume. The volume-level backups lived on the same volume, so they went too. The whole sequence took about nine seconds. Aembit’s write-up of the incident notes the data was later recovered.

The public accounts point to three failures: a broadly privileged credential within the agent’s reach, a weak boundary between staging and production, and no confirmation step on a destructive call. A dedicated agent identity would have made the action easier to attribute. On its own, it would not have stopped the deletion; narrower authorization and execution controls had to do that.

A similar pattern played out in the 2025 Replit deletion, where a code freeze written into a prompt did not stop an agent holding production access.

What an agent-specific identity and permission model looks like

An agent-specific model gives the AI agent its own credential, its own lifecycle and permissions limited to one task. The agent becomes a distinct principal, separate from the person it works for. Its actions can be audited, and its access can be cut off without touching the user’s account.

Auth0 makes the same case for treating agents as first-class identities, distinct from human users and from traditional machine identities, and adds policy bindings to the list of what each agent identity carries.

Then there’s the permission side, which matters just as much. In the OpenFGA authorization pattern the same article describes, agent permissions are scoped to capabilities and bound to tasks. They are not copied wholesale from a user’s role. The authorization model sets the boundary, not the prompt and not the agent’s own judgment.

How the three models compare

	Borrowed user session	Shared service account	Agent identity with delegation
Who the logs show	The user	A generic service name	The agent and the person it acted for
Scope	Everything the user can do	Usually broad and static	Limited to the task
Credential lifetime	As long as the session or refresh token	Often never expires	Short-lived, per task or session
Revoking the agent	Means revoking the user	Breaks every app using the key	Cuts off one agent only

What an AI agent identity record should contain

A name and a client ID won’t get you far in an incident review. NIST’s NCCoE published a summary of public comments on its agent identity project in September 2026. One working group recommended that a minimum agent identity record include:

• Model version and provenance: who built and deployed the agent
• Operating policy context: which authorization policy governed its deployment
• Lineage in multi-agent pipelines: which parent agent spawned it
• Human principal binding: which human account authorized its deployment

To be clear, that’s a recommendation from the public comments, not NIST guidance. It still makes a good checklist, since every field answers a question an auditor or incident responder will eventually ask.

How delegation keeps the human in the audit trail

Delegation lets an agent act for a user without becoming that user. OAuth 2.0 Token Exchange (RFC 8693), published in January 2020, defines both delegation and impersonation.

With an agent, the two look very different.

• Impersonation: the agent gets a token that represents the user. Downstream services may see only the user, with no separate record of the agent.
• Delegation: the token names the user as the subject and the agent as the current actor, through an ” actor ” act claim. The agent keeps its own identity.

Prefer delegation wherever your identity provider and target systems support it. The token can carry both identities, but attribution survives only if downstream services and logging systems keep the actor information. Check that before you rely on it for audits.

Agent-specific work at the IETF is still at the individual-draft stage. An early on-behalf-of proposal for AI agents has expired without being adopted. A newer individual draft from July 2026, the AI Agent Authorization Integration Framework, profiles existing OAuth extensions for agents, including SPIFFE-based workload identity and multi-hop delegation. Neither is a standard.

What changes when agents call other agents

RFC 8693 can record a delegation chain by nesting act claims, one per hop. The RFC also says access decisions should consider only the current actor; earlier actors in the chain are informational.

The act claim records the chain; it does not narrow anyone’s access by itself. The authorization server has to issue a token with less scope at each hop, and the receiving service has to enforce it. A sub-agent should get a reduced slice of the original authority, never the orchestrator’s full scope.

One identity per agent, per instance or per task?

Few articles touch this, and no standard answers it yet. The default below is editorial judgment, not a published rule.

• Give each deployed agent (one purpose, one environment) a persistent identity with an owner.
• Issue short-lived credentials per task or session under that identity.
• Split into per-instance identities when instances of the same agent serve different users or tenants, because their behavior and data exposure can differ.

Which identity model fits which kind of agent?

The right model depends on whether the agent acts for a person or for the organization, and on how much damage a wrong action could do. Treat the matrix below as a recommended starting point, not a universal standard.

Situation	Starting point	Watch out for
Fixed internal job, no user-specific data	Dedicated workload identity	Limit resource access and separate environments
Acts for one signed-in user	Delegated, scoped access with the agent named as actor	User consent should not hand over every permission the user holds
Serves many customers or tenants	Workload identity plus tenant-aware authorization	A separate identity alone does not stop cross-tenant data exposure
Moves money, deletes data or changes permissions	Narrow identity, per-action authorization and human approval	An approval step only works if the runtime cannot bypass it
Orchestrator calling sub-agents	Explicit delegation chain with a narrower token at each hop	The parent’s broad scope must not pass through automatically
Short-lived agent created for one task	Ephemeral credential under managed issuance	Keep the identity record and logs after the credential expires

A worked example: a support agent that issues refunds

Picture a support agent with refund rights. The flow below isn’t any vendor’s product; it simply shows where identity, authorization, and enforcement each earn their place.

1. A support employee asks the agent to refund a specific order.
2. The runtime identifies both the employee and the agent, then checks the employee’s authority and the agent’s permitted capabilities.
3. An authorization policy checks the customer, the order, the amount and any fraud or approval rules.
4. A credential broker issues access for that one refund, and nothing else.
5. The billing service validates the request again and enforces its own rules.
6. The audit record captures the agent, the authorizing employee, the order, the action, the policy result, and the outcome.

If the amount exceeds the agent’s limit, the policy denies the autonomous request and routes it to a person for approval. The agent never holds a standing refund permission it could reuse on another order.

A second example: a coding agent in a CI pipeline

Same idea, different setting. A coding agent runs inside a CI job, trying to fix a failing test on a pull request.

1. The pipeline issues the agent a short-lived identity tied to that job, that repository and that branch.
2. The agent can read the repository and push commits to its own branch, but it cannot merge or touch protected branches.
3. Deployment credentials are never present in the job environment, so the agent cannot find and reuse them.
4. Any deploy runs through a separate pipeline step that requires human approval.
5. Commits and API calls are logged against the agent’s job identity and the developer who triggered it.

The agent can still make mistakes. What it cannot do is reach past its own job.

When is a separate agent identity overkill?

A dedicated identity is usually overkill when the agent only reads data, serves one user, works under close supervision, and has no way to send data out. In that narrow case, a scoped delegated token is often enough. Identity sprawl and management cost are real trade-offs.

The test below is editorial judgment rather than a benchmark. It weighs how much an agent could break against what one more identity costs to run.

Five questions that decide whether an agent needs its own identity

A separate identity pays off when you answer yes to most of these:

1. Does the agent act without a person approving each step?
2. Can it write, delete, move money or move data?
3. Does it spawn sub-agents or call other agents?
4. Does it work across several users or tenants?
5. Will you need to answer “who did this?” for an auditor?

Why read-only agents are not automatically low risk

Read-only access sounds safe, but it only stays safe when the agent has no outbound channel. An agent that can read a mailbox and also fetch web pages or send messages can leak what it reads.

Prompt injection makes that leak practical. A hidden instruction in a document or web page can tell the agent to forward data somewhere else. The agent never needs write access to cause harm.

That is why the exception above needs all four conditions, not read-only access alone. Even when all four hold, give the agent a scoped token rather than the user’s full session.

What a separate identity costs to run

Every identity needs issuing, rotating, monitoring, and retiring. A team running dozens of agents without lifecycle tooling can end up with orphaned credentials, the very mess agent identity was supposed to clean up.

Design choices can shrink that cost. When an agent drafts and a person approves, the agent needs fewer standing permissions. That is one reason many teams start with augmentation instead of full automation before handing an agent its own write access.

Do permissions alone keep AI agents safe?

No. An agent can stay inside every permission it holds and still do damage, because permissions only define what it can touch. Whether a given action makes sense for the task at hand is a separate question, and scopes don’t answer it.

The PocketOS token technically allowed the volume deletion. Nothing checked whether deleting production made sense for a staging task. Identity and scopes are necessary, but they are not sufficient.

The OWASP Top 10 for Agentic Applications, published in December 2025, lists identity and privilege abuse as one of its ten core risks. That risk covers agents misusing their own credentials, borrowed credentials or trust relationships with other agents.

Runtime controls that close the gap

• Task-bound authorization. Auth0 frames the question as what the user intended the agent to do, not only what the agent is permitted to do. The task itself becomes a unit in the authorization model. In practice, the runtime re-checks each sensitive action when it executes, against the original task and policy, instead of trusting the scopes granted when the task began.
• Human approval for high-risk actions. Deletes, payments, permission changes and anything irreversible pause for an explicit yes from a person.
• Environment separation. A credential issued for staging should fail in production, so a mistake in one environment cannot reach the other.
• Fast revocation. Check whether your system caches permissions at the start of a task. If it does, an agent can keep working on stale access after you revoke it.

One caution on task-bound authorization: it’s still a vendor design pattern, not proven practice. It fits the threat well, but independent evaluations are thin so far.

What agent identity cannot prevent

Identity tells you which agent acted and on whose authority. It does not stop these failures by itself:

• Prompt injection. Hidden instructions can steer a correctly identified agent into misusing access it legitimately holds.
• A compromised runtime. If an attacker controls the host or the agent’s process, the agent’s credentials are theirs too.
• Weak downstream checks. A target system that trusts any valid token will execute whatever that token allows.

Each of these needs its own control: input handling, runtime hardening, and enforcement at the system that acts.

Who is accountable when an AI agent acts?

A named person or organization stays accountable. A separate agent identity does not move responsibility onto the agent. It makes accountability traceable by linking each action to the agent that took it and the person or team that authorized it.

Without that link, the audit log shows a shared account or a user who never clicked anything. Incident review then turns into guesswork.

NIST’s NCCoE raised this directly in its February 2026 concept paper on agent identity and authorization. The paper asks how to bind an agent’s identity to a human identity, and it lists logging and auditing of agent activity among the areas a project would examine.

The accountability question also shapes which work an agent should do at all. Some tasks are limited by what models can reliably do today; others are limited by who gets sued when the work is wrong. The second group, which AI Work Audit calls liability-gated automation verdicts, keeps a person accountable no matter how good the agent’s identity setup is.

What are NIST and other standards bodies doing about AI agent identity?

No finished standard for AI agent identity exists yet. NIST’s NCCoE is running a project to apply existing identity standards to agents, OWASP has named the risks, and the Model Context Protocol has hardened its authorization rules. The building blocks exist; the agreed blueprint does not.

Status as of October 2026

Effort	What it is	Where it stands
NIST NCCoE agent identity project	A concept paper on applying identity and authorization standards to software and AI agents	Published February 5, 2026; comments closed April 2, 2026; comment summary released September 29, 2026
NIST CAISI AI Agent Standards Initiative	A broader NIST program on agent security, identity and authorization	Launched February 2026; no finished standard yet
OWASP Top 10 for Agentic Applications	A peer-reviewed risk framework for agentic systems	Published December 2025
MCP authorization (2026-07-28 spec)	How MCP clients get authorized access to MCP servers over HTTP	Current revision; Client ID Metadata Documents preferred over Dynamic Client Registration
OAuth 2.0 Token Exchange (RFC 8693)	The standard for delegated and impersonated tokens	Published standard since January 2020
IETF agent authorization drafts	Individual proposals for agent delegation and authorization	Not adopted; the on-behalf-of draft has expired, a July 2026 integration framework draft is active

Where the NCCoE project is heading

The NCCoE concept paper proposes adapting existing identity and access standards rather than inventing new ones. If the project proceeds, its output will be a practice guide with example implementations, not a rule anyone must follow.

The September 2026 summary of comments narrowed the focus. Because so much feedback concerned agents in software development, the project team is working with NCCoE’s DevSecOps project to demonstrate agent identity and authorization across the software development lifecycle. Coding agents, the category behind both the PocketOS and Replit incidents, are where the first reference designs will likely land.

What changed in MCP authorization

The MCP 2026-07-28 authorization specification builds on OAuth 2.1. Authorization servers and MCP clients should support OAuth Client ID Metadata Documents, which replace Dynamic Client Registration as the preferred way for a client to get an ID. Dynamic Client Registration is deprecated but still allowed for backward compatibility, so existing clients can keep working while they migrate.

Alongside the core spec, an optional enterprise-managed authorization extension lets administrators govern agent access to MCP servers through their existing identity provider, instead of relying on per-server consent clicks.

Which identity products support AI agents today?

Tooling has moved quickly in 2026. Microsoft Entra Agent ID and Okta for AI Agents both reached general availability in April 2026. Okta’s Agent SSO, for agents calling several applications through its Cross App Access approach, followed later in the year, and other identity providers have shipped agent-focused features.

Registering an agent is no longer the hard part. Governing one that spans several platforms and licensing tiers is. Features and pricing shift month to month, so check the current product pages before you commit.

How to give AI agents their own identity: where to start

Start by finding every agent and every credential it can reach. Then replace shared keys and borrowed sessions with per-agent, short-lived, task-scoped credentials, log every action, and gate anything destructive behind human approval. Expand only after those basics work.

A workable order, with the highest-risk fixes first:

1. Inventory your agents. List each agent, the systems it touches, its owner and the credential it uses today.
2. Remove long-lived keys from anywhere an agent can read them. Config files, environment variables and shared notes in an agent’s workspace all count.
3. Issue each agent its own identity. Pair it with short-lived credentials and minimum scope. Where tooling allows, have the agent call a credential broker instead of holding the secret itself. A broker hands out a short-lived token for one operation, so no reusable secret sits in a config file for the agent to find later.
4. Separate environments. Make staging credentials useless in production.
5. Use delegation, not impersonation, when an agent acts for a user. The token should name both the user and the agent.
6. Bind permissions to tasks where your tooling allows it. Narrow the scope again at every agent-to-agent hop.
7. Log every action against both the agent and the authorizing person.
8. Add approval gates for high-impact actions. Deletes, payments, permission changes and external messages come first.

Older internal systems often still assume a human user or a fixed service account, so they may need a gateway or broker in front of them.

Agent identity yes, standing access no

Most production AI agents should have their own identity, because without one nobody can scope, audit or revoke what the agent does. The identity is only half the answer. The other half is narrow, short-lived, task-bound access and a human approval step for anything that cannot be undone.

The main exception is the read-only, single-user, closely supervised agent with no outbound channel. A scoped delegated token is usually enough there.

Standards are still forming, so build on what already exists: OAuth delegation, per-agent credentials and complete logs. Those choices will map cleanly onto whatever NIST’s practice guide recommends.

Frequently asked questions about AI agent identity

Q. Should AI agents have their own identity?

Yes. Most production AI agents need a dedicated identity to control permissions, track actions, and revoke access. Supervised, read-only agents may only need scoped delegated access.

Q. Is an AI agent a user or a service account?

An AI agent is a non-human software actor that can use a workload identity, service account, or delegated user credentials. Its actions should remain separately traceable.

Q. Can AI agents act independently?

Yes. Autonomous AI agents can plan, make decisions, and execute tasks without constant supervision. However, sensitive actions should require human approval.

Q. Is there an official NIST standard for AI agent identity?

Not yet. As of October 2026, NIST is developing guidance. Existing standards such as OAuth 2.0 Token Exchange (RFC 8693) support agent identity and delegation.

Q. How is AI agent authorization different from traditional access control?

Traditional access control assigns permissions by role. AI agent authorization can additionally restrict access by task, tool, user intent, and runtime conditions.

Q. What is delegation vs. impersonation in AI agents?

Delegation preserves both the user’s and agent’s identities. Impersonation makes the agent act under the user’s identity, potentially reducing accountability.

Q. Can AI agent permissions prevent prompt injection?

No. Permissions limit what an agent can access but cannot stop malicious instructions. Task-level controls and human approval help reduce the damage.

Q. What credentials should AI agents use?

AI agents should use short-lived, least-privilege credentials with task-specific access. Avoid shared API keys, permanent tokens, and unrestricted user credentials.

Related: Knowledge Work Automation: What Works, What Fails & Why

Disclaimer: This article is for informational and educational purposes only and does not constitute professional cybersecurity or compliance advice. AI agent identity standards, security practices, and authorization frameworks are evolving. Organizations should verify current NIST and OWASP guidance and consult qualified professionals before implementing these recommendations.