Blog · Analysis · Last reviewed June 25, 2026

The Agent Identity Becomes the Service Account

When AI agents act inside real systems, identity becomes the control surface for delegated machine action. Whether an agent can perform a task matters far less than whether the institution can prove who authorized it, what account or workload principal it used, what it was allowed to touch, what it actually did, and how to revoke it when the story changes.

Identity Is the Action Boundary

An AI agent becomes institutionally serious at the moment it stops merely answering and starts acting. Reading a calendar, filing a ticket, sending a message, querying a data warehouse, opening a pull request, changing a permission, ordering supplies, approving a refund, or escalating a security alert all require access. Access requires identity.

An agent identity is not just a display name. It is a governed principal, or a record attached to one, that binds an agent class or instance to an operator, sponsor, purpose, scopes, credentials, runtime, tool surface, approval policy, audit trail, and revocation path. It should let a downstream system distinguish "Alice clicked this" from "a sales-summary agent acted for Alice under this bounded delegation."

The definition has to separate four layers that products often collapse. Identity names the non-human actor. Credentials let that actor authenticate. Delegation explains whose authority and purpose the actor is using. Receipts preserve enough evidence to review the action later. A service account can carry one of those layers, but it should not be allowed to masquerade as all four.

This does not make the agent a legal person, moral agent, employee, or consciousness. It means the institution refuses to let software action vanish into a generic token. The identity record is administrative, not metaphysical: it exists so access control, investigation, appeal, and revocation can survive automation.

That sounds like ordinary enterprise plumbing. It is not. A human identity usually belongs to a person with employment status, duties, credentials, supervision, discipline, memory, and legal accountability. A service account usually belongs to a workload with a defined purpose. An AI agent sits awkwardly between them. It may operate under a user prompt, a workflow, a scheduled task, a tool call, a delegated chain, or another agent's request. It may be persistent or temporary. It may reason over new context before choosing which tool to call. It may do something no administrator enumerated in plain language when the credential was issued.

The identity layer is where those ambiguities become operational. If the agent acts as the user, every action can look like the user did it. If it acts as a broad application service principal, many users and tasks collapse into one technical actor. If it has its own identity, the institution still has to bind that identity to a human principal, scope, policy, runtime, model, tool set, and revocation path.

The old question was "Can this software authenticate?" The agentic question is harder: "Can this system prove the chain of authority behind a machine action that was partly selected at run time?"

Current Context

As of June 25, 2026, agent identity has moved from an architectural worry into standards work and product infrastructure. NIST's AI Agent Standards Initiative treats agent authentication and identity infrastructure as research and standards work for secure human-agent and multi-agent interactions. NIST's NCCoE project page for software and AI agent identity is now in "Reviewing Comments" status after the April 2, 2026 close of the concept-paper comment period. That makes it a live project signal and draft problem statement, not a completed practice guide.

The standards layer is still plural. IETF WIMSE work is developing workload-identity architecture for conveying workload identity and security context across systems. The Agent Authorization Profile for OAuth 2.0 remains an active individual Internet-Draft for agent-specific authorization, with structured claims for agent identity, task context, operational constraints, delegation chains, and human oversight. The older on-behalf-of user authorization draft remains useful as a design sketch even though it expired in November 2025.

On the product side, Microsoft now describes Entra Agent ID as generally available and as first-class identity and access management for AI agents. Its documentation defines agent identities as special service principals created from blueprints, says agent identities do not hold credentials of their own, distinguishes user-delegated and autonomous token acquisition, and names sponsors as accountable humans or groups. Microsoft also says Agent 365 is becoming the unified registry and control plane for agents while Entra Agent ID remains the identity foundation, and its lifecycle-workflow materials include sponsor transfer so agent identities do not lose human accountability when a sponsor leaves.

Product documentation is evidence of product direction, not independent assurance that a deployment is least-privilege or safe. It still marks the direction: agents are being governed as non-human actors with lifecycle, access, monitoring, sponsorship, registry, and policy controls rather than as invisible helper text inside a chat product.

