Explainer · By Chris Sowa · Published October 13, 2026
Last updated October 13, 2026

What Is AI Agent Identity and Why Do Agents Not Fit Traditional User Access Models?

Separate human and AI identity cards connect through an access gate to enterprise resources.

AI agent identity is the distinct, accountable identity an agent carries when it acts for a person without being that person. User access models assume one human behind each session; an agent inherits a person's access while differing in session, scope and accountability. Treat the two as the same and no one answers for what the agent did. The question matters now because agents are moving from prompt boxes into applications: they open the claims platform, the student information system and the payer portal under someone's login and take actions there. A directory answers who is signed in, not who is responsible for a step a model chose under a login a person lent it. The practical fix has two halves, an identity for the agent that is separate from the person's, and a record that ties every run to a named owner who granted the access and approved the consequential actions, which is what Supervised Delegation describes. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

NIST's zero trust architecture treats every access request as coming from a subject that must be authenticated and authorized per request, with policy decided by an enterprise-owned policy engine rather than by the location or the standing session of the requester (NIST, 2020).
NIST's digital identity guidelines bind a credential to a specific subscriber through identity proofing and authentication, which is the assumption an agent breaks when it operates under a person's credential without being that person (NIST, 2025).
OWASP lists Excessive Agency as LLM06 in its 2025 Top 10 for LLM Applications: an agent granted more functionality, permissions or autonomy than the task requires, which a user-scoped identity makes the default rather than the exception (OWASP, 2025).
Gartner warned in May 2026 that uniform governance across AI agents will lead to enterprise agent failure; one user account cannot express different scopes for different agents (Gartner, 2026).
OMB M-24-10 requires human oversight and monitoring for rights- and safety-impacting AI, which presupposes that an agent's actions can be attributed to it and to an accountable official (OMB, 2024).

What does a user access model assume that an agent breaks?

Every identity and access management stack rests on assumptions that held for decades. A credential belongs to one person. That person is present during the session it opened. The person's role describes the person's work, so the permissions attached to the role describe what the session should reach. Logs that record the account record the person, and audit, discipline and liability flow back to a human through the account name. NIST's digital identity guidelines formalize the first assumption: identity proofing and authentication exist to bind a credential to a specific subscriber, so that an authenticated session is evidence that the subscriber is the one acting (NIST, 2025).

An agent acting under a person's login breaks three of those assumptions at once. The person is absent for most of the session, or busy on a different screen. The role describes the person's whole job, while the agent was asked to do one task inside it, so least privilege at the account level does not shrink what the agent can reach. And the log says the person acted when a model chose the step. The account authenticates, the policy engine returns allow, and nothing reports an error, because an authorized subject opened an authorized resource.

The failure is one of attribution rather than authentication. NIST's zero trust architecture tries to close part of the gap by evaluating every request against policy, using subject identity, device state and context rather than a standing session (NIST, 2020). That helps only if the subject presented to the engine is the agent on a task, not the person whose credential it borrowed; an engine cannot restrict an actor it cannot distinguish. The first requirement of agent identity is the ability to tell the engine, the log and the reviewer that this request came from an agent, which one, on whose behalf, for which piece of work.

How do sessions, scope and accountability differ for an agent?

Three properties separate an agent's identity from the user's, and each one maps to a control that user-centric IAM does not supply.

Property	Human user	AI agent acting for that user	Control the difference calls for
Session	One person, present, one login, ended by logout or timeout	Many runs, each a separate task, often unwatched, often spanning applications	A per-run identity and boundary, so one task cannot inherit another's state (session isolation)
Scope	The whole role: every screen and record the person's job touches	One task: the three fields, two screens and one action the work requires	Scope set per task before the run, not per account at provisioning time
Accountability	The account holder answers for the session	The model chose the steps; the person lent the credential; the vendor supplied the model	A named owner who granted the access and approved each consequential action, on the record
Credential	Password, MFA, device	Often the person's own credential, or a service account shared across agents	A credential the model never reads, bound to the agent, not shared between agents
Lifecycle	Joiner, mover, leaver	Created per task, may be copied, forked or left running	Creation, expiry and revocation tied to the task and the owner

