Delegate key policy

Two very different keys exist in Raven's world. Confusing them is the classic mistake.

Access credentials vs signing keys

Your hosted API key (x-api-key) is an ACCESS credential — it gates who may call /verify. Raven's ed25519 SIGNING key signs receipts and lives server-side only, never issued to anyone. Losing an API key never compromises receipt authenticity.

One key per context

Want separate keys per agent, project, customer, or environment? That's the right instinct — ask for them at request access. If one leaks, that ONE key is revoked and reissued; nothing else rotates, and historical receipts are unaffected. Suggested naming (prefixes only, examples not real keys): rvk_live_{project}_{agent} · rvk_beta_{project}_{agent} · rvk_internal_{canary} · rvk_customer_{name}.

Hard rules

No API keys in browser code — ever. Any browser-visible call must go through your own server.
No API keys in public repos. Use env vars; gitignore env files.
No API keys in agent memory or stored receipts (/receipt-memory-policy.md).
Holder-beta is enabled per key only — one agent can have holder evidence while another doesn't.
ACP jobs need NO hosted API key at all: your agent pays per job (0.1 USDC, escrowed) and the key never exists client-side.
Leak suspected? Tell us; the key is revoked and reissued. Receipts already issued stay valid — they're signed by Raven's key, not yours.