For this site, the identity question connects directly to AI Agent Identity, AI Agents, Agent Tool Permission Protocol, Agent Prompt Hardening, Agent Audit and Incident Review, AI Agent Observability, The Agent Log Becomes the Receipt, The Enterprise Connector Becomes the Permission Map, and Digital Identity. Agent identity is where permission, prompt-injection defense, audit, and revocation meet.

Service Account Inheritance

Most organizations already live with more non-human access than they can comfortably govern. CyberArk's 2025 identity-security report press release said machine identities outnumber human identities by more than 80 to 1, and that nearly half have sensitive or privileged access. That figure comes from a vendor with commercial incentives, so it should be treated as industry evidence rather than neutral census data. The direction is still plausible and widely recognizable: APIs, workloads, certificates, tokens, bots, automations, CI/CD systems, cloud services, and integrations already produce a dense population of non-human actors.

AI agents inherit this world. They do not arrive on a clean slate. They attach to calendars, drives, email, CRM, Slack, Teams, GitHub, Jira, databases, cloud consoles, payment systems, code repositories, internal search, MCP servers, and enterprise connectors. The quick implementation path is tempting: give the agent an existing account, reuse a broad OAuth grant, hide it behind a service principal, or let it operate under the human's session.

That path creates identity collapse. The audit log says a user, app, or service account acted, but the real action included a model, prompt, tool server, connector, retrieved context, policy decision, user instruction, and possibly another agent. The log may be technically true and institutionally useless.

This is why agent identity cannot be reduced to naming. A name in a directory is only the start. A useful agent identity has to answer at least eight questions: who operates the agent, who sponsors it, which human or workflow delegated authority, what purpose and scope apply, what tools and data were available, what credential was used, what action was attempted, and what evidence remains after the action is complete.

The hard case is the legacy system that only understands human-like accounts. Microsoft now names this pattern directly as an optional "agent's user account" paired one-to-one with an agent identity for systems that require a user object. That is useful vocabulary because it preserves the distinction: the user-shaped account is an interoperability shim. It should not replace the agent identity, sponsor, policy, or audit chain.

The control goal is not to make every agent permanent. Some identities should be long-lived workload actors; some should be short-lived task actors; some should be denied direct action and allowed only to draft. The important point is that duration, scope, sponsor, and credential lifetime are deliberate design choices rather than accidental inheritance from whichever service account was easiest to reuse.

NIST Names the Problem

NIST's AI Agent Standards Initiative, launched in February 2026 and updated in April 2026, frames agent standards around trusted, interoperable, and secure autonomous action. Its stated pillars include industry-led standards, community-led protocols, and research into agent authentication and identity infrastructure for human-agent and multi-agent interactions.

The more concrete document is NIST NCCoE's February 2026 concept paper on software and AI agent identity and authorization. It asks how identification, authentication, and authorization should apply to agents that access data, tools, and applications. The paper's questions are revealing because they are not abstract ethics prompts. They are implementation questions: what metadata belongs in an agent identity, whether identity should be ephemeral or fixed, how key issuance and revocation should work, how least privilege applies when required actions are not fully predictable, how an agent proves authority for a specific action, how "on behalf of" delegation works, and how logs can support non-repudiation.

That list is the governance map. It says the problem is not solved by adding a checkbox that says "AI agent." Agent identity has to carry enough structure for access-control systems, auditors, administrators, users, and affected parties to reconstruct authority after the fact.

NIST also places prompt injection in the same frame. That matters. If an agent reads untrusted content and then takes action, the identity system cannot assume that every action cleanly expresses the user's intent. Authorization must survive hostile context. A token that lets the agent do everything the user can do is not least privilege when the agent can be steered by a document, email, web page, tool result, or retrieved record.

