API tokens

An API token is a long-lived credential that lets a tool outside AgentLeverage — an MCP client like Claude Code or Cursor — call your organization's tools without you signing in. It's the credential Connecting your agent assumes you already have.

Tokens are managed from Settings → API tokens (/app/<your-org>/settings/api-tokens), and only organization admins can create or manage them.

Creating a token

1. Go to Settings → API tokens and select Create token.
2. Give it a name (optional, but useful once you have more than one — e.g. "Claude Code – laptop").
3. Pick an expiry: No expiry, 30 days, 60 days, or 90 days.
4. Select Create token.

The token is shown once, immediately after creation, as a string starting with agl_. Copy it right away — closing the dialog is the only way out, and the plaintext value is never shown again anywhere in the app.

Using a token

A token authenticates as a bearer token in the Authorization header:

Authorization: Bearer agl_<your-token>

See Connecting your agent for the exact config for Claude Code, Cursor, Hermes, OpenClaw, Codex, and Claude Desktop.

A token is a separate principal from any human user, but it's an organization credential: it reads and cancels jobs across the organization it was created in, including ones you and your teammates started in the app. It never reaches another organization's jobs. Jobs the token creates are badged with the token's name in Job History so you can tell them apart from jobs you ran yourself.

That org-wide reach includes AI Inspector reports: a token can decrypt the reports of any AI Inspector run in the organization, including your teammates' plaintext conversation transcripts. This is intentional. Only admins can mint a token, and reading the organization's own conversation data is an admin capability. Mint tokens accordingly, and treat one as you would any credential that opens the whole account.

Token status

Each token in the list shows one of three statuses:

The list also shows when a token was created, when it was last used (or "never used"), and when it expires (or "no expiry").

Rotating a token

There's no in-place "regenerate" — rotate by:

1. Creating a new token.
2. Updating your MCP client's config with the new token.
3. Revoking the old token once the new one is working.

Doing it in that order avoids a gap where neither token works.

Revoking and removing

• Revoke — immediately stops the token from authenticating. Any client still using it gets 401 Unauthorized right away. This can't be undone.
• Remove — deletes the token's row from the list entirely. If the token is still active, revoke it first; removing an active token doesn't invalidate it any faster than revoking does.

Automatic revocation on offboarding

A token is tied to the admin who minted it. It is revoked automatically, without anyone clicking Revoke, as soon as that person can no longer hold an organization credential:

• They are removed from the organization. Their tokens in that organization are revoked. Tokens they minted in another organization they still belong to keep working.
• Their role changes away from admin in the organization.
• Their account is deleted. Every token they minted is revoked, in every organization.
• The organization itself is deleted. Every token for that organization is revoked, whoever minted them.

Automatically revoked tokens behave exactly like manually revoked ones: they stay in the list with a Revoked status, and any client still using one gets 401 Unauthorized. There is no un-revoke — if a revocation was wrong, an admin mints a fresh token.