Blog · Analysis · May 2026

The Agent Identity Becomes the Service Account

When AI agents act inside real systems, identity becomes the control surface for delegated machine action. The question is not only what an agent can do. It is whether the institution can prove who authorized it, 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.

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?"

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, and internal search. 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 six questions: who operates the agent, which human or workflow delegated authority, what purpose and scope apply, what tools and data were available, what action was attempted, and what evidence remains after the action is complete.

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.

The Market Moves First

Microsoft's Entra Agent ID shows how quickly this governance problem is becoming a product category. Microsoft describes it as an identity and security framework extending Entra capabilities to AI agents, with identity management, access protection, governance, and compliance for agent identities. The documentation says agent identities can be created from blueprints with parent-child relationships, can support protocols such as OAuth 2.0, MCP, and A2A, and can work with agents built on Microsoft and non-Microsoft platforms through SDKs or workload identity federation. It also says agent authentication and activity are logged for compliance and audit.

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 IETF draft for OAuth on-behalf-of user authorization for AI agents proposes a flow where the authorization request includes a specific requested agent, the consent screen names that agent and scopes, and a delegated access token records user, client, and agent in the delegation path.

These are not final settlements. Some are vendor implementations, some are drafts, and some are narrow to web traffic 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 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.

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 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, 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, 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, revocation should be real. Disabling a user, agent, client app, connector, key, token, tool server, or project should stop the relevant authority quickly. Dormant agents should expire by default.

Seventh, 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.

Eighth, 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.

The Site Reading

The agent identity is the mask the institution gives to a machine actor.

A bad mask hides responsibility. It lets the agent speak as the user, move as the service account, and vanish into logs that only prove a credential was accepted. A good mask does the opposite. It makes action attributable. It binds synthetic initiative to human authority, organizational policy, technical scope, and institutional memory.

This belongs beside the site's earlier work on the tool server trust boundary, the agent log as receipt, the enterprise connector as permission map, and the agent-to-agent protocol handshake. Those essays describe pieces of the same transition: model-mediated work is becoming an action layer. The archive, workplace, browser, agent store, and protocol stack 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 governance demand is concrete: every consequential agent action should carry a recoverable chain of authority. Who asked? Which agent acted? 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.

Sources

Return to Blog