Protocol flows

Registration

Everything auth51 enforces at runtime is checked against something registered ahead of time. Registration is that one-time step: it establishes the client, each agent’s identity, and the workflows they run, so that later a mint can be a decision rather than a guess. It’s built to be automated: run from a deploy step or CI/CD, not clicked through by hand.

Figure 1. Registration in three exchanges: the client, then each agent (with its checksum and PoP public key), then any workflows. Requests are solid; the Authority’s confirmations are dashed.

Client registration

First the application registers as a client. The shim computes a checksum of the client and sends a registration request; the Authority verifies the authorization grant, stores a record mapping the client_id to that checksum and its granted scopes, and returns the id. This is ordinary OAuth client onboarding. The agent-specific part comes next.

Agent registration

Then each agent registers as its own identity. The shim assembles the agent’s signature (its prompt, tool interfaces, and configuration), computes the checksum, and sends it along with the agent id and the agent’s proof-of-possession public key. The Authority recomputes the checksum from the submitted signature rather than trusting the client’s value, stores the mapping of agent id, checksum, granted scopes, granted intents, and PoP key, and returns a registration_id, the handle used later to revoke the agent wholesale.

Note

The client checks its own shim’s integrity before it registers anything. If the shim has been tampered with, registration is refused. A compromised enforcement point can’t quietly enroll agents.

Workflow registration

Separately, workflows are registered: the plans agents run, each a set of steps with their scopes, dependencies, and approval gates. A workflow can be registered by hand or, more often, inferred from the agent’s source and tools and registered from CI/CD. The Authority stores each workflow so a later run can be validated step by step.

▶Why registration is a governance boundary

Registration is the one sanctioned path by which an agent’s identity enters the trusted core. Everything downstream (minting, verification, discovery) assumes that what’s registered was reviewed and approved. So an unregistered agent doesn’t just fail quietly: its content is routed to discovery for review, and its mint is denied until a human approves it into the registry.

Re-registering the same agent id with a different checksum doesn’t overwrite. It creates a new, versioned record, so a prompt or tool change is tracked rather than silently accepted. draft-goswami-agentic-jwt §5.4 · §6.2

Keep reading