Skip to main content
A token is the credential you hand to an AI client. It identifies exactly one agent and carries a list of capability scopes you specified at issuance time. The client can only do what those scopes allow — read mail, use vault credentials, run a machine, or any combination — and nothing outside that list is reachable, no matter how the client asks. Tokens are the primary way you enforce least privilege in Agent Loadout.

​
Capability scopes

Every token is issued with one or more scopes chosen from the list below. A token without a scope has no access to that resource.
Issue the minimum scopes the client actually needs. A coding agent that only signs up for services and reads mail does not need vault:write or compute:run. A CI-fixer agent does not need wallet:read.

​
Issuing tokens

You can issue a token from the dashboard or programmatically with an org key.
1

Open the agent

In the dashboard, navigate to the agent you want to issue a token for.
2

Go to the Tokens tab

Click the Tokens tab on the agent’s page. Existing tokens and their scopes are listed here.
3

Create a new token

Click New token, give it a name (e.g. claude-code or codex-cli), and tick the capability scopes the client needs. The token value is shown once — copy it before closing the dialog.

​
Token boundaries

Tokens enforce hard boundaries that cannot be overridden at runtime:
  • A token can only reach the one agent it was issued for. It cannot read another agent’s mail, vault, or machines.
  • A token never has access to billing, organization settings, or member management.
  • Wallet and compute scopes are feature-flagged — even if you include wallet:read or compute:run on a token, those capabilities do nothing until the feature is enabled in your workspace.

​
MCP tokens (OAuth flow)

When a user connects an MCP client — Claude Code, Codex, Cursor, or ChatGPT — they go through an OAuth 2.1 authorization flow on the Agent Loadout site. The user chooses an agent, approves the scopes the client is requesting, and the platform issues an agent token. That token appears in the agent’s Tokens tab immediately and can be revoked there at any time. The MCP server URL for all clients is:
OAuth discovery documents:

​
Token lifetime

Access tokens are short-lived by design. MCP clients and well-behaved REST clients use the refresh token to obtain new access tokens transparently. You do not need to re-authorize every hour.

​
Revoking tokens

Revoke a token at any time from the Tokens tab on the agent’s page — click the token row and choose Revoke. Revocation takes effect immediately; any in-flight request using that token will receive a 401 response on its next call. You can also revoke through the standard OAuth revocation endpoint:

​
Organization keys

Org keys are a separate credential type used for management operations: creating agents, issuing tokens, and configuring the organization programmatically. They do not act as an agent and do not have email or vault access. Create them from Settings → Organization keys.
Org keys are for your backend, not for AI clients. Never put an org key in an MCP configuration — issue a scoped agent token instead.

​
Best practices

Issue a separate token for each client that connects to an agent — Claude Code, Codex, a cron job, a webhook receiver. If one client is compromised or behaves unexpectedly, you can revoke its token without affecting the others.
Only include the scopes the client actually uses. If you add compute:run to a token for a client that only reads mail, you have expanded the blast radius of a compromise with no benefit.
When you update a client’s system prompt, change its model, or hand it to a different team, issue a new token and revoke the old one. The token name in the Tokens tab tells you at a glance what each token is for.
Access tokens should never appear in application logs, CI output, or error reports. Use environment variables to pass tokens to clients and ensure your logging configuration excludes the Authorization header.