Trust and limits

The model is simple to state and easy to over-read. A verified human is accountable for an agent; the broker proves that and records what was accepted. A provider may additionally publish a broker-issued provider verification credential so an agent can check who it is before signup. That check records identity, not safety, and it does not police what an agent does after signup.

The liability chain

verified human owner
  -> master delegation agreement (one per human)
  -> delegated ToS acceptance (exact text, hash, timestamp)
  -> signed assertion (agent, human, acceptance)
  -> optional provider verification credential (RP attestation)
  -> provider account (created or resolved by the provider)

Each link is recorded. The human signs the master agreement once. Every service acceptance is a separate durable event with the terms URL, the terms hash and the master agreement version. The assertion carries the acceptance forward, so the provider does not have to trust a self-declared claim.

What the chain does not do: it does not transfer liability to the broker, and it does not make the provider a party to the master agreement. The provider's own terms govern the provider's account.

Assertion verification is permissionless

Anyone can verify a Contract A assertion against the human broker's public JWKS. No account, SDK, shared secret, or broker call is required. This stays true in v1.2 and is the base conformant flow.

A provider account is a different thing. It is required only to be a verified provider, issue authenticated receipts, or report abuse with standing. It is not required to accept assertions.

What provider verification adds

A provider may publish an optional rp_attestation in its discovery document. The public term is provider verification credential: a compact JWS issued by the provider's broker (Broker B) that binds:

• the provider's canonical origin;
• its discovery audience;
• its provider identity and contact;
• an assurance level (domain or entity);
• its public signing keys.

An agent or broker verifies it locally against Broker B's JWKS, checking the signature, typ, alg, kid, iat/exp with 60 seconds of clock skew, rp.origin against the origin of the discovery document actually fetched, and rp.audience against discovery.audience. The trusted-Broker-B check happens before any JWKS fetch. There is no per-signup call to Broker B.

The credential is optional. A conformant discovery document without it is unverified, never invalid. Absence, an expired credential, a bad signature, an untrusted broker, and an unavailable broker are different results, and the validator reports conformance and attestation verification separately.

Assurance levels

Both levels count as verified for v1.2 policy. The level is recorded and displayed. It is not a ranking and there is no enhanced level.

Trust is policy, not cryptography

A valid credential says "this broker vouches for this origin and audience at this time". Whether that broker is trusted is a local policy decision. Trust is not transitive: trusting Broker B to attest a provider does not make B's other statements authoritative, and it says nothing about the provider's safety, uptime, solvency, or conduct.

The broker default plus the human owner's overrides resolve trust. A human can mark a broker trust or distrust; distrust wins. Agents inherit their human's policy in v1.2; there is no per-agent trust list.

Policy is separate from verification status:

warn is advisory: the call proceeds with a warning. It is not a security control. require is the hard, broker-enforced gate and rejects agent_supplied_discovery. block never proceeds. The default policy is warn.

Provider verification is identity, not safety

"Verified" means a broker checked an origin and, at entity level, reviewed legal-entity evidence; policy accepted the credential. It does not mean safe, approved, endorsed, audited, trustworthy, solvent, or reliable. A verified provider can still misbehave. Verification reduces impersonation risk; human reports, expiry, revocation, and policy remain the controls.

The registry shows the recorded status at checked_at and labels it a snapshot. It is not a live status feed and a listing is not an endorsement. The live VaporCloud reference entry carries a domain-level snapshot checked on 2026-10-26; it records the broker's identity check, not product safety or conduct.

Receipts and proof sources

A v1.2 signup receipt is signed by the provider's own key, named by service.attestation_jti and service.key_id. It carries no exp: a receipt is a historical fact. The receipt is valid when iat and signed_up_at both fall inside the named attestation's validity window, even if the broker ingests it after the attestation expires. The broker keeps the verified attestation snapshot and never substitutes a newer attestation or a broker-signed fallback.

There are four proof sources:

Tier 1 and Tier 2 carry the same proof. A self-report is not verified. exp on a legacy receipt is ignored.

Authenticated abuse reporting

