AI Agent Identity

Your agents stop sharing an API key and start acting on someone's behalf, with a short-lived credential that records who authorised every action.

Today

{
  "sub": "service-account"
}

With AuthAction

{
  "sub": "ops@acme.eu",
  "act": { "sub": "payouts-agent" },
  "exp": "5 minutes"
}

The person disappears

An AI agent calling your API usually carries a static service credential. It works, but the audit trail records the service, not the person who asked. The agent can do anything that key can do, for anyone, and nothing downstream can tell the difference.

AuthAction trades the user's token for a short-lived one naming both of them. The agent can only do what the person who asked it could already do, and every call it makes says who that was.

Read the guide

How it works

The model never holds a credential. Your MCP server or agent runtime does, and it exchanges the user's token for a scoped one before every call.

1. Someone signs in

Through your existing identity provider: Okta, Entra ID, Google Workspace, or AuthAction itself. Nothing about how your team logs in has to change.

2. The agent exchanges it

One SDK call trades their token for a five-minute credential scoped to a single API, carrying the user as the subject and the agent as the actor.

3. Your API can prove it

Verify it like any other token, then read the delegation chain: who authorised the action, and what carried it out.

One call in your agent

The user's token arrives with the request your MCP server is handling. Exchange it, then call onward.

  • Built on OAuth 2.0 Token Exchange (RFC 8693)
  • Works with your existing identity provider
  • Nested delegation for agents that call subagents
  • Tokens never outlive the session they came from
  • No stored secrets: agents authenticate with their platform identity
  • EU-hosted and EU-operated 
import { createClient } from '@authaction/node-sdk';

const client = createClient({
  domain:       process.env.AUTHACTION_DOMAIN,
  clientId:     process.env.AUTHACTION_CLIENT_ID,
  clientSecret: process.env.AUTHACTION_CLIENT_SECRET,
});

// userToken arrives with the request you are handling
const { access_token } = await client.exchangeTokenForUser(
  userToken,
  ['https://api.acme.eu'],
);

await fetch('https://api.acme.eu/payouts', {
  headers: { Authorization: `Bearer ${access_token}` },
});

Bring your own provider

Okta Entra ID Google Workspace Any OIDC provider

No identity migration

Adopting agent identity does not mean replacing how your people sign in. Register your provider once, issuer and JWKS URL , and the tokens your team already holds can be exchanged directly.

Nothing needs configuring on their side. AuthAction only reads their public keys, outbound. There is no callback URL, client secret, or application to register.

See the setup 
const client = createClient({
  domain: process.env.AUTHACTION_DOMAIN,

  // The Kubernetes token your platform
  // already rotates. No secret to store,
  // no secret to leak, no secret to rotate.
  clientAssertion: workloadTokenFromFile(),
});

Nothing left to leak

A delegated token is short-lived and attributable. A client secret sitting in an environment variable is neither: it is permanent, anonymous, and it is the credential an attacker actually wants.

So agents don't need one. If yours runs on Kubernetes, EKS, GKE, GitHub Actions or anything speaking SPIFFE, it authenticates with the identity that platform already issues and rotates. Register the workload once; store nothing.

How it works

Set up in the dashboard

Agents have their own section. Each one carries the APIs it may call and the platform tokens it accepts instead of a secret.

1. Create the agent

Under Applications → Agents. Only agents may exchange tokens: an ordinary machine-to-machine client cannot act for a user, even with a valid secret.

2. Choose its APIs

On the agent's APIs tab. An exchange for any API you have not enabled is refused, so an agent's reach is written down in one place.

3. Link a trusted issuer

On its Trusted Issuers tab: the platform, the exact subject, the audience. No wildcards, so a link never covers a workload you did not mean.

Is my MCP server an agent?

Only when it calls other APIs as the signed-in user. To let MCP clients such as Claude or Cursor connect to your server, protect it as an API with MCP Server Authorization. Many MCP servers need both. Read more.

Further reading

Related products

All products

In the docs

Full documentation

Give your agents an identity

Stop handing them a shared key. Start recording who asked. Completely free, no credit card required.

Get Started View Pricing