This is the classic confused deputy problem in agentic form: a program trusted with broad authority is tricked by a less-privileged party into misusing it. EchoLeak made it concrete. Disclosed in June 2025 and tracked as CVE-2025-32711, it was a zero-click prompt-injection vulnerability in Microsoft 365 Copilot in which a crafted email could enable remote, unauthenticated data exfiltration. NVD lists Microsoft's CVSS 3.1 score as 9.3 critical, while NIST's own enrichment score is 7.5 high. The arXiv case study describes the attack as full privilege escalation across LLM trust boundaries without user interaction. The identity lesson is permanent: if an assistant reads untrusted content while holding broad delegated access, the access is not only the safeguard; it is also the attack surface.

That case should be read carefully: it is a specific disclosed vulnerability, not a universal claim that every enterprise assistant fails the same way. Its general lesson is about trust boundaries. Untrusted content plus broad delegated access can turn identity into an exfiltration route.

The Market Moves First

Microsoft's Entra Agent ID shows how quickly this governance problem is becoming a product category. Microsoft describes the Agent ID platform as generally available, with identity and authorization for AI agents operating in enterprise environments and support for protocols such as OAuth 2.0, MCP, and A2A. The documentation says an agent identity is a special service principal, that agent identities are created from blueprints, that blueprints can carry permission and logging configuration, and that a sponsor can record the human user or group accountable for an agent.

This is a serious architectural admission: agents are being treated as enterprise actors. They need lifecycle management, adaptive access policies, risk detection, sign-in logs, audit logs, and network controls. The assistant becomes something closer to a user, a workload, and a delegated representative at once.

Other infrastructure points in the same direction. Cloudflare's signed-agent documentation describes end-user-controlled bots verified through Web Bot Auth cryptographic signatures, so automated traffic can be distinguished from spoofed user-agent strings or IP-based guesswork. The Agent Authorization Profile for OAuth 2.0 proposes structured claims and validation rules for agent identity, task context, operational constraints, delegation chains, and human oversight. The expired on-behalf-of user authorization draft is still useful because it shows the same pressure from a different angle: agent delegation needs token-level evidence, not just a consent screen.

These are not final settlements. Some are vendor implementations, some are drafts, and some are narrow to web traffic, workload identity, or enterprise identity. But they point to the same institutional truth: once agents act across systems, authorization cannot remain an invisible wrapper around a chat box. It has to become a record-bearing protocol.

Delegation Needs a Record

Delegation is the difference between an agent and an automation script pretending to be a person.

A serious delegation record should say that a particular human, role, workflow, or supervising system authorized a particular agent instance to perform a bounded class of actions for a bounded purpose over a bounded time, using bounded tools and data, with bounded ability to delegate further. That sounds bureaucratic because it is. Authority is a bureaucratic object before it is a technical token.

The record should also separate four things that are easy to collapse: the agent identity, the credential used to authenticate, the delegation grant that authorizes a specific purpose, and the runtime trace showing what happened. A permanent service principal, a short-lived token, a user approval, and an audit log are not interchangeable. Together, they are the chain of authority.

The emerging protocol work points toward purpose-bound records rather than all-purpose bearer power. The Agent Authorization Profile draft, for example, sketches token claims for agent metadata, task purpose, capabilities, constraints, delegation depth, and audit trace identifiers, while also warning that privacy requires claim minimization when tokens cross trust boundaries. Even if that draft changes or never becomes a standard, the design pressure is real: an agent token should say what job it is doing, not only which client asked for access.

The hard part is that agents often discover the next step while working. A user asks for a vendor-risk summary. The agent searches email, reads contracts, checks sanctions lists, opens a spreadsheet, writes a memo, and maybe asks another agent to review financial exposure. Some steps are read-only. Some disclose sensitive data. Some create durable records. Some may trigger external communication. Some may require a human pause.

Static role assignment does not capture that path. Neither does a single "Allow access to your files" consent screen. The permission should be decomposed by action type, data class, destination, purpose, time, and escalation threshold. The agent should be able to ask for more authority, but the request should name the new action and the reason. That approval should become part of the record, not a disappearing modal.

