AI Agent Identity in 2026: Why Service Accounts Are Not Enough

AI agent identity became an infrastructure problem in 2026

The first generation of business agents was often deployed like an integration script: create one service account, place its token in a secret store, and let the application call several APIs. That pattern is convenient because every tool call succeeds under one stable identity. It is also where accountability starts to disappear.

An agent does not merely repeat a predetermined request. It interprets changing context, selects tools, constructs arguments, retries, and may cross several systems while pursuing an outcome. The authority required for one step can be very different from the next. A support agent may read a customer record, draft a refund, request approval, and then instruct a payment system. If all four operations appear as the same service account, the receiving systems cannot reliably answer who initiated the task, which agent instance acted, whether a human approved the refund, or whether the credential was valid for that specific customer and amount.

This is no longer a niche concern. In February 2026, NIST launched its AI Agent Standards Initiative with agent security, identity, authorization, and interoperability among its stated priorities. NIST's related concept paper focuses on distinguishing human and agent identities, delegated access, authorization, logging, transparency, and data provenance. The direction is practical: agents need an accountable chain of authority, not a larger collection of reusable API keys.

One agent action can involve four different principals

A useful architecture stops asking for one universal answer to ‘Who is the agent?’ and records the identities that matter at each boundary.

The first is the requesting principal: usually a person, but sometimes a scheduled business process or another service. This principal supplies the original authority and business context. The second is the workload identity of the deployed application—the cryptographically verifiable process, container, function, or service that is allowed to request credentials. The third is the agent execution or session: a specific run with a purpose, policy version, model configuration, and expiry. The fourth is the downstream client seen by the tool or resource server.

These identities should be correlated, not collapsed. The workload proves that approved software is making the request. The user identity establishes whose authority may be delegated. The execution identity gives the action a bounded lifecycle. The downstream credential limits where and how that authority can be exercised. When everything becomes `automation@company.com`, each control loses information it needs.

Why a shared service account loses the facts that authorization needs

A service account is not inherently insecure. It is appropriate for a bounded machine workload with stable permissions: exporting one approved dataset, rotating a cache, or writing metrics to a single destination. The problem begins when a flexible agent uses the same long-lived identity to act for many users, tenants, purposes, and tools.

First, the service account carries aggregate authority. If one user may view only Region A and another may approve only invoices below a threshold, a broad agent credential can silently bypass both boundaries. Application code is then expected to recreate every downstream entitlement correctly. One missed check becomes privilege escalation.

Second, the credential usually says nothing about delegation. A resource server sees the application but not the human, agent run, or approval behind it. Third, the credential is reusable. A token copied from memory, logs, a developer machine, or a compromised tool may work outside the original task. Fourth, revocation is coarse. Disabling the account can stop every agent workflow, while leaving it active preserves an exposed credential.

The safer alternative is not ‘one service account per agent name.’ That still creates static identities with growing permission sets. The goal is transaction-specific authority derived from authenticated principals and enforced by the target system.

Delegation is usually safer than silent impersonation

When an agent acts as a user, teams often pass the user's token downstream and call the result ‘on behalf of.’ That can produce impersonation: the target sees the user as the subject but cannot distinguish the software actor. The user appears to have made the call directly.

Delegation preserves both sides of the relationship. The resource can identify the subject whose authority is being used and the actor exercising it. OAuth 2.0 Token Exchange, RFC 8693 defines delegation and impersonation semantics and includes an `act` claim for identifying an acting party. It also warns that delegated rights create abuse potential and recommends constraints such as limited scope and token lifetime.

This distinction matters operationally. A customer may authorize an agent to prepare a payment but not release it. An employee may let an assistant read availability but not expose private event descriptions. A purchasing agent may compare vendors but require a named approver for commitment. If the downstream system sees only the user, it cannot enforce or explain the boundary between preparation, recommendation, approval, and execution.

