Try the demo network

The demo network is a real, deployed test environment for agent-identity-v1. It has two brokers and three providers, so you can try the same-broker, cross-broker and unverified signup paths against the live broker.

Broker B and the three providers are simulated third parties operated by Agent Registrar. They are not independent adopters. The network is not a production service and has no provisioning, billing, SLA, uptime or endorsement claim. Nothing on this page is an adoption, production-readiness, safety, uptime or endorsement claim. Use only test data; the provider terms describe a test service only. Re-run the commands on this page before relying on a result.

Roles and trust

A verified provider publishes a provider verification credential (also called an RP attestation) in its discovery document. P1 and P2 have one; P3 does not.

P1, P2 and P3 share the registrable domain agentregistrardemorp.com. Their origins and audiences are separate, but they are not isolated from each other at the browser or DNS boundary. The landing page is a status page, not a network-wide provider directory.

Topology

The demo's human and agent are registered with A; your own A account follows the same path. P1 is registered with A, P2 is registered with B, and P3 is registered with neither. All three providers accept assertions only from A. A trusts B for the demo human through a policy row; A has no account with B, and B has no account with A.

Cross-broker sequence

A serves the agent and verifies the B attestation against B's metadata and JWKS. B does not mint an assertion in this flow. P2 verifies A's assertion against A's JWKS. P2 signs the receipt with its B-attested key and posts the receipt plus the exact attestation to A. A verifies the B attestation and key, then records the signup in the human ledger.

Try it as an agent user

You need a harness that supports remote MCP over OAuth and a browser for the consent step. There is no demo API key and no separate demo signup.

1. Connect your harness to https://agentregistrar.dev/mcp and complete the OAuth flow. If this is your first agent, follow Quickstart - use an agent.
2. Ask the agent to sign up at P1: https://verifiedprovider1.agentregistrardemorp.com. Review the terms before accepting. P1 is attested by A, so a normal A account should see verified and can record the A-attested receipt.
3. For P2, first make sure A trusts B for your account. Open the trust page, add https://agentregistrardemobroker.com to your broker trust list, and set P2 to require if you want a hard gate. Without that trust, warn proceeds with an rp_broker_untrusted warning and require blocks. Then ask the agent to sign up at https://verifiedprovider2.agentregistrardemorp.com. A verifies the B attestation and the receipt can be recorded with attestation issuer B.
4. For P3, use the default warn policy first. The signup proceeds with an unverified warning, P3 creates an account, and no receipt is issued; the agent can record a self-report only. Then set P3 to require and repeat: A blocks with rp_unverified. Set P3 to block to see P3 signups refused.

Policy outcomes for an unverified provider

Policy is per human and relying party; an agent inherits its human's policy in v1.2. Changing trust or policy does not deploy B or P2.

Where to see the record

• Ledger shows the acceptance, the exact accepted terms, provider, verification status, attestation jti and receipt.
• ToS and ledger explains what was accepted and who receives the receipt.
• The provider account and credential are issued by the provider, not by A.

Try it as a provider implementer

You do not need an account, SDK or shared secret to fetch discovery or verify an assertion. You cannot add your own provider or origin to B; provider onboarding is operator-only. The three discovery documents are public:

• P1 discovery
• P2 discovery
• P3 discovery

Discovery is served with Cache-Control: no-store, so a refresh shows a terms or attestation change on the next fetch.

Validate all three with the conformance validator. Run these from a checkout with the validator installed; see the validator.

# P1: A-attested
pnpm --silent validate:discovery \
  https://verifiedprovider1.agentregistrardemorp.com/.well-known/agent-signup.json \
  --json --probe-jwks --verify-attestation --require-attestation \
  --trusted-rp-broker https://agentregistrar.dev

# P2: B-attested
pnpm --silent validate:discovery \
  https://verifiedprovider2.agentregistrardemorp.com/.well-known/agent-signup.json \
  --json --probe-jwks --verify-attestation --require-attestation \
  --trusted-rp-broker https://agentregistrardemobroker.com

# P3: conformant, unverified
pnpm --silent validate:discovery \
  https://unverifiedprovider1.agentregistrardemorp.com/.well-known/agent-signup.json \
  --json --probe-jwks

P1 and P2 exit 0 with valid: true and a verified attestation. P3 exits 0 with valid: true and an unverified result. P1's rp_attestation is signed by A. P2's is signed by B. P3 has no rp_attestation. The difference is the issuer: the attestation comes from the broker that registered the provider, not from the broker that mints the agent assertion. The validator reports conformance and attestation verification separately; a valid document is not a safety or uptime claim.

Broker B documents

curl -sS https://agentregistrardemobroker.com/.well-known/agent-broker.json
curl -sS https://agentregistrardemobroker.com/.well-known/jwks.json

The metadata names the issuer, JWKS, attestation status endpoint, abuse endpoint, protocol versions and contact. Its shape is:

{
  "issuer": "https://agentregistrardemobroker.com",
  "jwks_uri": "https://agentregistrardemobroker.com/.well-known/jwks.json",
  "attestation_status_uri": "https://agentregistrardemobroker.com/api/broker/attestation-status",
  "abuse_endpoint": "https://agentregistrardemobroker.com/api/broker/report-abuse",
  "protocol_versions": ["agent-identity-v1"],
  "contact": "security@agentregistrardemobroker.com"
}

All URIs are same-origin. The live document is authoritative; the shape above is illustrative. The JWKS contains public Ed25519 keys only.

To read a signed status for the current P2 attestation, take the jti from the attestation payload and query B:

JTI="$(curl -sS https://verifiedprovider2.agentregistrardemorp.com/.well-known/agent-signup.json \
  | node -e 'let s="";process.stdin.on("data",d=>s+=d).on("end",()=>{const p=JSON.parse(s).rp_attestation.split(".")[1];console.log(JSON.parse(Buffer.from(p,"base64url")).jti)})')"
curl -sS "https://agentregistrardemobroker.com/api/broker/attestation-status?jti=${JTI}"

The response is {attestation_jti, status_jwt}. The status JWT names the attestation in sub, reports active, suspended or revoked, and expires in at most five minutes.

Synthetic receipt shape

A receipt is a compact JWS. The decoded claims below are illustrative only, use reserved example names, and are not a captured receipt. The wire form carries a signature from the provider's RP key.

{
  "iss": "https://verifiedprovider1.agentregistrardemorp.com",
  "sub": "agt_demo_example",
  "aud": "https://agentregistrar.dev",
  "jti": "srp_demo_example",
  "iat": 1794009600,
  "assertion_jti": "jti_demo_example",
  "service": {
    "audience": "demo-verifiedprovider1",
    "origin": "https://verifiedprovider1.agentregistrardemorp.com",
    "provider_name": "Demo Verified Provider 1",
    "provider_url": "https://verifiedprovider1.agentregistrardemorp.com",
    "account_id": "acct_demo_example",
    "attestation_jti": "rpa_demo_example",
    "key_id": "rp_example_1"
  },
  "agent": {
    "id": "agt_demo_example",
    "name": "demo-agent",
    "email": "demo-agent@agents.example"
  },
  "human": {
    "id": "hum_demo_example",
    "name": "Example Owner",
    "email": "owner@example.com",
    "verified": true
  },
  "tos": {
    "version": "demo-2026-11-07",
    "url": "https://verifiedprovider1.agentregistrardemorp.com/terms",
    "sha256": "sha256:<64 hex characters>"
  },
  "context": {
    "url": "https://verifiedprovider1.agentregistrardemorp.com/guide",
    "sha256": "sha256:<64 hex characters>"
  },
  "signed_up_at": "2026-11-07T00:00:00Z"
}

context is optional; when present it points to the provider's guide and is hash-pinned. A does not fetch the context URL; the agent does. A receipt carries no expiry: it is valid when iat and signed_up_at fall inside the named attestation's window. The provider may post the exact pair {signup_token, rp_attestation} to https://agentregistrar.dev/api/broker/signup-receipt. A verifies the receipt signature against the exact attestation snapshot, checks that window and dedupes the receipt. The agent can instead record the same receipt through identity_record_signup. The two paths carry the same proof; the ledger labels them rp_callback and rp_signed. A self-report without a provider signature is agent_self_reported, stays visibly weaker, and cannot overwrite a stronger receipt.

Do not post the synthetic example. A receipt without a valid signature and a matching attestation is rejected.

Rotation and renewal

Broker and provider key rotation, attestation renewal or expiry, suspension and rollback are operator drills. An anonymous visitor cannot run them. The operator records the evidence in a private test record; it is not published here. The observable behaviour is:

• an attestation is valid for 24 hours; a provider renews when 12 hours or less remain and never publishes an expired token;
• a new broker key is published with overlap, and a new attestation names the new kid; old attestations remain valid until expiry;
• A and the providers cache JWKS for at most five minutes, so a new kid can take one cache window to be seen;
• a suspended attestation is reported by B's signed status, and A blocks it under require or enforced warn; the status check may be cached for up to five minutes;
• old receipts remain verifiable through the attestation snapshot they name.

What you can and cannot test

What is real and what is disposable

Resetting a provider does not remove the acceptance or signup row in Broker A. Do not use sensitive personal data. The demo is not a storage or production service.

Feedback

Report a broken demo link or a wrong expectation in the docs issue tracker. Report a security issue to security@agentregistrar.dev; do not include live credentials, JWTs or personal data. Provider-specific conduct goes to the contact published in that provider's discovery document.

Next

• Specification v1.2.0 is the normative contract.
• Provider quickstart is the implementation path for a relying party.
• Agent quickstart connects a harness and registers an agent.
• Trust and limits explains policy, receipts and the known gaps.
• Validate and register covers the validator and the public registry.
• Demo landing page shows the live host status.