In high-stakes domains, the record must also bind to consequences. If a legal agent files a document, a security agent disables an account, a purchasing agent spends money, or a health-care agent sends a message to a patient, the institution needs more than a trace that a tool call occurred. It needs an accountable chain: policy, principal, agent, model or runtime, tool, data source, decision point, human approval where required, and final action.

The Identity Dossier

A governed agent should have an identity dossier before it receives meaningful authority. The dossier is not a biography of the model and not a full prompt archive. It is the administrative evidence package that lets security, audit, procurement, and incident teams reconstruct who the agent was, whose authority it used, and what could be revoked.

The dossier should be queryable. A security team should be able to ask which agents can write to finance systems, which blueprints can mint identities, which sponsors are leaving the organization, which agents read untrusted content before write actions, and which service-account shims still exist for legacy systems. If those queries are impossible, the organization does not have agent identity governance. It has names.

Failure Modes

The first failure mode is borrowed identity. The agent uses the human's session, so logs, notifications, and downstream systems cannot distinguish human action from delegated machine action.

The second is service-account fog. Many agents share one application identity or privileged service principal. Investigation can prove that "the integration" acted, but not which agent, prompt, user, workflow, or approval caused the action.

The third is standing privilege. An agent receives durable broad access because it might need it later. That defeats least privilege precisely where prompt injection and tool misuse make broad access dangerous.

The fourth is delegation drift. A user approves a narrow task, but intermediate steps expand purpose, data exposure, or downstream action until the original consent no longer describes what happened.

The fifth is orphaned agents. A project ends, an employee leaves, a connector is replaced, or a workflow is retired, but the agent identity, token, key, or scheduled authority remains alive.

The sixth is uninspectable refusal. A system blocks an agent for security reasons, but the user and administrator cannot tell whether the block came from policy, expired delegation, risk detection, tool failure, prompt-injection defense, or vendor-side guardrail.

The seventh is consent theater. The user sees a vague approval screen, while the real power sits in broad scopes, downstream connector inheritance, hidden tool calls, and unclear retention of logs and retrieved data.

The eighth is sponsor ambiguity. The directory can show an agent identity, but no accountable human, team, vendor owner, or retirement path exists when it behaves badly or stops being needed.

The ninth is agent sprawl. Teams create assistants, custom agents, MCP-enabled workflows, and scheduled automations faster than the identity program can inventory them. The result is a population of non-human actors with unclear owners, duplicated scopes, stale blueprints, and no emergency disable map.

The tenth is delegation laundering. One agent asks another agent, connector, plugin, or tool server to act, and the downstream system sees only the final caller. The originating user, purpose, data class, prompt-injection exposure, and approval decision disappear from the chain.

The Governance Standard

A serious agent-identity regime should meet a higher standard than "give the bot an account."

First, agents should have distinct identities. A consequential agent should not disappear into a human login or shared service account. Its identity should name the operator, sponsor, owner, purpose, environment, model or runtime class, version, and approved tool boundary.

Second, delegation should be explicit and bounded. Authority should specify principal, purpose, scope, duration, data classes, allowed actions, allowed destinations, credential type, and whether further delegation is allowed.

Third, permissions should be action-shaped. Read, write, send, delete, purchase, approve, publish, deploy, and change-access are different authorities. The interface should not collapse them into one friendly consent event.

Fourth, high-risk actions need step-up approval. The agent may prepare, draft, recommend, and queue. Spending money, contacting outsiders, changing permissions, deleting records, filing legal documents, deploying code, or affecting a person's status should trigger stronger confirmation and recordkeeping.

Fifth, logs should bind identity to intent and outcome. The record should include the human or workflow principal, agent identity, tool call, data source category, authorization basis, approval event, result, error, and downstream object changed. Logs should be useful for investigation without turning every prompt into unnecessary surveillance.

Sixth, credentials should be short-lived and constrained. Prefer managed identities, federated identity credentials, proof-of-possession where appropriate, separate read and write credentials, and token lifetimes that match the task. Avoid long-lived secrets and broad reusable grants.