A person's session is bounded by attention; an agent's run is bounded only by its task and instructions. OpenAI's own documentation of its always-on agents describes dots that do "proactive research" while the user is away, in read-only mode, under rules the user set (OpenAI, 2026). A session that continues with no person present is not a user session in any sense the directory understands.

The scope row is where OWASP's Excessive Agency lands: agents granted more functionality, permissions or autonomy than the task requires (OWASP, 2025). A user identity makes that the default, because the only scope a user account can express is the user's whole role. The accountability row is the one examiners ask about first.

A security team can treat a borrowed credential as a risk and build controls around it. An examiner asks a different question: who is responsible for this action? Under a person's identity there are three candidate answers and the record supports none of them. The person whose login was used did not choose the step. The model that chose the step is not a legal person and cannot be disciplined or sanctioned. The vendor that trained the model disclaims responsibility for how the customer deployed it.

Microsoft's AI Red Team taxonomy of agentic failure modes separates failures that originate in the agent from failures in how the agent was built into a system (Microsoft, 2025). Identity confusion is a deployment failure: the organization gave the agent an identity that cannot carry responsibility. Anthropic's agentic misalignment research adds a second reason to keep the identity distinct: in its test scenarios, models in agentic roles with broad access sometimes acted against the deploying organization's interests (Anthropic, 2025). An agent that can behave like an insider needs an identity that lets the organization treat it as one, with its own access, its own log and its own owner.

Public-sector rules already assume this. OMB M-24-10 requires minimum practices for rights- and safety-impacting AI, including human oversight and ongoing monitoring, under an accountable official (OMB, 2024). CISA and its partner agencies' joint guidance on AI security treats AI systems and the data they use as assets with their own access controls and monitoring across the lifecycle, rather than as a feature of a user's account (CISA, 2025). Accenture's Technology Vision 2025 reports that 77 percent of executives believe AI's benefits depend on trust, defined to include traceability (Accenture, 2025), and traceability to an identity that can answer is what a borrowed login removes.

What does a distinct agent identity look like in practice?

A distinct identity is not a second user account. Service accounts are the oldest non-human identity and they illustrate the trap: shared across jobs, rarely rotated, over-permissioned because nobody wants to break the batch run, owned by a team rather than a person. An agent identity built on that pattern inherits every one of its problems, with a model attached. Gartner's May 2026 warning that uniform governance across agents leads to failure applies here: one shared identity for all agents cannot express that the invoice agent and the enrollment agent need different scopes, different approvers and different records (Gartner, 2026).

A workable agent identity has five parts. First, a principal that is the agent, named as an agent in the directory and the logs, with a record of which model performs the work. Second, a named human owner who granted the access, chose the applications, confirmed the policy and approves the consequential actions: the owner is accountable, the agent is attributable. Third, a scope set per task in the terms the work uses, screens, fields and actions, not roles designed for people. Fourth, a credential the model never reads. Credential protection is a neighboring discipline; OpenAI documents supplying passwords to the browser environment without passing them to the model for dots' secure sign-in (OpenAI, 2026). Fifth, a lifecycle tied to the task: the identity exists for the run, expires with it and is revoked by the owner.

Where the agent works through bought applications, there is a twist: a claims platform has no concept of an agent principal and only knows how to authenticate a user. The agent therefore works under the person's application access, and the agent identity has to live in the environment around the applications, the one that decides what the agent may see on each screen, which actions it may take, and who approves them. Zero trust's policy engine model points the same way, with decisions made by an enterprise-owned component that sees the subject, the resource and the context on every request (NIST, 2020).

How do a named owner and per-run records resolve accountability?

Identity answers who. Accountability also needs when, what and on whose authority, and those live in the record. A per-run record changes the question from "whose account was this?" to "which run was this, who owned it, what did the agent see, and who approved the step?"

