Get started

Give every agent action an identity you can verify

Auth51 gives every agent action its own scoped, short-lived token. This token is minted in your process and is cryptographically bound so a stolen one is useless. All of this is built on top of your existing workflow, so your tools stay untouched. Choose the path that matches your starting point.

Traditionally, API requests do not show which agent produced it, whether the agent still matches its registered instructions, or whether another process is replaying a leaked token. Auth51 adds a verifiable agent identity to each action. For the default setup, you only need to add a single import.

You will learn

Why an agent proves its identity by its fingerprint, not by a token it could leak
How one import enables agent identification without changing any underlying logic
How to review and approve an unregistered agent
Where to observe the authorization flow

The core principle

An agent's identity is a fingerprint of what it is: its system prompt and the tools it can call, rather than a secret it carries. The Auth51 client observes the model request, computes that fingerprint as a cryptographic hash, and compares it with the agents registered in your organization. A match identifies the agent without relying on a self-declared name. If no registration matches, Auth51 treats the agent as unregistered and sends it for review.

Shared API key

Calls made with the same long-lived credential have the same client identity. Anyone who obtains the token can present it until it expires or is rotated.

With Auth51

Each call carries a fresh token scoped to one action and bound to the agent's fingerprint and process-held key. Copying the token alone does not provide the key required to use it.

Quickstart

Create an API key

Sign in to the console. Auth51 creates an organization for you automatically. Create a key under Settings → API Keys, then add it to your agent's environment. The client reads the credentials when it is imported.

env

export AUTH51_CLIENT_ID=a51_live_...     # Settings → API Keys
export AUTH51_CLIENT_SECRET=...          # shown once

Note

The key is limited to your organization and its permitted scope envelope. It cannot approve escalations or access another tenant. On AWS, you can avoid a client secret by using keyless workload identity, which allows the agent to prove its IAM role.

Install and import

The import installs egress interception. On the agent's first model call, Auth51 identifies it from the request on the wire. The default discovery path does not require configure(), a wrapper around your code, or declared audiences.

shell

pip install auth51

your_app.py

import auth51        # ← that's it

# ...run your agent as usual.
run_your_agent()

Approve it in the console

The first time the agent runs, the client sends its observed identity, consisting of the system prompt, tools, and computed checksum, to your organization's Discovery inbox. Open Agents → Discovered, review the identity, and select Register to approve the agent. On the next run, Auth51 recognizes the registered agent and governs its actions.

console · your org

checkout-bot

checksum 3f9a…c21e · 2 tools

live

mint · payment:execute → api.acme.com

dpop-bound · exp 60s · agent checkout-bot

allowed

Note

The prompt and tools are sent to your Discovery inbox for review. They enter the Authority only after you approve the registration. Until then, the agent remains unregistered and the mint path fails closed.

Recap

Add the API key to the environment and import auth51.
The client derives the agent identity from its model request rather than from a declared name.
Review unregistered agents under Discovered, then approve the identities you want to register.
Auth51 recognizes and governs the registered agent on its next run.

Advanced & self-host

The steps above use the managed SaaS defaults. Use the following options when you need explicit configuration or a self-hosted deployment.

▸Deep dive · Configure in code instead of env (and self-host)

If you prefer explicit configuration or run your own Authority and Discovery services, call configure() once at startup. For an on-premises deployment, point the client to your servers. When you configure a custom Authority, the client does not fall back to SaaS Discovery.

startup.py

import auth51

auth51.configure(
    client_id="a51_live_...", client_secret="...",
    # self-host only — SaaS is the default:
    authority_url="https://authority.your-co.internal",
    discovery_url="https://discovery.your-co.internal",
)

▸Deep dive · Name an agent explicitly, or register from CI/CD

The client assigns a provisional name to a discovered agent from its prompt, and the console allows you to rename it during approval. To assign a name in code, wrap the run in with auth51.agent("checkout-bot"): .... To register agents before runtime, such as during deployment, POST their components to /v1/intent/register/agent. The console uses the same endpoint when you approve a discovered agent.

▸Deep dive · Enforce at your resource servers (audiences)

Discovery and identity use the default configuration. To mint intent tokens for calls to your resource servers, identify the Auth51-protected hosts through audiences or AUTH51_AUDIENCES. Install the Auth51 verifier on those services to validate the tokens.

Next steps

How it works→

Learn how intent tokens, DPoP binding, and non-amplification fit together.

Go keyless→

Use an AWS IAM role to authenticate an agent without a client_secret.

See an attack blocked→

Follow a live run and inspect the request that Auth51 refuses to authorize.