AI Agent Identity vs Human Identity: The Access Control Model That Actually Works

An AI agent should have its own identity. It should not automatically have its own authority.

That distinction decides whether your agent programme is governed or quietly broken. Two shortcuts remain common in production: running an agent on an employee’s credentials, or putting several agents behind one shared service account. Both destroy your ability to answer the question an auditor will eventually ask. Who actually did this?

Giving each AI agent a separate identity fixes attribution. It also creates a risk that published guidance rarely mentions. An agent with standing permissions of its own can reach data the person who tasked it could never reach alone. You solve the audit problem and open an authorization bypass in the same move.

This guide covers the delegation model that avoids that trap, what each shortcut breaks, how granular agent identities should be, and what the approach costs to run.

Should AI agent identity be separate from human identity?

Yes. An agent needs an identity distinct from any human’s, so you can attribute actions, scope permissions, and revoke the agent on its own. That separation must not extend to authority. Separate the identity, then constrain the permissions to an overlap.

The rule to design against:

Effective authority = agent permissions ∩ human permissions ∩ task scope

WorkOS states the two-party version clearly: an agent’s effective authority should never exceed the intersection of what the agent may do and what the requesting user may do. If Alice cannot delete the production database, the agent cannot delete it for Alice, even where the agent’s own credentials allow it.

The third term matters in practice. Agent permissions drift upward as teams grant broad roles to unblock pilots and never narrow them again. Task scope does not drift. Anchoring each authorization decision to what the current task requires is the only term that resists permission creep by construction.

Skip that constraint and the failure mode is specific. When actions execute under the agent’s identity instead of the requester’s, user-level restrictions stop applying. A user with limited access reaches restricted data by asking the agent for it.

Identity, authorization, and governance answer different questions

• Identity answers who is acting
• Authorization answers what this actor may do right now
• Governance answers whether that access should continue to exist

An agent registry that assigns identities but never reviews or revokes them has solved the first layer and ignored the third. Most agent programmes fail at governance rather than authentication.

Microsoft’s engineering guidance names the ambiguity behind many of these incidents. Teams consistently fail to answer whether an agent acts under its own identity, a delegated user scope, or some mix of the two. That answer determines accountability. Settle it before the agent ships.

Three questions every agent transaction has to answer

Each agent action involves three separate facts. Collapse any two and your authorization engine loses information it needs.

Layer	Question it answers	Typical mechanism
Agent workload identity	Which running thing is this?	SPIFFE SVID, federated identity credential, mTLS certificate
Delegated authority	Whose permission is being spent?	OAuth token exchange, sub and act claims
Resource authorization policy	Is this combination allowed here?	Policy engine at the resource server

The first two are principals. The third is a control layer that evaluates them.

An API key represents one of these facts and silently discards the other two. The resulting audit record says the key did it. It cannot tell you which workload ran, who authorised the work, or where authority changed hands.

What delegation looks like inside a token

RFC 8693 token exchange already carries this shape. In a delegated model, sub identifies the subject whose authority is being exercised, and act identifies the actor acting.

{
  "iss": "https://idp.example.com",
  "sub": "user:alice@example.com",
  "aud": "https://api.example.com/invoices",
  "exp": 1789520400,
  "scope": "invoices:read",
  "act": {
    "sub": "spiffe://example.com/agent/invoice-reporter/inst-7f2a"
  }
}

The claims sub, act, aud, scope and exp are standard. Anything else you add, such as a sponsor reference or a task identifier, is deployment-specific. Never assume a partner API will honour custom claims.

A resource server holding this token can evaluate both principals independently. Alice’s entitlements bound the request. The agent’s entitlements bound it again. The scope bounds it a third time.

The path from human intent to audit record

Human Intent
→ Delegation
→ Token Exchange
→ sub = human / act = agent
→ Agent Identity
→ Human Permissions ∩ Agent Permissions ∩ Task Scope
→ Authorization Decision
→ Resource Server
→ Audit Record

Effective Authority = Human Permissions ∩ Agent Permissions ∩ Task Scope

Audit Record = Agent + Human + Scope + Action + Correlation ID

What goes wrong when an agent uses an employee’s credentials

Five things break, in a predictable order.

Over-privilege happens automatically. An employee’s account carries their full permission set. An agent borrowing that account inherits all of it for a task that may need one API call. The credential was never built to carry scope.

The audit log stops answering questions. Every action lands under the employee’s name. A regulator asking whether a human reviewed a decision gets no answer. Your incident responder gets none either.

Non-repudiation disappears. If human and agent actions look identical at the identity layer, you cannot prove which one acted. That matters for fraud investigation and any regulated process with a human-review requirement.

Revocation turns into a bad choice. Stopping the agent means disabling the employee’s account or rotating their credentials. The options are to cut the human’s access or leave the agent’s credentials active.

