Reference

Specification & standards

auth51 isn’t a protocol you take on faith. What’s new — agent identity as a checksum, intent tokens minted per action, non-amplification across delegation — is written up as an IETF internet-draft. Everything underneath it is established OAuth, so if you know these RFCs you already know most of how auth51 works.

The auth51 protocol — the specification

The internet-draft is the normative spec: it defines the identity checksum, the intent-token profile, the MCP _meta propagation (Hop-A / Hop-B), and the non-amplification rules. The protocol overview is the readable companion to it.

Note

The canonical IETF datatracker link and the arXiv preprint are being finalized and will be linked here. (Placeholders until then — not yet public.)

Standards it builds on

These are the base standards auth51 composes. The draft above specifies how.

  • RFC 6749OAuth 2.0 Authorization Framework

    The client-credentials grant an agent uses to authenticate as its org.

  • RFC 8693OAuth 2.0 Token Exchange

    How a signed-in console session is federated into an org-scoped authority token.

  • RFC 9449Demonstrating Proof of Possession (DPoP)

    Binds an intent token to a key held in the agent process, so a copied token is useless.

  • RFC 7519JSON Web Token (JWT)

    The shape of an intent token on the wire — identity, scope, audience, expiry.

  • RFC 7517JSON Web Key (JWK)

    How a resource server fetches the authority’s public keys (JWKS) to verify a token.

The paper

A companion paper (arXiv preprint) covers the threat model and the evaluation behind the protocol. Link lands here on publication.

API, config, and scopes

Endpoint-level reference for the authority and the client — request shapes, the environment variables the client reads, and the scope envelope a customer key carries — is being written and will live in this section.