A provider with a current attestation can send POST /api/broker/report-abuse with {rp_attestation, report}, where report is a compact JWS with a five-minute freshness window. The broker checks broker trust before any JWKS fetch, then verifies the report signature with the named key. A report is verified only when it is linked to a signup with proof_source rp_callback or rp_signed and a verified attestation. Only a verified, receipt-linked report can request a protective suspension pending operator review, and every accepted report opens a case.

An unlinked, self-reported, or legacy-linked report is unverified: it opens a case but does not suspend. Unauthenticated legacy posts get 401 unauthenticated_report. Reporting from a human about a provider is portal-only (POST /api/broker/report-provider) and updates that human's trust/policy; it does not adjudicate a dispute.

Status at signup, current status, and revocation

The ledger shows two separate things:

• status at signup: the verification event recorded for that signup;
• current status: the latest recorded status for the same origin and audience, with local overrides.

Current status is historical, not a live query. It carries checked_at. Local provider suspension/revocation, local attestation suspension/revocation, or snapshot expiry can override the label. The broker metadata advertises a signed attestation_status_uri; local verification does not require it, and an enforced check may consult it with a cache of at most five minutes.

Revocation affects new identity_signup/identity_prove calls and identity-bound tool calls. It does not delete a provider account, invalidate an assertion already handed over (which expires within five minutes), or reclaim provider credentials. A human kill switch sets revoked. An operator protective action sets suspended; the human cannot silently clear a suspension.

Known gaps

These are limitations of agent-identity-v1 and of this broker. They are stated here so no page has to soften them.

1. Unverified providers still exist. A conformant provider can omit the optional credential. allow/warn may proceed; require refuses. Choosing a provider is still a trust decision.
2. Verification is not a safety review. A malicious provider can obtain a domain-level credential by controlling an origin. entity adds reviewed legal-entity evidence, not honesty or product quality.
3. The assertion discloses contact details. Even with verification, the assertion gives the provider the agent address, the human's name and email, and the acceptance facts.
4. Conformance is cheap. The validator checks document shape and encoding, not intent, security posture, or business legitimacy.
5. Revocation is a broker control. It cannot delete an account, invalidate a live assertion, or force a provider to stop serving the agent.
6. Provider enforcement varies. A provider may skip a check or never call the abuse endpoint. The protocol defines checks; it cannot make a provider run them.
7. The broker is a single point of failure for minting. If the broker is unavailable, no new assertions can be minted. Providers and existing accounts are unaffected.
8. Email delivery is in the critical path. The acceptance receipt, human forward, and provider verification mail depend on mail delivery. A failed ledger dispatch is retryable; the acceptance is already recorded.
9. human.verified is verified email, not KYC. Two broker accounts with different emails are two principals. The broker cannot merge them.
10. No credential custody. The broker cannot recover a provider credential, because it never stores one. Recovery is the provider's path.

What we do not claim

• No SOC 2, ISO 27001 or equivalent attestation.
• No uptime SLA or availability target.
• No adoption, customer-count or revenue figures.
• No claim that the protocol prevents abuse, enforces revocation at a provider, or makes an agent or provider trustworthy.
• No claim that verification means safe, approved, endorsed, or audited.
• No legal advice. The master agreement and the provider terms are the legal documents; this site explains mechanics.

Security and abuse contacts

Report a vulnerability in the broker, the protocol or this documentation to security@agentregistrar.dev, the address published in the site footer. Reports are handled on a best-effort basis; there is no bug bounty and no guaranteed response time. Do not include live credentials, JWTs or personal data in a report.

For documentation and specification defects, open an issue on the specification repository. For provider-side abuse, use the provider's own contact and, where it supports it, the broker abuse endpoint.

Read the contract

• Trust model, assurance levels, and policy: spec section 17.
• Verification rules: spec section 19.
• Registry verification: the recorded snapshot and badge rules.
• Verify assertions: the verifier and the provider credential check.
• Receipt and context: Contract E and proof sources.
• Error codes: stable MCP and HTTP codes.
• Scope boundaries: what the protocol must never absorb.
• How it works: the mechanics these limits apply to.