Security

Prompt injection, SSRF, replay, attestation and trust policy, key handling and the known limits of agent-identity-v1 v1.2.0.

The normative security rules are spec section 20, with agent consumption rules in section 8, verdicts in section 19, and issuer assumptions in section 10. This page summarizes the threat model for implementers. It does not weaken the specification.

Prompt injection and untrusted data

Discovery content, terms.text and the post-signup guide are data, never instructions.

Fetch discovery only when the user explicitly targets that service. Do not follow arbitrary links from another service's discovery document.
Treat terms.text as untrusted legal text. Never interpret it as agent commands. This is the prompt-injection defense.
After signup, treat the vendor guide as untrusted vendor documentation. The broker vouches for who signed up and what ToS was accepted, not for the guide's contents.
Reject a service if the document is missing, malformed, over the size cap, uses an unknown protocol, or does not allow the agent's issuer.
Never send an assertion to an endpoint that was not discovered from the same service origin, unless the user intent explicitly covers a separate API origin.
Never reuse an assertion across audiences, services, or after expiry.

SSRF rules

Do not fetch arbitrary internal addresses derived from a discovery document.
http://localhost and http://127.0.0.1 are allowed only in explicit development mode.
Every fetch of discovery, JWKS or a context URL applies a timeout, a bounded response size and a redirect limit. Redirects must stay on the same origin.
Fetching a discovered URL must not cause a side effect. Probing advertised endpoints, if done at all, must be non-destructive.
The broker validates context.url statically and does not fetch it during receipt ingestion.

Replay, resolve and acceptance lifetime

The jti check is an account-creation guard, not duplicate suppression. A repeated request for the same agent, account and service resolves idempotently.
assertion_replayed is reserved for a jti presented in a conflicting context: a different agent, account or service.
A broker may return the identical previously issued, still-unexpired assertion for an identical request. Acceptance is the durable legal event; assertions are short-lived proofs.
A relying party must not treat a fresh assertion that references an existing acceptance as a new consent.
v1 imposes no protocol-mandated re-acceptance interval. An acceptance remains the recorded consent for its terms.sha256 until the terms change or the human re-consents. A broker may impose its own documented policy.

See spec section 7.2 and section 7.3.

Provider verification and trust policy

The provider verification credential is optional. Absence is unverified, never invalid.
Check the attestation issuer against the trusted RP-broker list before any JWKS or metadata fetch. Never contact an untrusted broker.
Verify the attestation signature with the key selected by kid; require typ: agent-rp-attestation+jwt and alg: EdDSA. Never try all keys or accept none/HMAC.
Compare rp.origin to the origin of the discovery document actually fetched and rp.audience to discovery.audience. A mismatch is invalid, not unverified.
Check iat/exp with 60 seconds of skew. A bad signature, origin or audience is a verification failure; a fetch failure is unavailable.
Trust is policy, not cryptography. warn is advisory; require is the hard, broker-enforced gate; block never proceeds. Do not treat a registry badge as an endorsement or a safety rating.

Receipts and authenticated reporting

A v1.2 receipt has no exp. Ignore a legacy exp; never reject a receipt only because it passed.
Verify the receipt with the RP key named by service.key_id in the exact historical attestation named by service.attestation_jti. Never substitute the current attestation and never fall back to a broker key.
Compare iat and signed_up_at to that attestation's [iat, exp] window. Skew applies to current-time checks, not the historical window.
An abuse report is a current event: five-minute JWS, current attestation, broker trust only. Only a verified, receipt-linked report may apply a protective suspension pending review.
The registry and ledger "current" status are snapshots with checked_at; they are not live feeds.

Clock skew and assertion lifetime

Verify exp with at most 60 seconds of clock skew.
Keep assertion lifetimes short. The recommended maximum is 5 minutes; the broker default is 5 minutes.
Re-fetch discovery immediately before signup, or honor its cache lifetime. Never reuse a stale ToS hash.

Keys and JWKS

Assertions use Ed25519 (EdDSA) signatures with a stable kid.
Every issuer origin must publish GET <iss>/.well-known/jwks.json over HTTPS, with application/json, and make it safe to cache.
Resolve issuer keys only from the issuer's canonical JWKS. Never accept a jku or x5u header that points at an arbitrary host.
Require the JOSE header alg to be EdDSA and select the key by kid.
v1 does not define a key-rotation protocol. The fixed JWKS path and stable kid are the contract. An unknown kid is a reason to refresh the issuer's JWKS, not a reason to accept an unverified signature.
The discovery document itself is not signed. Trust comes from TLS, the issuer allowlist, issuer-hosted JWKS and the signed assertion. The optional rp_attestation is a signed statement about the provider, not a signature over the document.
Attestation-signing public keys stay in the RP broker's JWKS for at least 30 days after the last attestation they signed expires, so historical receipts remain verifiable. An unseen old receipt after that window is attestation_unavailable.

Other checks

Issuer spoofing: exact iss allowlist matching and issuer-origin JWKS only.
Audience confusion: one exact, stable aud per service.
ToS substitution: the agent recomputes the hash from terms.text; the relying party rejects stale or mismatched hashes.
Discovery tampering: TLS plus the signed assertion; the discovery document is a parameter document, not a trust anchor.
DoS: response size limits, timeouts, caching and rate limiting.
Privacy: no human PII or secrets in the public discovery document.
Cache poisoning: short cache lifetimes and revalidation before signup.

Known limits

Verification is optional and not a safety review. A conformant provider can omit the credential. allow/warn may proceed; require refuses. A domain credential proves origin control, not good conduct; entity adds reviewed legal-entity evidence, not honesty.
Cheap discovery conformance. A valid document is not evidence of the service's security, uptime or product quality.
Revocation and suspension scope. They are enforced by the broker at assertion-minting time. They suspend or revoke the broker identity; they do not delete accounts a provider already created.
No abuse prevention. The protocol does not prevent abuse. It records who acted, for which human, under which terms, with what proof.
No signed discovery document. TLS and the assertion are the trust path; the optional attestation is a separate provider identity statement.
No KYC. human.verified means a verified email address, not a verified legal identity.