---
title: "Trust and limits"
description: "The liability chain, provider verification, trust policy, receipts and abuse mechanics, the known gaps, and where to report a security issue."
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.

# 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

```text
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](/agent-identity/v1/validator/) reports conformance and attestation
verification separately.

## Assurance levels

| Level | What was checked |
| :--- | :--- |
| `domain` | Automated control of the origin through an HTTPS well-known file or a DNS TXT record. |
| `entity` | An operator reviewed legal-entity evidence: legal name, registry/VAT id, and official contact, in addition to the origin check. |

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:

| Policy | Verified | Unverified | Untrusted broker | Invalid or expired | Unavailable | Suspended |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| `allow` | proceed | proceed | proceed | proceed | proceed | proceed |
| `warn` | proceed | proceed + warning | proceed + warning | proceed + warning | proceed + warning | proceed + warning |
| `require` | proceed | `rp_unverified` | `rp_broker_untrusted` | `rp_attestation_invalid` / `rp_attestation_expired` | `rp_broker_unavailable` | `rp_suspended` |
| `block` | `rp_blocked` | `rp_blocked` | `rp_blocked` | `rp_blocked` | `rp_blocked` | `rp_blocked` |

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

| Proof source | Meaning |
| :--- | :--- |
| `rp_callback` | Tier 1: the provider posted the RP-signed receipt to Contract F. |
| `rp_signed` | Tier 2: the agent recorded the same RP-signed receipt through `identity_record_signup`. |
| `agent_self_reported` | No provider signature. Weaker and visibly marked. |
| `legacy_broker_signed` | A pre-v1.2 row. Historical and unverified. |

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](https://github.com/agentregistrar/spec/issues).
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](https://github.com/agentregistrar/spec/blob/v1.2.0/agent-identity-v1.md#17-trust-model-assurance-levels-and-policy): spec section 17.
- [Verification rules](https://github.com/agentregistrar/spec/blob/v1.2.0/agent-identity-v1.md#19-verification-rules): spec section 19.
- [Registry verification](/providers/guides/validate-and-register/): the recorded snapshot and badge rules.
- [Verify assertions](/providers/guides/verify-assertions/): the verifier and the provider credential check.
- [Receipt and context](/agent-identity/v1/receipt-and-context/): Contract E and proof sources.
- [Error codes](/reference/error-codes/): stable MCP and HTTP codes.
- [Scope boundaries](https://github.com/agentregistrar/spec/blob/v1.2.0/scope-boundaries.md): what the protocol must never absorb.
- [How it works](/start/how-it-works/): the mechanics these limits apply to.

Source: https://docs.agentregistrar.dev/start/trust-and-limits/index.mdx