Seventh, revocation should be real. Disabling a user, agent, client app, connector, key, token, tool server, blueprint, or project should stop the relevant authority quickly. Dormant agents should expire by default.

Eighth, prompt-injection risk should shape access. Agents that read untrusted content should receive narrower tokens, stronger isolation, content-origin labels, and stricter approval requirements before write actions.

Ninth, users should see the actor. Approval screens, audit views, notifications, and generated artifacts should make clear when an action is performed by an agent, on whose behalf, with what authority.

Tenth, user-account shims should be exceptional. If a legacy mailbox, calendar, or collaboration system requires a user object, pair that account to a distinct agent identity, mark it as agent-operated, scope it narrowly, and keep it out of ordinary human groups unless the risk has been reviewed.

Eleventh, organizations should maintain an agent register. The institution should be able to list active agents, sponsors, identities, blueprints, connectors, credentials, scopes, data classes, logs, expiration dates, and emergency disable paths. If no one can inventory the actors, no one can govern their authority.

Twelfth, delegated claims should be minimal. Tokens and tool calls should carry enough purpose, capability, and trace context to enforce policy, but not unnecessary personal data, prompt text, or long-lived correlation identifiers when crossing trust boundaries.

Thirteenth, affected people need appeal paths. If an agent changes access, sends a notice, opens a case, denies a request, or contributes to a consequential decision, the affected person should be able to ask which agent acted, under whose authority, and how to correct the record.

What This Changes

An agent identity is not just a login. It is the place where delegated machine action becomes accountable or disappears.

A weak identity scheme lets the agent speak as the user, move as a shared service account, and vanish into logs that only prove a credential was accepted. A strong one does the opposite. It binds machine action to a human or organizational principal, a purpose, a scope, a tool boundary, an approval record, and a revocation path.

This is the same transition visible in tool servers, agent logs, enterprise connectors, and agent-to-agent protocols: model-mediated work is becoming an action layer. Browsers, workplaces, archives, app stores, and protocol stacks are no longer only places where information is displayed. They are places where authority is delegated.

The danger is not that agents receive identities. They need them. The danger is that identity becomes a comforting label while authority remains vague. An agent can be named and still be over-permissioned. It can be logged and still be unaccountable. It can be approved and still exceed the user's understanding of the task.

The standard should be concrete: every consequential agent action needs a recoverable chain of authority. Who asked? Which agent acted? Which sponsor owns it? Which credential was used? Under what scope? What data did it touch? What policy applied? Could a human stop it? Can the institution revoke it? Can the affected person challenge it?

Until those questions have durable answers, the agent identity is not accountability. It is a service account with a better story.

Source Discipline

Current-source claims in this essay were checked on June 25, 2026 against the primary sources listed below.

NIST's initiative and NCCoE concept paper are standards-work signals and draft problem statements, not binding law and not evidence that the market has solved agent identity. The NCCoE paper is especially useful because it names implementation questions around metadata, key management, least privilege, on-behalf-of delegation, non-repudiation, and prompt-injection mitigation; it is not a finalized control baseline.

IETF Internet-Drafts are works in progress: the WIMSE draft and Agent Authorization Profile should be read as evolving protocol design, while the May 2025 on-behalf-of user authorization draft had expired by June 2026. Draft claims such as task purpose, capabilities, delegation depth, and audit trace identifiers are useful for vocabulary, not proof of deployed interoperability.

Microsoft and Cloudflare sources are vendor documentation about product capabilities. They help identify emerging control surfaces such as agent service principals, blueprints, sponsors, lifecycle workflows, registry/control-plane consolidation, on-behalf-of flows, and signed-agent traffic, but they are not independent assurance that any deployment is least-privilege, auditable, or safe from prompt injection.

CyberArk's machine-identity numbers are vendor-reported industry evidence, not a neutral census. EchoLeak sources are a vulnerability record and research case study about a specific disclosed failure mode; the governance lesson is broader, but the facts should not be stretched into a claim that all agent systems are equally exposed.

Sources

Return to Blog