Machine identity for AI agents: Which credential to issue and when

An AI agent walks into your API. What credential does it present?

That's not a rhetorical question anymore. Agents are calling endpoints, mutating records, and chaining tool calls in production. The auth industry is still working out the right identity primitive to use. We just shipped user-scoped API keys across the WorkOS API and widgets, and that puts us in an interesting spot to ask the harder question underneath all the AI-era positioning: when an agent acts on behalf of a user, what credential should it carry?

This article walks through the common agent scenarios in B2B workflows, which WorkOS credential primitive fits each one, and how to set it up.

The problem: Agents aren't users, but they aren't pure machines either

Traditional auth has two shapes. Humans get sessions, OAuth flows, and user-scoped tokens. Machines (backend services, integrations, cron jobs) get client credentials and short-lived JWTs. The split has worked for years.

Agents break it. An agent acting on behalf of a sales rep isn't the rep. It has a different lifecycle, gets spun up and torn down on demand, and may chain across multiple systems in a single "thought." It's also not a generic service account, because its blast radius needs to be bounded by what the rep is allowed to do. Issuing an agent the same org-scoped service credential a backend integration uses is how you end up writing the postmortem.

Most of the conversation around agent identity has split into two camps. One focuses on API surface: make credentials composable enough that agents use them like any other client. The other focuses on policy enforcement: embed governance into the decision loop so agents can't act outside defined boundaries. Both are real problems worth solving. Neither tells you what credential to actually issue the agent, or what properties that credential needs to have. That's the question this article is about.

The interesting questions are:

• Should an agent get a user-scoped key that inherits the human's permissions through delegation?
• Should it get an org-scoped key with permission scoping that bounds it to exactly what it needs?
• Or should it authenticate as a backend service, using the OAuth client credentials flow to receive short-lived JWTs that expire without explicit revocation?

The answer isn't "pick one." It falls out of the primitives you already have, if those primitives are good.

The three agent scenarios

Before picking a credential, it helps to be clear about what kind of agent you're actually running. Most agentic workflows in B2B products fall into one of three shapes.

• ‍A personal agent acting on behalf of a specific user. One human authorizes one agent to work on their behalf: drafting emails, updating CRM records, querying their data. The agent should only be able to do what that person can do. If the person is offboarded, the agent's access should disappear with them. Attribution matters: when the agent takes an action, it should be traceable back to the human who authorized it.‍
• A shared agent serving an org-wide workflow. The agent is not tied to any one user. It might handle support ticket routing, process incoming webhooks, or run a scheduled data sync across all accounts. Nobody owns it the way a personal assistant has an owner. But its access still needs to be bounded: it should have only the permissions it actually needs to do its job, not a full set of org credentials.‍
• A backend agent running in infrastructure you control. Some agents run as services rather than user-facing tools: a data pipeline agent, a scheduled sync, a backend workflow that chains calls across internal systems. In these cases the agent is effectively another service in your stack, and the teams deploying it likely expect an OAuth-based integration rather than a simple bearer token. Short-lived credentials that expire automatically are also preferable here, since the agent runs unattended and there is no human to notice if a long-lived secret leaks.

The primitives for each scenario

WorkOS has three credential primitives relevant to agentic workflows. None of them were designed exclusively for agents, but together they cover the scenarios above.

• ‍User-scoped API keys are keys that belong to an individual user rather than the organization. The user mints the key themselves, permissions are inherited from what they have been granted in WorkOS, and the key is listed under their profile. When the user is removed, their keys are revoked. This is the right primitive for personal agents: the attribution chain is built in, revocation is clean, and the blast radius is bounded by what the individual is allowed to do.‍
• Org-scoped API keys with permission scoping are organization-level keys with a narrowed permission set. Rather than carrying every permission attached to the org, you designate in the WorkOS dashboard which permissions are available for API keys, and a key carries only a subset of those. No individual owns the key, but the scope of what it can do is controlled. This fits shared agents that need to operate across the org without being tied to a person.‍
• M2M Applications issue short-lived JWTs using the OAuth 2.0 client credentials flow. The agent authenticates with a client ID and secret to receive a token that expires, rather than holding a long-lived opaque secret. Two properties make this the right fit for backend agents: the tokens expire automatically without explicit revocation, and because the credential is a JWT, it can be validated locally against a cached JWKS without a network call to WorkOS on every request. M2M Applications are created in the WorkOS dashboard rather than by end users through a widget.

All three primitives plug into the same WorkOS authorization graph. The same permission system that controls user access controls API key access, with no parallel model to maintain.

When to reach for each one

• ‍Personal agent, one human, delegation pattern. Reach for a user-scoped API key. The user mints it via the <ApiKeys /> widget, scoped to the permissions they want to grant the agent. Attribution is automatic: every API call carries the owning user's identity. Revocation is per-user, so offboarding the person revokes the agent's access without affecting any other integrations. The tradeoff is that you cannot restrict the agent below the user's permission level: if the user can issue refunds, so can the agent.‍
• Shared agent, org-wide workflow, no individual owner. Reach for an org-scoped API key with a narrowed permission set. Configure which permissions are available for API keys in the Authorization section of the WorkOS dashboard, then create a key scoped to exactly what the agent needs. Admins with the widgets:user-api-keys:manage-all permission have visibility across all keys in the org, so there is an oversight path even without per-user attribution. The tradeoff is that attribution to a specific human is not carried by the credential itself: if you need to know who deployed the agent, that link lives in your own application logic.‍
• Backend agent, service-to-service integration, OAuth expected. Reach for an M2M Application. The client credentials flow is the standard pattern for backend service authentication, and teams running infrastructure agents will typically expect it. The short-lived JWTs expire automatically, so you do not need to actively revoke credentials to limit exposure if something leaks. And because the credential is a JWT, your application can validate it locally against a cached JWKS rather than making a network call to WorkOS on every request, which matters if the agent is embedded in a latency-sensitive path. The tradeoff relative to API keys is that M2M Applications are created in the WorkOS dashboard rather than self-served by end users through a widget.

Setting it up

• ‍User-scoped keys. In the WorkOS dashboard, go to Authorization > Configuration and designate which permissions can be scoped to user API keys. Assign the widgets:user-api-keys:manage-self permission to the roles that should be able to mint their own keys, and widgets:user-api-keys:manage-all to admin roles that need org-wide visibility. Drop the <ApiKeys /> widget into your app with the scope prop set, and users can create and manage their own keys directly. Keys are shown in full only at creation; subsequent views are masked. The List user API keys and Create user API key API endpoints are available if you want to build a fully programmatic flow.‍
• Org-scoped keys with permission scoping. In the WorkOS dashboard, configure which permissions are available for API keys under Authorization > Configuration. When creating a key, select only the permissions the agent actually needs. Admins can audit all active keys across the org via the widgets:user-api-keys:manage-all permission.‍
• M2M Applications. Create the application in the WorkOS dashboard. The agent authenticates using its client ID and secret via the client credentials flow and receives a short-lived JWT. No additional widget setup is required.

One thing that matters regardless of which shape you pick

Whatever credential shape you use, agents can exfiltrate or replay credentials at machine speed, which makes storage discipline matter more than it does for human-held credentials. WorkOS API keys are hashed at rest with no reversible path back to the original value. If you are passing agent credentials through environment variables, logs, or anything that ends up in plaintext, the scope constraints on the credential do not protect you. Store them in a secrets manager, treat a leaked agent credential as a higher-severity incident than a leaked user password, and build rotation into your deployment pipeline from the start.