Lifecycle coupling surfaces months later. Human identities generate joiner-mover-leaver events. Agents generate none. Reco’s governance analysis makes the point well: access reviews trigger on onboarding and offboarding, so agents accumulate permissions without any review ever firing.

Tie an agent to an employee’s account, and you inherit both failure directions. The agent dies when they leave, or the account survives offboarding because production depends on it. The second outcome can leave orphaned privileged access in place indefinitely.

Microsoft is direct about this in its own platform guidance. Regular user accounts are not recommended for AI agents, because Conditional Access policies written for humans misfire, Identity Protection detections degrade, and governance processes can strip agent access by accident.

The same reasoning applies outside Entra. Any control designed around human sign-in behaviour will behave unpredictably when the thing signing in is not an employee.

What goes wrong when agents share a service account

A shared service account gives an agent broad standing permissions, no link to any human decision, no per-agent revocation, and traffic that looks legitimate to every monitoring tool you run. The Salesloft Drift compromise shows how that plays out at scale.

Working from Google Threat Intelligence Group’s advisory rather than secondary coverage: beginning as early as 8 August 2025 and continuing through at least 18 August, an actor tracked as UNC6395 targeted Salesforce customer instances using compromised OAuth tokens tied to the Salesloft Drift application. The actor exported large volumes of data from numerous corporate instances, and GTIG assessed the primary goal as credential harvesting.

On 28 August, GTIG confirmed the actor had also compromised tokens for the Drift Email integration and used them on 9 August to reach email in a small number of Google Workspace accounts.

Three details matter more than the headline.

Nothing was exploited. No platform vulnerability was involved. A legitimate integration authenticated with legitimate tokens and made API calls the platform was designed to serve. Analysis published through the Cloud Security Alliance notes that monitoring failed because the traffic came from a trusted, pre-approved integration. Organisations could see Drift had access. They could not see what it was doing with it.

MFA was irrelevant. Astrix Security’s research records that the campaign bypassed multi-factor authentication entirely. A refresh token is post-authentication by definition. MFA protects a login moment, and integration identities have no login moments.

Revocation was coarse and centralised. Salesforce and Salesloft revoked all Drift tokens on 20 August, for every customer at once, roughly twelve days after activity began. No individual customer could cut off just the compromised path.

The common lesson drawn from this incident is to audit third-party integrations. The sharper lesson concerns granularity of revocation. Every affected organisation had approved that connection deliberately. What they lacked was an identity boundary fine enough to sever one thing without severing everything.

Agent identity vs service account vs user account

Use a purpose-built agent identity where the platform provides one. Do not fall back to a generic service principal simply because an agent happens to be a non-human workload. Give an agent a user account only where a downstream system refuses to work without a user object.

Microsoft’s Entra Agent ID model is the most detailed published articulation of these distinctions, so it works as a reference model even if you run somewhere else.

	Human user account	Service principal	Agent identity	Agent user account
Represents	A person	An application or static workload	An AI agent	An agent needing a user object
Credentials	Password, MFA, passkey	May hold a secret or certificate, depending on configuration	None of its own; tokens issued by a parent blueprint	None of its own; authenticates via its agent identity
Human accountability	The person	Owner or team, often informal	Enforced sponsor	Inherited from the agent identity
Audit granularity	Per user	Per application	Agent-specific entries	Appears as a user to Microsoft 365 APIs
Revocation scope	User-wide	Account-wide, often shared	Per agent	Per agent user
Best fit	People	Deterministic workloads	Most AI agents	Mailbox, Teams, calendar presence

Microsoft explains why a new object type exists: service principals were designed for static, deterministic workloads and lack the governance agents need. Agent identities are built on the same infrastructure but carry an “agent” subtype, adding a parent blueprint that acquires tokens for each agent identity, a required sponsor, and agent-specific audit entries.

Agent identities hold no credentials of their own. They authenticate using tokens their blueprint issues, which removes an entire class of stored-secret risk.

The agent user account is the nuance most writing on this topic misses. It is optional, paired one-to-one with an agent identity, and exists for the digital-worker pattern where an agent needs a mailbox or Teams presence. It cannot hold passwords, passkeys, or MFA factors.

Six properties every agent identity needs

These are platform-neutral, and they map equally onto SPIFFE-based workload identity, a cloud IAM role model, or a home-grown registry.

1. A unique identity
2. A named, accountable sponsor
3. A defined authority, bounded by the intersection rule
4. A managed lifecycle
5. An independent revocation path
6. Its own audit trail

If your agent registry is missing one of these, start there. The sponsor requirement is the one teams forget most often and the cheapest to add.

How AI agents differ from other non-human identities

