The 2026 AI agent auth checklist: 9 things to audit before you ship

Most AI agent security failures are not zero-days. They are the same handful of mistakes, repeated: an agent running under a borrowed user session, a static API key baked into an environment variable, no audit trail that distinguishes what the agent did from what the user did. The patterns are predictable. So is the blast radius when something goes wrong.

This checklist is for backend and platform engineers who are either building agentic systems or being asked to sign off on ones that already exist. It covers the nine properties that separate a production-grade agent authorization stack from one that will eventually cause an incident. Each item includes the risk you take on by skipping it and the implementation standard that closes the gap.

Work through it before you ship. Then keep it as your baseline when the system changes.

1. Every agent has its own identity

The risk: If agents run under a shared service account or borrow the authenticated user's session, you cannot attribute actions to a specific agent, cannot revoke access for one agent without affecting others, and cannot scope permissions to what each agent actually needs. When something goes wrong, your audit log will tell you that a human user made a series of API calls. That is not useful.

What good looks like: Each agent (or each class of agent, if you deploy multiple instances of the same role) is registered as its own OAuth client with its own client ID. It authenticates independently using the Client Credentials flow for machine-to-machine scenarios, or via a delegated OAuth flow when acting on behalf of a user. The agent's identity is separate from the user's identity at every layer of the stack.

The IETF is formalizing this direction: the SCIM working group is standardizing an /agents resource type, and NIST published a concept paper on agent identity in early 2026. The industry is converging on treating agents as first-class principals, not as extensions of the humans who invoked them.

Quick audit: Can you answer the question "which specific agent made this API call" for any call in your production logs from the last 30 days? If not, you do not have per-agent identity.

2. Agent permissions are the intersection of agent role and user permissions, never the union

The risk: An agent that inherits a user's full session token can do everything that user can do. If the user is an admin, a confused or manipulated agent is an admin. The OWASP Top 10 for LLM applications (2025) lists excessive agency as a primary risk category for exactly this reason. A single poisoned document in a RAG pipeline or a malicious prompt can redirect an over-permissioned agent to take actions the user never intended.

What good looks like: The intersection rule. An agent's effective authority at any given tool call must be calculated as the strict intersection of its own configured permissions and the requesting user's current permissions. If the user cannot delete a database record, the agent acting on their behalf must fail when it attempts the same action, regardless of what the agent's role technically allows.

Implementing this requires two identity layers on every request: the agent's workload identity (registered as an OAuth client, scoped to the application running the agent logic) and the user's delegated identity (authenticated via OpenID Connect, passed explicitly into every tool call). The runtime evaluates both before authorizing any action.

This is not the same as limiting the agent's role at provisioning time. It is a runtime check, evaluated per action.

Quick audit: If your most privileged user invokes your agent, does the agent inherit their full permission set? If yes, you are not enforcing the intersection rule.

3. OpenID Connect and OAuth 2.1 are used for separate purposes

The risk: Using a single token for both authentication and authorization is a common shortcut that creates durable, over-permissioned access. An ID token that doubles as an access token can be replayed against resource servers it was never scoped for. An agent compromised by prompt injection can reuse a human session to access unrelated systems.

What good looks like: OpenID Connect handles human authentication. It answers the question "who is this person" and establishes the session. OAuth 2.1 handles delegated authorization. It answers the question "what is this agent allowed to do on this person's behalf" and produces scoped, short-lived access tokens for specific resource servers.

These two protocols serve different purposes and should be kept strictly separate. The Model Context Protocol specification mandates OAuth 2.1 with PKCE as the authorization mechanism for MCP servers, precisely because the spec authors recognized that authentication and authorization are distinct problems requiring distinct solutions.

Quick audit: Is your agent using the same token it received at login to make downstream API calls? That token is almost certainly over-scoped.

4. Access tokens are short-lived, audience-bound, and scoped to the task

The risk: A long-lived token with broad scope that gets logged, leaked through a debug endpoint, or exfiltrated via a compromised dependency gives an attacker persistent, broad access. Static API keys are the worst version of this pattern, but OAuth tokens with 24-hour expiries and no audience binding are not much better.

What good looks like: Every access token issued to an agent should carry the full execution context as claims. The subject (sub) identifies the user on whose behalf the action is taken. The actor (act) identifies the agent making the call. The audience (aud) binds the token to a specific resource server. The scope grants the minimum permission required for the current task, not a superset of everything the agent might ever need. The expiry is set to a tight window, typically 5 to 30 minutes.

RFC 8707 (resource indicators) should be enforced to bind tokens to a specific audience, so a token minted for a calendar API cannot be replayed against a CRM. RFC 8693 (token exchange) provides the mechanism for safely trading a broad user token for a tightly downscoped agent token. For high-security deployments, RFC 9449 (DPoP, demonstrating proof of possession) sender-constrains the token to the client's private key, so that an intercepted token cannot be used without also compromising the key.

Quick audit: What is the expiry on the access tokens your agents use? Are they audience-bound? Can a token issued for one resource server be used against another?

5. Sensitive actions require explicit human approval

The risk: Agents with legitimate permissions can still cause damage by applying those permissions in ways no one anticipated. Most real-world agent incidents involve agents that had technically valid authorization for the actions they took. The agent did not exceed its permissions. It exercised them in an unintended context, often because a user phrased a request ambiguously or because a prompt injection redirected its behavior.

What good looks like: A set of actions is designated as requiring explicit human approval before execution. These typically include sending external communications, modifying or deleting records that cannot be recovered, exporting large datasets, making financial operations, and changing permissions or access controls. When the agent determines that an action falls into one of these categories, it pauses and surfaces a confirmation request to the user before proceeding.