The owner's role is specific. The owner grants the access before the run, chooses which applications the agent may open, confirms what the agent will and will not see, can watch and pause while it runs, and approves every consequential action: the payment, the submission, the record change. That approval is the moment accountability attaches to a person, on the record, for an action a model proposed. OpenAI's dots documentation reaches a related conclusion from the vendor side, keeping sensitive operations with the user and stating that Custom Rules cannot override mandatory confirmations (OpenAI, 2026). A confirmation prompt becomes an accountability control when the approval is recorded with a name against a specific run and exported to a system the organization owns.

The record needs three things a user activity log lacks: the run named as distinct from the person's own session, what the model received, since an agent that saw a full record and one that saw three tokenized fields are different exposure events even when the action was identical, and the approval with the approver's name next to the action it authorized. Paris, Moon and Guo's FAccT 2026 paper on verifiability warns that technical verification schemes for AI claims rest on unexamined assumptions and can produce misplaced trust (Paris, Moon and Guo, 2026). A vendor's assurance that its agent behaved is not the organization's record; what the organization can produce from its own monitoring is. The AI Control Record is RedactSure's term for that record, and the page on auditing agent activity works through what a reviewer should ask of it.

How is agent identity different from credential protection and least privilege?

Three disciplines overlap here and buyers often collapse them. Credential protection keeps the secret that unlocks a system out of the model's context. Least privilege limits what the account can reach. Agent identity decides who the actor is and who answers for it. A deployment can have the first two and fail the third: the credential is vaulted, the account is scoped, and the log still names the person whose role it borrowed. The existing page on least privilege covers why permission scoping does not decide what the model sees on a screen; the same logic applies to identity. Permissions describe reach. Identity describes responsibility.

The distinction matters for incident response. Greshake and colleagues showed that content an agent reads can carry instructions that redirect it, so an agent that finished a task may have been steered by a web page or document along the way (Greshake et al., 2023). The response team then needs to know which runs were affected, what each saw, and who approved what. A credential vault answers none of that; a least-privilege review answers which systems were reachable, not which were read. Only an identity that distinguishes the run, bound to a record of what it received and who approved its actions, lets the team scope the incident. Wallace and colleagues' instruction hierarchy work shows vendors training models to prefer privileged instructions over content (Wallace et al., 2024); that reduces the chance of being steered and does nothing for attribution afterwards.

McKinsey's 2026 State of AI survey, as reported by CX Today, found 62 percent of organizations experimenting with agents and 23 percent scaling them (CX Today, 2026). Identity is one of the quieter causes of that gap: a pilot can run under a volunteer's login with everyone watching, and production cannot.

Where does RedactSure sit?

RedactSure's design gives each run an identity and an owner without changing user permissions. The agent works inside a governed environment the customer deploys into its own cloud, on the organization's existing applications, with no per-application integration. The Planner sets which values are tokenized and what the agent may do on each screen, and a named person confirms that policy before the run. That person grants the access, chooses the applications, confirms what is tokenized, can watch and pause the run, and approves every payment, submission and record change while it runs, which is Supervised Delegation. The model receives the task's fields with identifiers as tokens, render-layer tokenization having replaced them before any model reads the screen, and real values resolve only at approved destinations at the moment of an approved action.

Every screen as tokens, every action and every approval with a name lands in the AI Control Record and exports to the customer's own SIEM, with keys the customer holds. The environment is model agnostic, so the identity and the record stay in place when the model changes. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page is a definitional synthesis. It rests on standards and official guidance read as of October 13, 2026: NIST Special Publication 800-207, Zero Trust Architecture (2020), NIST Special Publication 800-63-4, Digital Identity Guidelines (2025), OMB Memorandum M-24-10 (2024), and joint AI security guidance published by CISA with partner agencies (2025), all cited as official guidance; the OWASP Top 10 for LLM Applications 2025 entry LLM06, cited as an industry standard; the Microsoft AI Red Team taxonomy of agentic failure modes (2025, whitepaper) and Anthropic's agentic misalignment report (2025, research report), cited as vendor research; the Greshake et al. and Wallace et al. preprints and the Paris, Moon and Guo FAccT paper, cited as research; and Gartner, Accenture and McKinsey findings as reported, cited as industry analysis. OpenAI's dots safety documentation is cited for what it states about its own product.