AI agents are non-human identities and belong in your NHI programme. Four properties still break the analogy with service accounts and API keys.

Property	Traditional non-human identity	AI agent
Behaviour	Deterministic	Non-deterministic; two runs diverge
Permission scope	Fixed at provisioning	Assembled at runtime through tool calls and delegation
Attack surface	Code and credentials	Code, credentials, and natural-language input
Lifecycle triggers	Deploy and decommission	Often none; agents spawn and persist unnoticed

This is the practical consequence of the difference between an AI tool and an AI agent. A tool executes a defined function. An agent decides which functions to call, which is exactly what makes its permission envelope unpredictable.

Non-determinism has a concrete effect on identity design. GitGuardian points out that Kubernetes workload identity assigns identity at the service account level, so every replica shares one identity. That works for deterministic APIs. Two instances of the same agent behave differently on different inputs, which leaves an attribution gap for anyone extending existing workload identity infrastructure to agents unchanged.

The natural-language attack surface is the genuinely new problem. Nobody argues a service account into misbehaving. Agents can be argued into it, and the instructions an agent loads at runtime are part of that surface.

OWASP’s Top 10 for Agentic Applications tracks this as ASI03, Identity and Privilege Abuse. Agents inherit user or system identities, including high-privilege credentials, and those privileges get reused, escalated, or passed between agents through cached keys in agent memory, unscoped cross-agent delegation, or confused deputy scenarios.

Why confused deputy attacks evade normal detection

A confused deputy attack is not a compromise in the traditional sense. A privileged agent is tricked by a less privileged party, usually through prompt injection hidden in a document or web page, into using its legitimate privileges for the attacker.

No credential is stolen. No code is exploited. The agent does exactly what it was built to do, with inputs it should not have trusted. Endpoint detection sees nothing unusual.

The defence has two parts: bound agent authority to the requesting user’s permissions, and require human approval for irreversible actions.

How granular should an agent identity be?

Per deployment works as the default. Per instance gives the strongest attribution and cleanest revocation at real operational cost. One identity shared across every copy of an agent type recreates the shared service account problem under a new name, so rule it out.

The revocation test

Answer five questions before an agent ships. Any “no” means the granularity is wrong.

1. Can I revoke one agent without touching any other agent?
2. Can I revoke one deployment without taking down the agent type?
3. Can I revoke one task’s authority without revoking the agent?
4. Can I revoke the delegated authority without disabling the human?
5. Can I rotate a compromised credential without breaking unrelated workflows?

If any answer requires rotating a shared secret, the identity is too coarse.

Per-instance identity earns its cost where agents spawn sub-agents at runtime. Without a verifiable identity for each instance, you cannot determine which privileges were inherited or delegated. Orchestration frameworks such as CrewAI make that pattern the default rather than the exception.

Multi-tenancy is the second argument. When one agent instance serves several users under a shared identity, no credential-level boundary stops one user’s context from leaking into another’s.

The cost is real, and vendor content tends to skip it. Rigorous per-instance identity adds provisioning and revocation overhead, trading audit precision against lifecycle complexity. You create and destroy identities at task frequency, and your identity provider, logging pipeline, and on-call rotation all feel it.

One interoperability limit deserves a flag. No relying party specification currently defines how to handle an instance-named credential. Outside your own trust boundary, instance-level attribution can degrade from cryptographically verifiable to merely operational. Test that in a pilot.

A workable split: per instance for agents that touch regulated data, move money, or spawn sub-agents. Per deployment for everything else. Revisit when blast radius changes, not on a calendar.

Why delegation breaks across multiple agent hops

Once an orchestrator hands work to a sub-agent that calls a tool that calls another service, each hop mints a new token. No adopted standard fully enforces the resulting chain.

The constraint comes from RFC 8693 itself. The specification states that consumers of a token should consider only the top-level claims and the current actor in the act claim. Prior actors in nested act claims are informational and are not intended for access control decisions.

Read that carefully. OAuth token exchange lets you represent a delegation chain. It does not enforce one.

Multi-agent systems also fail in ways single agents do not, including shared false beliefs propagating across a population of agents.

Three things you can do now:

Do not rely on nested actor claims for authorization. RFC 8693 tells you not to. Enforce constraints at each hop rather than inferring them from claim history.

Re-evaluate authorization at every privileged hop. A single check at the start of a workflow is worthless three delegations later. OWASP’s mitigation for identity and privilege abuse calls for re-checking through a central policy engine at each privileged step.

Bind tokens so a stolen one cannot travel. Short lifetimes, audience restriction, and proof-of-possession binding limit what a leaked intermediate token is worth.

Specification work on verifiable delegation chains is active but unsettled. The current proposals, and what they would change, are covered in the companion piece on AI agent identity standards.

