Architecture

Auth51 consists of a small set of components with distinct responsibilities. Those components map to the Zero-Trust roles defined in SP 800-207. This page provides the system map; the linked pages describe each component in detail.

Figure 1. The runtime topology. Control-plane calls for minting, proposing identities, and fetching keys are shown with faint lines. The accent line shows the data-plane call from the agent to the resource with its intent token. The checksum engine runs identically on the client and Authority.

Two planes, one trust root

The diagram separates the system into two planes. The control plane includes the interactions that support authorization decisions: the client runtime requesting a token from the Authority, an unregistered agent’s content going to Discovery, and a resource server fetching verification keys. The data plane is the request from the agent to a resource with an intent token. The Authority acts as the trust root but does not sit on this data path, so resource requests do not pass through it.

Zero-Trust roles

The Authority is the Policy Decision Point. The client runtime and the verifier are Policy Enforcement Points on opposite sides of the request. The client runtime proves identity and intent at the source, while the verifier checks them independently at the resource. The MCP proxy is a third enforcement point for the tool boundary.

▶Which components are on the request path, and which aren’t

Three components can touch a live request: the client runtime or MCP proxy at the source, and the verifier at the resource. The Authority is consulted when a token is minted, not on each downstream hop. Discovery remains outside the request path and receives an unregistered agent’s content out of band.

The checksum engine and contracts are shared code rather than services. The checksum engine keeps identity computation identical on both sides, while the generated contracts keep client types aligned with the Authority API.

Keep reading