---
title: "Try the demo network"
description: "Try a deployed two-broker, three-provider test network for same-broker, cross-broker and unverified agent signups."
image: "https://docs.agentregistrar.dev/og/docs-default.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.agentregistrar.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

> **What is real**
>
> A demo signup creates a real acceptance record under your human identity in
> Broker A. The provider account, credential and provider-side data are test-only
> and may be reset.

## Roles and trust

| Host | Role | Registered with | Attestation | What to expect |
| :--- | :--- | :--- | :--- | :--- |
| [Broker A](https://agentregistrar.dev) | Human/agent broker | Home broker | n/a | Your human identity, agent, policy and ledger |
| [Broker B](https://agentregistrardemobroker.com/.well-known/agent-broker.json) | RP broker | RP-only demo broker | B issues the P2 attestation | Metadata, JWKS and signed status; it does not register agents |
| [P1](https://verifiedprovider1.agentregistrardemorp.com/.well-known/agent-signup.json) | Verified provider | A | A-signed | `verified` in A; an A-attested receipt can be recorded |
| [P2](https://verifiedprovider2.agentregistrardemorp.com/.well-known/agent-signup.json) | Verified provider | B | B-signed | `verified` after you trust B; a B-attested receipt can be recorded |
| [P3](https://unverifiedprovider1.agentregistrardemorp.com/.well-known/agent-signup.json) | Unverified provider | Neither | None | Unverified; `warn` proceeds with a warning, `require` blocks, `block` never proceeds |
| [Landing](https://agentregistrardemorp.com) | Demo status page | None | None | Host links and live status; no protocol identity |

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](/start/quickstart-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](https://agentregistrar.dev/trust), 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.

> **Trust is local policy**
>
> Trusting B does not make every B statement authoritative, and it does not make a
> provider safe. `verified` means the attestation was verified under your policy,
> not that the service is trustworthy.

### Policy outcomes for an unverified provider

| Policy | P3 result | What it proves |
| :--- | :--- | :--- |
| `allow` | Proceeds silently, no receipt, self-report only | Not a verification control |
| `warn` (default) | Proceeds with an unverified warning, no receipt, self-report only | Advisory only |
| `require` | Blocked with `rp_unverified`; no account, assertion or acceptance | The hard gate |
| `block` | Blocked with `rp_blocked`; applies to verified providers too | Never proceeds |

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](/portal/ledger/) shows the acceptance, the exact accepted terms,
  provider, verification status, attestation jti and receipt.
- [ToS and ledger](/agents/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](https://verifiedprovider1.agentregistrardemorp.com/.well-known/agent-signup.json)
- [P2 discovery](https://verifiedprovider2.agentregistrardemorp.com/.well-known/agent-signup.json)
- [P3 discovery](https://unverifiedprovider1.agentregistrardemorp.com/.well-known/agent-signup.json)

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](/agent-identity/v1/validator/).

```bash
# 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

```bash
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:

```json
{
  "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:

```bash
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.

```json
{
  "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

| You can test | You cannot test |
| :--- | :--- |
| Discovery conformance, Broker B metadata/JWKS/status, and A- or B-attestation verification for P1/P2/P3 | An agent registered with B; B is an RP broker only |
| Same-broker signup at P1 with a real A agent | Provider-to-provider isolation; P1/P2/P3 share a registrable domain |
| Cross-broker signup at P2 after trusting B | Multiple third-party brokers, trust precedence or federation governance |
| Unverified `warn`/`require`/`block` behaviour at P3 | Anonymous admin actions, key rotation or destructive lifecycle drills |
| Receipt ingestion, dedupe, ledger status and the [abuse-reporting contract](/providers/guides/abuse-reporting/) | Signed abuse reports, which require a provider signing key; production uptime, support, SLA or a security review of a provider |
| Assertion verification with public JWKS, no account or SDK | A provider catalog, provisioning, billing or infrastructure resale |
| P1/P2/P3 terms hashes and P1/P2 context hashes | Multi-label public-suffix domains such as `co.uk` or `workers.dev` |

## What is real and what is disposable

| Item | Status |
| :--- | :--- |
| Acceptance and signup rows in Broker A | Real records under your human identity; not reset by the demo |
| Broker A human, agent, trust and policy rows | Real for your account; the demo uses a dedicated test identity |
| Broker B and provider-side data | Test-only; each host can be reset without touching A |
| Provider-side account, credential and receipt state | Test-only; may be reset and grants no production access |
| Discovery, metadata, JWKS and status documents | Public and live; fetch and validate them |
| Administrative credentials, private signing keys and private records | Never public |

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](https://github.com/agentregistrar/docs/issues). 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](https://github.com/agentregistrar/spec/blob/v1.2.0/agent-identity-v1.md)
  is the normative contract.
- [Provider quickstart](/providers/quickstart/) is the implementation path for a
  relying party.
- [Agent quickstart](/start/quickstart-agent/) connects a harness and registers
  an agent.
- [Trust and limits](/start/trust-and-limits/) explains policy, receipts and the
  known gaps.
- [Validate and register](/providers/guides/validate-and-register/) covers the
  validator and the public registry.
- [Demo landing page](https://agentregistrardemorp.com) shows the live host
  status.

Source: https://docs.agentregistrar.dev/demo/index.mdx