What to log, and how to switch an agent off

Log the agent identity, the role and effective scope used, the resource and action, the human on whose behalf the agent acted, timestamps, and correlation IDs that stitch the orchestrator to the tool call to the downstream system. Make the log immutable. Then rehearse the kill path before you need it.

Most organisations have neither. Palo Alto Networks’ 2026 Identity Security Landscape found that only 37% of organisations can revoke an AI agent’s credentials and only 30% keep immutable audit logging of agent activity. Those figures are self-reported and vendor-supplied, though a revocation gap of that size matches what the Drift incident demonstrated in practice.

On audit fields. Microsoft’s field list is a workable minimum, and nothing in it is platform-specific. Without the on-behalf-of field and correlation IDs, you can show that an action happened and nothing about who authorised it.

Immutability matters for a specific reason: the agent identity may be the thing under investigation.

On revocation. Practise disabling the agent identity, rotating credentials, and running rollback or compensating actions for realistic failures such as bulk writes gone wrong or unintended exports. An untested revocation path is not a control.

On continuous evaluation. Token expiry is a blunt instrument. Where your platform supports shared-signals-style continuous access evaluation, push revocation signals to relying parties instead of waiting for tokens to age out.

Authentication tells you which agent is calling. It says nothing about what that agent should be allowed to do. A financial analyst may legitimately hold broad access, while an agent that analyst deploys to run a monthly invoice report should reach only the APIs that report needs.

What AI agent identity management costs

Separating agent identity adds operational load and depends on standards that are still moving. It remains the right call, because the alternatives fail worse and less visibly. Name the costs before someone else does.

• Identity sprawl. Your identity estate now grows with your agent estate, which burdens discovery, review, and decommissioning. Automate the lifecycle from day one.
• Bootstrapping. Something has to issue the agent its first credential. The secret-zero problem does not vanish because everything downstream is short-lived.
• Ephemeral credential failure modes. Token renewal, clock skew, and revocation propagation become live concerns in workflows that previously used a static key.
• Moving standards. Nothing agent-specific is an RFC yet, so anything built against draft claim names may need rework.
• Audit volume. Per-instance identity plus per-action logging produces a large event stream, which carries storage and signal-to-noise costs.

Platform features are also newer than they look. Microsoft’s Agent ID command set reached general availability in the Entra PowerShell module in May 2026, and agents created before a platform’s agent identity model existed usually sit outside its newer protections until migrated. Those tend to be the oldest and most privileged agents you have.

Where to start if you already have agents running

Start with discovery. Find the agents already operating and identify which credential each one uses.

That exercise usually ends the internal debate on its own, because it surfaces the agent running on a departed employee’s account.

Then migrate by blast radius. Agents that move money, touch regulated data, or reach production infrastructure get their own identity and a named sponsor first.

Standards alignment comes third, and it is inexpensive if you modelled delegation with distinct subject and actor claims from the start.

The honest limitation: none of this makes an agent safe to trust with irreversible actions. It makes agent behaviour attributable, boundable and reversible. Those three properties are what let you extend autonomy deliberately instead of discovering its limits during an incident.

Frequently asked questions

Q. Should AI agents have an identity separate from human identity?

Yes. AI agents that take autonomous or delegated actions should have a distinct identity for attribution, scoped access, independent revocation, and auditability. The agent can still act on behalf of a human, but its identity should remain separate from the human account.

Q. Does a separate AI agent identity mean it should have its own permissions?

Not necessarily. An AI agent’s effective access should be limited by three things: the agent’s permissions, the requesting user’s permissions, and the scope of the current task. The agent should never gain more authority than the human who delegated the task.

Q. Can an AI agent use an employee’s account?

It should not. Using an employee account gives the agent the employee’s full permissions and makes human and agent activity harder to distinguish in audit logs. A separate agent identity also allows administrators to revoke the agent without disabling the employee.

Q. What is the difference between an AI agent identity and a service account?

A service account usually represents a fixed application or workload with standing permissions. An AI agent identity is designed for agent-specific attribution, delegated authority, scoped access, lifecycle management, and independent revocation. This makes it better suited to autonomous or semi-autonomous AI systems.

Q. Does OAuth token exchange enforce AI agent delegation chains?

No. OAuth 2.0 Token Exchange under RFC 8693 can represent delegation using claims such as sub and act, but it does not automatically enforce the full delegation chain. Authorization should be checked again at each privileged step in a multi-agent workflow.

Q. How should AI agent activity be audited?

Audit logs should record the agent identity, requesting human, effective permissions, resource, action, timestamp, and correlation ID. Logs should also be immutable where possible so teams can trace who authorized an action, which agent performed it, and what systems were affected.

Related: OpenHands vs Devin vs Manus: Best AI Agent in 2026