Concepts

Discovery & the trust boundary

You won’t register every agent up front, and you shouldn’t have to. Someone spins up a new agent, a script gets copied, a prompt changes. auth51’s job is to notice the ones you haven’t approved and put them in front of you — without quietly trusting them, and without your prompts ending up somewhere they shouldn’t.

What happens when an unknown agent runs

The client identifies agents at the model call by matching their checksum against the ones your org has registered. When nothing matches, two things happen, on two separate paths:

First, the client sends a proposal to the discovery service — the agent’s observed identity: its system prompt, its tools, and the computed checksum. Second, when the agent tries to take a governed action, the mint is denied (it’s not a registered agent) and the authority records a reference: just the agent id and the checksum, nothing more.

In the console those two meet again, joined by checksum, under Agents → Discovered. You see the agent, read the prompt it was actually running, and click Register. From its next run on, it’s recognized.

The trust boundary: content and references travel apart

This is the part worth understanding. The authority — the component that mints tokens and holds your keys — never receives an agent’s prompt or tools until you approve it. All it ever sees for an unregistered agent is a reference: an id and a checksum. The content lives in the discovery service, a separate component, and stays there for your review.

Figure 1. An unregistered agent’s full identity goes only to the discovery service. Only a reference — id and checksum — crosses into the trusted core, so the authority never holds a prompt you haven’t approved.

Approval is the one path that moves content into the authority, and it’s a deliberate human action: clicking Register runs the normal registration, which is the sanctioned way for a prompt and tool set to enter the trusted core. Nothing an unregistered agent emitted gets there on its own.

▶Why a checksum is enough to join the two halves

The two paths never share the prompt, yet the console still lines them up. That works because the checksum is a deterministic fingerprint of the agent’s identity (see agent identity): the client computes the same value the authority recorded as a reference, and the discovery service stores the full identity under that same value.

So the join key is a hash both sides arrive at independently — not a shared copy of the sensitive content. The authority learns “an unregistered agent with checksum a7f3… tried to act,” and the console can show you what that checksum is by looking it up in discovery — without the prompt ever passing through the authority.

Watch out

Discovery is not permission. An unregistered agent’s governed calls are denied the whole time it sits in the Discovered list — fail-closed. Discovery makes the agent visible and easy to approve; it never makes it trusted.

Keep reading