Open Agent Trust Registry

The open root-of-trust for agent identity on the internet. A public, federated registry of trusted attestation issuers — the agent runtimes authorized to vouch for agents acting on behalf of humans. Services verify agent attestations against this registry to determine if the issuing runtime is legitimate. This acts as the Certificate Authority trust store for the agent internet.

The Problem

How can a website know if an AI agent is actually allowed to do something on your behalf?

Right now, if you log into a website like your bank, you use a password or FaceID. The bank knows it’s you. But if you tell an AI agent, "Go pay my internet bill," the agent needs a way to prove to the bank, "I am an authorized agent acting for my user."

To do this, the agent presents a digital "ID badge" (called an Attestation). But anyone can fake a digital ID badge. The bank needs a way to verify that the ID badge was issued by a trustworthy organization (like a reputable developer, platform, or runtime) and not by a hacker.

This registry is the master list of trustworthy badge issuers. It acts just like the systems that power the padlock icon in your web browser (Certificate Authorities). When a website sees an agent's badge, it checks the Open Agent Trust Registry to see if the issuer of that badge is on the approved list.

How It Works (In Simple Terms)

The Wax Seal (Ed25519 Cryptography)

An organization creates a Private Key (a secret, like a signet ring) and publishes their Public Key to our registry (the imprint the ring leaves in wax). When they issue an ID badge to an agent, they stamp it with their Private Key. When a website gets the badge, they look at the stamp, check our registry for the public imprint, and if they match, the badge is authentic.

Permissionless Registration

Organizations register by cryptographically proving they own their website domain. Our automated CI pipeline instantly adds them to the registry. No human gatekeepers, no bias.

Threshold Governance

To prevent any single person from maliciously altering the registry, the master list is secured by a cryptographic lock requiring 3 out of 5 keys to open. We distribute these 5 keys to independent ecosystem leaders. Every revocation requires mathematically provable consensus.

Zero-Trust Mirror Servers

A core feature of the registry is that the manifest.json is cryptographically signed. Because of this, anyone can host a registry mirror server without compromising security.

If a malicious actor hosts a mirror server and tries to secretly add a hacker to the list, the cryptographic signature of the file breaks. When a website downloads that list, the SDK will instantly detect the invalid signature and reject the entire file.

Mirror servers are "zero-trust messengers"—they can distribute the data, but they cannot fake it.

Design Principles

Open from day one

MIT or Apache 2.0 licensed. No proprietary extensions, no dual licensing.

No single point of control

Multiple mirrors, multi-party signing, governance designed to scale.

Verify locally

Services never need to call a central server per-request. Download the registry, verify locally.

Small & auditable

Hundreds to low thousands of entries. Any human can read the full registry in minutes.

Cryptographically Verifiable

Every registry state is signed. Every change is attributable. Tamper-evident by construction.

Quickstart

For Runtime Operators (Registering)

Terminal — Register

# 1. Generate an Ed25519 keypair for your runtime
$ npx @open-agent-trust/cli keygen --issuer-id my-runtime

# 2. Create your registration JSON file:
$ npx @open-agent-trust/cli register \
    --issuer-id my-runtime \
    --display-name "My Agent Runtime" \
    --website https://my-runtime.com \
    --contact [email protected] \
    --public-key <PUBLIC_KEY_FROM_STEP_1>

# 3. Domain verification (pick one):
#
#    PREFERRED — Add to your agent.json identity block:
#    "identity": { "oatr_issuer_id": "my-runtime", "public_key": "<PUBLIC_KEY>" }
#
#    FALLBACK  — Host a standalone file:
#    https://my-runtime.com/.well-known/agent-trust.json
#    { "issuer_id": "my-runtime", "public_key_fingerprint": "<KID_OR_PUBLIC_KEY>" }

# 4. Generate proof of key ownership:
$ npx @open-agent-trust/cli prove \
    --issuer-id my-runtime \
    --private-key my-runtime.private.pem

#    This creates registry/proofs/my-runtime.proof

# 5. Submit your registration via the CLI:
$ npx @open-agent-trust/cli submit \
    --issuer-id my-runtime \
    --github-token <GITHUB_TOKEN>

#    CI verifies: valid key + proof-of-ownership + domain verification
#    If all pass → auto-merged. No human approval needed.

Domain verification proves you control the website you declared. The preferred method is adding oatr_issuer_id to your agent.json identity block — the CI checks your agent.json first for domain verification. As a fallback, you can host a standalone file at /.well-known/agent-trust.json containing your issuer_id and a public_key_fingerprint. The CI accepts four fingerprint formats: the kid from keygen, the base64url public key, the SHA-256 hash of that public key in base64url, or Trunc16(SHA-256)in hex. Same model as Let's Encrypt.

Proof-of-key-ownership proves you control the private key. Generate it with the CLI using prove, which writes registry/proofs/<issuer>.proof. Then use submit to branch, commit, and open the registration PR automatically. The CI verifies the proof signature against your submitted public key. See the full registration spec for details.

For Services (Verifying)

Terminal — Verify

# 1. Issue a test attestation:
$ npx @open-agent-trust/cli issue \
    --issuer-id my-runtime \
    --kid <KID> \
    --private-key my-runtime.private.pem \
    --audience https://my.service.com

# 2. Test verifying that attestation against the registry:
$ npx @open-agent-trust/cli verify <JWT_STRING> --audience https://my.service.com

# 3. Integrating directly into your application:
$ npm install @open-agent-trust/registry

Looking for API provider identity (Tier 3)?

The Trust Registry proves that agent runtimes are legitimate. If you want to prove your API's domain identityinstead, that's Tier 3 in the agent.json spec. Tier 3 uses the same keypair from the CLI above but adds it to your agent.json and DID document.

Becoming Tier 3: Step-by-step guide →

Note for macOS users: Do not double-click .private.pem files. macOS will try to import them into Keychain Access, which is not what you want. Always use cat yourfile.private.pem in the terminal to view your key.

Relationship to agent.json

This registry is highly complementary to the agent.json standard. They serve different but mutually reinforcing purposes:

agent.json
Hosted by the Agent owner on their domain. Declares exactly what the agent is capable of doing, its API integrations, and its operator.
manifest.json
Hosted centrally by this Open Agent Trust Registry. This is the curated list of Trusted Runtimes (Issuers) authorized to execute and attest to those agents.

By combining the two, a service can guarantee both what the agent intent is (via agent.json) and who is securely authorizing the execution (via the Open Agent Trust Registry).

New in agent.json v1.4: The identity.oatr_issuer_id field consolidates trust discovery. Previously, verifying a domain required 4 separate fetches (agent.json, agent-trust.json, DID document, registry manifest). With v1.4, this is reduced to 2 (agent.json + DID document). The OATR CI now checks agent.json first for domain verification.