Prefer delegation when the receiving system can evaluate both principal and actor. Use impersonation only when a legacy target cannot understand delegated actors, the risk is low enough, compensating controls exist at the adapter, and the audit record still preserves the original chain.

Authorize the proposed action, not the agent's confidence

Identity supplies facts to a policy decision; it does not make the decision by itself. The enforcement point should evaluate the principal, actor, tenant, target resource, action, amount or sensitivity, task purpose, environment, approval state, and relevant risk signals. The model can propose `prepare refund for invoice 481`, but a deterministic layer must decide whether that operation is allowed.

Place that check at the tool gateway or protected resource, close to the state change. A prompt instruction such as ‘never refund more than £500’ is useful behavioural guidance, but it is not an authorization control. Retrieved documents, emails, websites, and tool output can influence the model. OWASP's AI Agent Security Cheat Sheet identifies tool abuse, privilege escalation, prompt injection, data exfiltration, and excessive autonomy among the core risks and recommends least privilege and authorization middleware.

The policy should return more than allow or deny when the workflow needs nuance. It can reduce a requested scope, require step-up authentication, route the exact action for approval, demand a second source, cap an amount, or issue a read-only credential. Denial must fail closed: the agent may explain the constraint or request help, but it should not search for a more permissive tool.

MCP standardizes connections; it does not choose your business authority

Model Context Protocol can standardize how an AI host discovers and calls tools, but a protocol connection does not decide what a particular agent should be allowed to do. Your host, authorization server, tool gateway, and resource systems still own identity, consent, policy, and audit. This is the same boundary explained in MCP Explained: What It Actually Does for Your AI Tools.

The MCP specification published on 28 July 2026 strengthened and clarified parts of its authorization model, including changes intended to align OAuth and OpenID Connect deployment more closely with established practice. That progress matters, but it should not be read as permission to grant one MCP client every tool scope. Machine-to-machine client credentials identify the client; they do not automatically preserve a human delegation chain. Interactive authorization establishes user involvement; it does not automatically make every later model-selected action appropriate.

Treat MCP authorization as one transport-layer component in a larger design. Register and authenticate clients correctly, request narrow scopes, protect tokens from model context, validate resource and authorization-server metadata, and apply business policy inside or in front of every consequential tool.

What to do when the target system only understands one technical user

Many production systems cannot consume actor claims, token exchange, or modern workload identity. Do not respond by exposing them directly to the agent. Put a narrow adapter in front of the legacy interface, as described in connecting AI agents to legacy systems safely.

The adapter authenticates the modern caller, evaluates delegated authority, exposes only task-specific operations, validates parameters, applies tenant and record filters, manages the legacy credential outside model reach, and writes an audit event before and after the call. To the old system, the adapter may still appear as one service account. To your control plane, every action retains its principal, actor, purpose, approval, and result.

This is a compensating control, not a perfect substitute for native authorization. Keep the adapter's account narrowly privileged, separate read from write operations, make high-impact actions reversible where possible, monitor use, and plan migration based on the risk and volume passing through the seam.

An identity design is only useful if the audit trail can prove it

A successful API response is not sufficient evidence that an action was legitimate. The trace should let an investigator reconstruct the request without relying on a conversation transcript: who initiated it, which agent and deployment ran, what information informed the proposal, which tool and arguments were selected, what policy allowed or narrowed the action, whether approval was required, which credential audience and scopes were issued, and what changed downstream.

Use stable identifiers to connect these events without copying sensitive tokens or unrestricted prompt content into logs. Protect the log from casual alteration, restrict access, redact secrets and unnecessary personal data, and define retention around business and legal needs. The implementation details in Auditing AI Agent Actions and AI Agent Observability complement identity: observability tells you what happened across the run, while identity and authorization explain who was permitted to make it happen.

Review denied actions too. Repeated requests for broader scopes, cross-tenant records, unusual tool sequences, approval mismatches, or credentials for unexpected audiences may reveal prompt injection, policy gaps, compromised workloads, or a workflow that was designed with the wrong authority boundary.