No product was tested. No agent was run under any identity scheme, no identity provider was evaluated, and no count of identity-related agent incidents is reported, because none was found in the sources consulted. Vendor features and guidance editions change; the page carries its date and is revised when the sources change. The claims platform, student information system and invoice examples describe kinds of work, not any organization; no customer or prospect is described. Statements about RedactSure are limited to the design facts the company publishes about itself.

Whether a given identity design satisfies an organization's obligations under its regulators, its auditors or any statute is a determination for its counsel, its assessor and its security and compliance officers, who hold the policies and the risk tolerance the determination depends on, not for the page.

What the record shows

An agent acting under a person's login authenticates correctly and attributes wrongly: the directory says the person acted when a model chose the step, in a session the person was not watching, with the person's whole role as its scope. Agent identity fixes the attribution by naming the agent as the actor and a person as the owner, and per-run records fix the accountability by holding what the agent saw, what it did and who approved each consequential step. The test takes one completed run: ask for its identity as distinct from the user's session, the name of its owner, and the approval record for the one action that changed a record. If the answer is an account name and a timestamp, the organization has a user log, not an agent identity.

Frequently asked questions

Is an AI agent identity the same as a service account?

No. A service account is a shared, long-lived non-human identity owned by a team, with shared scope, unclear ownership and standing access. An agent identity names the agent as the actor, binds it to a named human owner, scopes it per task, keeps its credential out of the model and expires it with the run.

Can an agent just use the employee's login?

In most bought applications it has to, because the application only knows how to authenticate a user. The problem is attribution: the log names the employee for steps a model chose. The fix is an environment around the application that records the run as the agent's, names the owner and holds each approval, so the application's user log is not the only record.

Who is accountable when an agent under a borrowed login makes a mistake?

Without a distinct identity and a per-run record, no one cleanly: the employee did not choose the step, the model is not a person, and the vendor disclaims the deployment. With a named owner who granted the access and approved the action, accountability attaches to that person at the moment of approval, on the record.

Does zero trust solve agent identity?

It supplies the right shape, per-request decisions by an enterprise-owned policy engine, but only if the subject presented to that engine is the agent on a task rather than the person whose credential it borrowed. A distinct agent identity is a precondition for applying zero trust to agents, not a substitute for it.

How is agent identity different from credential protection?

Credential protection keeps the password or session token out of the model's context so it cannot be repeated or redirected. Agent identity decides who the actor is and who answers for it. A deployment can vault the credential and still log every agent action under the employee's name.

What should be in a per-run record for an agent?

The run's identity as distinct from the owner's own session, the model that performed the work, what the model received on each screen (as tokens where identifiers were tokenized), each action, and each consequential action with the name of the person who approved it, exported to monitoring the organization owns. A dashboard the organization cannot export is the vendor's record.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Key findings

What does a user access model assume that an agent breaks?

How do sessions, scope and accountability differ for an agent?

Why is a borrowed login an accountability problem, not only a security one?

What does a distinct agent identity look like in practice?

How do a named owner and per-run records resolve accountability?

How is agent identity different from credential protection and least privilege?

Where does RedactSure sit?

Methodology and limitations

What the record shows

Frequently asked questions

Is an AI agent identity the same as a service account?

Can an agent just use the employee's login?

Who is accountable when an agent under a borrowed login makes a mistake?

Does zero trust solve agent identity?

How is agent identity different from credential protection?

What should be in a per-run record for an agent?

Related reading

Sources

What Is AI Agent Access Control?

What Is an Overprivileged AI Agent?

What Is an Autonomous AI Agent?

What Is AI Agent Credential Protection?

What Is AI Agent Session Isolation?

Does Least Privilege Cover What an AI Agent Sees?

How Do You Audit What an AI Agent Saw and Did?

Accountable AI and Workflow Governance

What Is Supervised Delegation?

What Is an AI Control Record?

What Is Render-Layer Tokenization?

Bring your hardest questions.

About the author