This is the human-in-the-loop pattern, and it is not just a safety measure. It is also what enterprise buyers require before they will deploy agents against production systems. OAuth 2.1's authorization code flow supports this pattern natively: the user grants consent through a familiar browser-based flow, and the agent receives a scoped token that encodes what it is and is not allowed to do.

Quick audit: Make a list of the most destructive actions your agent can take. Is there an approval gate in front of each of them?

6. Tokens are vaulted server-side and rotated automatically

The risk: Tokens stored in environment variables, passed through prompts, or held in agent memory are one leak away from becoming an attacker's persistent access. The attack surface includes log files, debug endpoints, model context that gets exfiltrated via prompt injection, and compromised dependencies. Any of these can expose a credential that was never intended to leave the server.

What good looks like: OAuth tokens are stored in a backend credential store, never in the agent process itself and never in any content that passes through the model. The agent does not hold credentials. It requests that a backend service perform an action using credentials that the backend holds on the user's behalf. Refresh tokens are rotated on use, stored server-side only, and expire if unused.

The pattern is a credential gateway that sits between the agent and external services:

  
Agent
  -> Credential gateway
     -> External API (using user's vaulted token)
  

The agent never sees the OAuth token. It sends a request to the gateway, the gateway looks up the appropriate credential for the user and provider, makes the call, and returns the result.

Quick audit: Where are the OAuth tokens your agents use actually stored? Can the model see them in its context window?

7. Every agent action is written to an immutable audit log

The risk: Without an audit trail that ties actions to specific agent and user identities, you cannot investigate incidents, satisfy enterprise compliance requirements, or demonstrate to customers that their data was handled correctly. "The agent did it" is not an acceptable answer to a security questionnaire or a breach notification.

What good looks like: Every tool call an agent makes is logged with the full execution context: the user ID, the agent ID, the tenant or organization, the action taken, the resource affected, the timestamp, and the authorization context under which the action was permitted. The log is structured, queryable, and tamper-resistant.

The log entry for an agent action should answer five questions: who initiated the request, which agent executed it, what data was accessed or modified, what was returned or changed, and why access was permitted. If any of those five fields is missing from your current logs, you have an audit gap.

Enterprise buyers specifically ask for this. The ability to show an IT admin a complete, attributable history of what an agent did on behalf of their users is increasingly a requirement for enterprise deals, not a nice-to-have.

Quick audit: Pull the logs for any agent action from last week. Can you answer all five questions above from the log entry alone?

8. Access can be revoked immediately, per agent and per user

The risk: If a user revokes consent or an agent is compromised, the time between the revocation event and the agent losing access is the window during which damage can still occur. For agents with access to financial systems, customer data, or communications, that window needs to be as short as possible.

What good looks like: Revoking access for a specific agent (across all users) or for a specific user (across all agents) is a single operation that takes effect immediately. Access tokens are short-lived enough that they expire before the revocation check becomes relevant, or the resource server validates token status in real time. Refresh tokens are invalidated server-side on revocation, so the agent cannot obtain new access tokens after the revocation event.

Users should also be able to see a list of agents that have active delegations on their behalf and revoke any of them from a self-serve interface. This is the same model as OAuth app management in consumer applications, applied to enterprise agent deployments.

Quick audit: How long would it take from "we need to revoke this agent's access" to the agent actually losing access? Measure it.

9. The system is designed to fail closed, not fail open

The risk: Agents that encounter authorization errors default to retrying, using cached credentials, or falling back to broader access. These behaviors are often introduced during development to make the system easier to test and never removed. In production, they mean that a revoked token, a misconfigured permission, or a compromised credential does not actually stop the agent from acting.

What good looks like: Authorization failures are treated as definitive stops. A 401 from a resource server means the agent halts and surfaces the error to the calling system. It does not retry with a different credential, it does not fall back to a service account, and it does not continue with reduced functionality that bypasses the authorization check. The agent should be designed so that the safe behavior when authorization is unclear is to do nothing and ask for clarification.

This also applies to the authorization logic itself. Authorization decisions should come from deterministic policy enforcement, not from model output. The pattern to avoid is any variant of "if the model says access is permitted, allow it." Prompt injection can and will exploit that path.

  
# Wrong
if llm_response.says_access_is_ok:
    allow()

# Right
decision = authorization_service.evaluate(agent_id, user_id, action, resource)
if decision.allowed:
    allow()
  

Quick audit: What does your agent do when it receives a 401? What does it do when a permission check fails? Trace both paths through your codebase.

Using this checklist

The nine items above are not equally urgent for every system. If you are in early development, items 1 (per-agent identity), 2 (intersection rule), and 9 (fail closed) are the ones to get right first. They are structural: fixing them later requires rearchitecting, not patching.

Items 4 (short-lived audience-bound tokens), 6 (vaulted credentials), and 7 (audit log) are what enterprise buyers will ask about in security reviews. Get them in place before you start selling to larger organizations.

Items 3 (OIDC/OAuth separation), 5 (human approval gates), and 8 (immediate revocation) close the gap between "technically functional" and "production-grade." They are the difference between a system that works under normal conditions and one that holds up when something goes wrong.

WorkOS AuthKit handles the OAuth 2.1 flows, per-agent M2M credentials, RBAC, fine-grained permissions, audit logging, and native MCP server authentication described in this checklist. If you want to skip building the infrastructure yourself, the MCP Auth docs and M2M authentication guide are the starting points.

Further reading

OWASP Top 10 for LLM applications (2025) covers excessive agency (LLM06) and prompt injection (LLM01) in detail. RFC 8693 (token exchange), RFC 8707 (resource indicators), and RFC 9449 (DPoP) are the relevant IETF specifications for the token patterns described in items 3 and 4.