AI Auth Protocol

The missing identity layer
for AI agents.

The AuthFI AI Auth Protocol (AAP) is the AI-native way agents authenticate and get scoped, revocable, audited access. One coherent protocol — identity, an MCP server, a cross-app act-chain, human approvals, and tamper-evident audit — built on open standards, not a proprietary key bolted on the side.

Available on Pro and above. See pricing

Start free Read the docs

01 · Agent identity

A real principal, not a key in a .env.

The protocol starts by making each agent a first-class identity in your directory — ci-bot, support-agent, deploy-bot — instead of a long-lived secret copied into config and forgotten. Agents authenticate the way your people do: they present a signed client assertion (RFC 7523 JWT bearer) and receive a short-lived, audience-scoped token. There is no static password on the wire to leak, phish, or rotate.

  • Named, not anonymous: the subject is the agent, so every downstream decision and log line attributes the action to a principal you can name and revoke.
  • Keyless by construction: short-lived attestable credentials replace the plaintext secret — the same model that already governs your humans, applied to machines.
  • Scoped and revocable: grant exactly the tools and scopes an agent needs; revoke and every token it holds dies on the next exchange. One identity model for people and agents — the security review you pass once covers both.
client-assertion.jwt
POST /token  — RFC 7523 JWT bearer
  grant_type=urn:…:grant-type:jwt-bearer
  assertion=eyJhbGciOiJSUzI1Ni…

decoded claims
{
  "iss": "agent:ci-bot",
  "sub": "agent:ci-bot",
  "aud": "https://acme.authfi.io",
  "exp": "+5m"      ← short-lived
}

No standing secret — the agent signs an assertion and receives a token scoped to one audience, expiring in minutes.

MCP tool catalog agent=ci-bot
deploy.staging scope: deploy:staging
repos.read scope: read:repos
deploy.production human approval
cloud.delete_bucket not granted
Deploy to staging, yes — touch production or delete a bucket, no.

02 · The AuthFI MCP server

Agents connect over MCP. They never touch your apps directly.

The protocol speaks the Model Context Protocol, the open transport Claude, IDE assistants, and custom agents already use to discover and invoke tools. AuthFI runs the MCP server in front of your stack: an agent connects, lists tools, and sees only a curated catalog — and every tool carries its own scope. The agent reaches cloud, SSH, or your network exclusively through a tool its policy allows; there is no raw socket to your systems and no shared bastion credential to over-grant.

  • Per-tool scopes: an agent that can deploy.staging still can't reach deploy.production — or read a single byte it wasn't granted.
  • One mediated path: identity check, policy, approval, and audit all sit on the call, so least-privilege is enforced at invocation, not assumed at config time.
  • Standard transport: because it's MCP, you onboard a new agent by pointing it at the server — not by writing a bespoke integration per tool. See AuthFI for AI agents →

03 · Cross-app act-chain

One agent, acting across your apps — provably, every hop.

An agent rarely stops at one app. When it must act in another, the protocol doesn't replay the agent's token — it performs an RFC 8693 token exchange and mints a new, short-lived grant scoped to a single downstream audience. That grant carries a nested act claim — the IETF ID-JAG (oauth-id-jag+jwt) shape — so App B sees the original user and every intermediary that stood between, all signed by the IdP. Delegation is a verifiable claim, not a trust assumption.

  • The problem it removes: "confused-deputy" sprawl — apps re-using a god-mode token because there was no standard way to say who is acting for whom.
  • Audience-bound, minutes-lived: a stolen downstream grant is useless elsewhere and expires fast — the blast radius of any single hop is bounded by the exchange.
  • Provable delegation: the chain is reconstructable from the token alone, so an auditor can read "App A, via scheduler-bot, acting for Alice" straight off the signature. See Cross App Access →
id-jag.token · IdP-signed
{
  "iss":   "https://acme.authfi.io",
  "typ":   "oauth-id-jag+jwt",
  "sub":   "alice@acme.com",   ← the user
  "aud":   "app-b",
  "scope": "calendar.read deploy:staging",
  "act": {                  ← App A acted
    "sub": "app-a",
    "act": {                ← via an agent
      "sub": "agent:scheduler-bot"
    }
  }
}

user → App A → agent, as a single signed claim — scoped to one audience, expiring in minutes.

Approval required request #a91f
ci-bot wants to call deploy.production
scope deploy:production · target acme-web · requested 14:09:23
Approve Deny
The agent's tool call blocks until a human decides. No approval, no action.

04 · Human-in-the-loop

High-risk actions pause for a person.

Reading a record is one thing; deploying to production or deleting a bucket is another. Mark a tool high-risk and its invocation becomes a blocking gate: the MCP call suspends, an approval request is raised to the console or a notification, and the agent waits on the human's decision before the tool ever runs. This is the machine equivalent of a consent screen — the thing an agent can't click for itself — pushed back to a person who can.

  • Gate, don't guess: risk is a property of the tool, set once in policy, not a heuristic the agent is trusted to apply to itself.
  • Either decision is evidence: approve or deny, the outcome is written to the audit trail as a recorded event — an approval is itself a logged fact.
  • The payoff: autonomy where it's safe, a human checkpoint where it isn't — without rewriting the agent or the downstream app.

05 · Tamper-evident audit

Every action an agent takes is recorded — and provable.

Who, what, and when, for every single tool call and every cross-app hop. Each entry is hash-chained into a Merkle tree: an entry holds the hash of the one before it, so altering or dropping a record breaks the chain and the root no longer verifies. The log isn't just stored — it's tamper-evident.

Agent audit log Merkle-verified ✓
TimeAgentToolVerdict
14:02:11ci-botdeploy.stagingallowed
14:06:48support-agentdb.read_userallowed
14:09:23ci-botdeploy.productionapproval
14:12:05data-botcloud.delete_bucketdenied

When an auditor asks what your agents did last quarter, the answer is a query — and the chain proves nothing was edited after the fact.

Open, not a silo

Standards on the wire. No proprietary key on the identity layer.

Every layer of the protocol is a published standard, not a vendor format. Identity rides RFC 7523 JWT bearer; cross-app delegation rides RFC 8693 token exchange and the IETF ID-JAG grant; tool access rides the Model Context Protocol. And the whole shape is aligned with OpenID IPSIE — the enterprise-identity direction Okta, Microsoft and Ping are building toward. Open wire formats mean agents and apps you don't control can still join the chain.

  • No lock-in: the act-chain is a JWT any compliant verifier can read — you're not betting your agent fleet on one vendor's SDK.
  • One model, people and machines: the same keyless identity carries a human at a login screen and an agent calling a tool across your apps.
⌖Built on
RFC 8693 token exchangeRFC 7523 JWT bearerID-JAG grantModel Context ProtocolOpenID IPSIE
Identity · delegation · tool access · enterprise alignment — each an open spec, not an AuthFI invention.
Start free Read the docs

Get started

Ready to get started?

Free for 5,000 monthly active users. No credit card required.

Start free Read the docs