Agents & Trusted Issuers

An agent is an application that calls your APIs on a user’s behalf — an AI agent, or an MCP server acting as the signed-in user. It is the only application type allowed to perform a token exchange: trading the user’s token for a short-lived one that names both the user and the agent.

A trusted issuer is an external token issuer AuthAction accepts tokens from — your company’s identity provider, or the platform your agent runs on. Agents link to trusted issuers so they can authenticate with the token that platform already issues and rotates, instead of a stored client secret.

This page covers setting both up in the dashboard. For the protocol, SDK and token format, see Token Exchange for AI Agents.

Agent or API?

Not every MCP server is an agent.

You want to…	Set up
Protect an MCP server so MCP clients (Claude, Cursor) can connect	An API with dynamic clients allowed — see MCP Server
Let an MCP server or AI agent call your APIs as the user	An agent, with access to those APIs
Let that agent authenticate without a client secret	The agent, linked to a trusted issuer
Call an API as a service, with no user involved	A Machine-to-Machine application

An MCP server often needs both: it is protected as an API, and it is registered as an agent for the calls it makes onward on the user’s behalf.

Create an agent

1. In the dashboard, open Applications → Agents.
2. Click Create Agent and give it a name.

The agent’s details page has three tabs:

Tab	What it is for
Settings	Name, client ID and client secret
APIs	The APIs this agent may request tokens for. An exchange for any other audience is refused
Trusted Issuers	The workload tokens this agent accepts in place of its client secret

On the APIs tab, enable every API the agent calls on users’ behalf.

Trusted issuers

Trusted issuers are tenant-wide: register one once, and any number of agents can link to it. Manage them under Trusted Issuers in the sidebar, or add one directly from an agent while linking it.

Field	What it is
Name	A label for the list
Issuer	The iss claim in their tokens, e.g. https://acme.okta.com. Matched exactly, so copy it from the provider
JWKS URL	Where their public signing keys are published
Audience	Optional. Restricts which of their tokens are accepted
Subject claim	Which claim identifies the user. Defaults to sub

Nothing needs configuring on the issuer’s side. AuthAction only reads their public keys.

A trusted issuer has two uses:

• Your identity provider (Okta, Entra ID, Google Workspace…) — its users’ tokens can be exchanged directly, with no change to how anyone signs in.
• Your agent’s platform (Kubernetes, EKS, GKE, GitHub Actions…) — its workload tokens can authenticate an agent, once linked below.

Caution

Issuers shared by every customer of a provider — https://accounts.google.com, Microsoft’s /common/ endpoint — require an audience, or anyone with an account there would be accepted. AuthAction rejects them without one.

Link a trusted issuer to an agent

Linking tells AuthAction: a token from this issuer, with exactly this subject and audience, is this agent.

1. Open the agent and go to the Trusted Issuers tab.

2. Click Link Issuer.

3. Fill in:

   Field	What it is
   Name	Where the agent runs, e.g. payouts-agent (prod cluster)
   Issuer	The platform that mints the token. Use + Add new issuer if it is not registered yet
   Subject	The exact sub claim of the workload token
   Audience	Required. The audience the platform mints the token for. Comma-separated for more than one
   Additional claims	Optional. One key=value per line, each matched exactly — for when the subject alone is too broad

4. Click Link.

Subjects by platform

Platform	Issuer	Subject
Kubernetes / EKS	https://oidc.eks.<region>.amazonaws.com/id/<cluster>	system:serviceaccount:<namespace>:<name>
GitHub Actions	https://token.actions.githubusercontent.com	repo:<org>/<repo>:environment:<env>

Subjects are matched exactly; there are no wildcards. A GitHub Actions issuer mints tokens for every repository on GitHub, so a pattern such as repo:acme/* would let any repository in the organisation authenticate as your agent. Where the subject alone is too coarse, add claims — for example repository_owner=acme.

The audience is required. It stops a token minted for another service being replayed against AuthAction. Ask the platform for a token with a dedicated audience, such as authaction.

Each issuer and subject pair can be linked to one agent only, so a workload always resolves to a single agent.

Use it from the agent

With a link in place, the agent presents its workload token instead of a client secret:

import { createClient, workloadTokenFromFile } from "@authaction/node-sdk";

const client = createClient({
  domain: process.env.AUTHACTION_DOMAIN!,
  clientAssertion: workloadTokenFromFile("/var/run/secrets/authaction/token"),
});

const { access_token } = await client.exchangeTokenForUser(userToken, ["https://api.acme.eu"]);

See Without a stored secret for projecting the token in Kubernetes and the raw HTTP request.

Related

• Token Exchange for AI Agents
• MCP Server Authorization
• API Servers