Verify evidence, not permission

A passport identifies an agent and describes its authority. A decision receipt records what Passport decided about one request. Neither is a universal pass to execute a new action.

Read an artifact

Open Verify and paste a passport, decision receipt, capability credential, or signed audit head. Use discovery at /.well-known/passport.json to inspect issuer keys. That endpoint is intentionally JSON for software, not a styled page.

The public verifier API accepts the same artifacts:

curl --fail-with-body \
  -H 'Content-Type: application/json' \
  --data-binary @artifact.json \
  https://YOUR-PASSPORT-HOST/api/v1/verify

Replace the host with your trusted issuer. Send a bare artifact or {"document": artifact}. Do not upload private keys or bearer tokens.

Four separate questions

1. Identity: which issuer signed this agent or credential?
2. Integrity: is the signature valid and bound to the expected subject, project, action and full request details?
3. Current authority: is the agent active, is the grant current, and has this authorization expired, been revoked, or already been used?
4. Execution: did the protected system enforce those checks before acting?

Offline signatures answer integrity, not live revocation or successful execution. Pin the intended issuer and obtain its keys from a trusted origin. Keep previous verification keys when rotating the issuer key.

Decision receipts

Recorded allow/deny decisions carry signed evidence. Pending requests do not yet have a final decision receipt, and malformed, unauthenticated or otherwise rejected input may receive only an error. Do not assume every HTTP response contains a receipt.

A signed denial is useful audit evidence but never permission. An allowed receipt still needs matching request details, a valid execution window, current authority and one-shot enforcement. Use Passport's relay for supported integrations. Custom executors must enforce their own equivalent boundary.

When a live check is unavailable, the result is incomplete, not silently valid. The SDK's checkReceiptStatus can check live decision state, but it does not atomically execute or consume a custom action. Custom runtimes need replay-safe execution and must stop on failed or unavailable checks.

Security model

Keep signing keys and upstream credentials outside the model's access. Runtime provenance is not hardware attestation; onBehalfOf is signed attribution by the runtime, not authentication of that person.

Read the protocol for formats and security boundaries for trust assumptions. Exported audit chains establish integrity relative to a trusted signed head; they are not an independent public transparency log.