AuthFI for AI Agents
An identity for every agent.
Scoped. Revocable. Audited.
The Agent Auth Protocol: AI agents authenticate, get a real identity, and reach your tools, cloud, and servers only within policy — through the AuthFI MCP server. First-class agent auth, not an API key bolted on the side.
Available on Pro and above. See pricing
Agent identity
Every agent gets a real identity.
An autonomous agent that can deploy code or read a customer record deserves the same scrutiny
as a human who can. So AuthFI makes each one a first-class principal in your directory — ci-bot, support-agent, deploy-bot — not a static API key
copied into a .env file and forgotten. The agent authenticates the way your people
do: it exchanges its credential for a short-lived, attestable bearer token, then
presents that token on every tool call. There is no long-lived secret sitting in plaintext to
leak.
- Keyless, the same model humans get: short-lived, attestable credentials instead of a static key — the proof of identity expires on its own and is rotated, not stored.
- Scoped and revocable: grant exactly the tools and scopes the agent needs, pull them back in one click — and every token it holds dies the moment you revoke.
- Works with your MCP clients: Claude, IDE assistants and custom agents connect over the Model Context Protocol; the identity travels with the agent across every client.
- One protocol — the same keyless identity from a person at a login screen to an agent calling a tool.
{
"sub": "agent:ci-bot",
"iss": "https://authfi.io",
"token_type": "DPoP",
"scope": "read:repos deploy:staging",
"cnf": { "jkt": "0ZcOCO…attested" },
"iat": 1750498462,
"exp": 1750499062 // +10 min, then gone
}A short-lived sender-constrained (DPoP) token, scoped to named tools and bound to an attested key (cnf). No secret on disk — revoke the agent and the token can't be replayed.
The AuthFI MCP server
A gateway between your agents and your tools.
The Model Context Protocol speaks JSON-RPC: a client calls tools/list to discover what's
available, then tools/call to invoke one. AuthFI sits on that boundary as the MCP
server. Agents see a curated tool catalog, each tool carrying its own scopes, and can
reach cloud, SSH or your network only through tools their policy allows. Nothing behind it is exposed
directly.
Claude, IDEs, assistants
identity · policy · approvals
only within policy
agent=ci-bot scope=read:repos,deploy:stagingPer-tool scopes mean an agent that can deploy to staging still can't touch production — or read a single byte it wasn't granted. The catalog is the only surface; the model never holds raw cloud or SSH credentials.
The agent waits. No approval, no action — and the decision is written to the audit trail either way.
Human-in-the-loop
High-risk calls pause for a human.
Reading a record is one thing; deploying to production or deleting a bucket is another. Mark a tool
high-risk and the agent's tools/call blocks on a real human decision —
approve or deny, right from the console or a notification — before AuthFI ever forwards it
downstream. The model can't talk its way around the gate, because the gate lives in the server, not
in the prompt.
- Per-call policy, not per-session: the verdict is evaluated on the individual call — its agent, its tool, its scope and target — so one approval never becomes a standing grant.
- Act-chains stay attributable: when an agent calls a tool that calls another, the original principal and the approval that authorized it ride the whole chain — no anonymous hand-off.
- The payoff: autonomy where it's cheap, a human in the loop exactly where a mistake is expensive — and a recorded decision either way.
Tamper-evident audit
Every action an agent takes is recorded.
Who, what, and when — for every single tool call, allowed, denied, or held for approval. The agent audit log is hash-chained into a Merkle tree: each entry commits to the one before it, so an entry can't be quietly altered or dropped after the fact without breaking the root.
| Time | Agent | Tool | Verdict |
|---|---|---|---|
| 14:02:11 | ci-bot | deploy.staging | allowed |
| 14:06:48 | support-agent | db.read_user | allowed |
| 14:09:23 | ci-bot | deploy.production | approval |
| 14:12:05 | data-bot | cloud.delete_bucket | denied |
When an auditor asks what your agents did last quarter, the answer is a query — and it's provable.
Delegation & revocation
Granted on standards. Withdrawn instantly.
Agent access isn't a bespoke trust model — it's the OAuth 2.0 machinery you already audit, pointed at machine principals. A human or service delegates a narrow slice of authority to the agent, the agent redeems it for a token bound to named scopes, and the whole grant collapses the moment you revoke it.
Scoped delegation
An agent receives only the authority it was granted — expressed as OAuth scopes on named tools. RFC 8693 token exchange lets a caller swap its own token for a narrower, agent-specific one, so delegation never widens access.
Audience-bound tokens
Each token is minted for a specific resource — RFC 8707 resource indicators pin it to the tool it's meant for. A token leaked from one tool can't be replayed against another; the audience won't match.
One-click revocation
Revoke an agent and every credential it holds is invalidated at the server. Because tokens are short-lived and checked on each call, there's no long-lived secret to chase down across hosts — the access is simply gone.
Give your agents a real identity.
Scoped, revocable, audited access for every AI agent — through the AuthFI MCP server. First-class agent auth, on the same platform as your users, cloud, and servers.
Get started
Ready to get started?
Free for 5,000 monthly active users. No credit card required.