Open standard lets API keys self-destruct on exposure
Draft standard ORKS would embed issuer domains in API keys and publish a well-known discovery file so leaked keys can be identified, quarantined or revoked by finders.
The draft specification ORKS v0.1 proposes embedding issuer domains in API keys and publishing a machine-readable discovery file so anyone who finds a leaked key can identify its issuer and trigger a revocation or quarantine process.
The draft defines a four-part system. Keys would include a fixed prefix, an encoded issuer domain, the secret portion and a checksum so scanners can identify the issuer. Each issuer would host a JSON configuration at /.well-known/api-key-config that lists a revocation endpoint, an optional introspection endpoint, a security contact and supported key constraints. Revocation would work by possession: posting the full key to the listed revocation endpoint would trigger the issuer’s revocation flow without additional authentication. The discovery file would also declare supported safeguards such as IP allowlists, required expirations, scopes and mTLS.
To reduce the risk of unauthorized outages, the draft includes an optional quarantine mode. Under quarantine, a revocation request would notify the key owner on registered channels, restrict the key to read-only or throttled access, block destructive operations and start a countdown (24 hours by default). The owner may cancel the quarantine or complete immediate revocation through an authenticated dashboard. Issuers can also declare an immediate mode that revokes keys on contact for high-risk credentials.
The draft highlights scenarios involving autonomous AI agents. Agents that hold multiple credentials can expose them rapidly through prompts or logs. A machine-readable revocation interface would allow automated detectors and agents to revoke or quarantine keys as part of workflows. ORKS also specifies short-lived keys with self-revoke policies so a credential can revoke itself after a task completes.
The draft notes that adoption does not require a central authority. Providers can implement the standard incrementally by adding a key prefix, publishing the well-known JSON file and providing a revocation endpoint. Scanners and automated tools could decode the issuer from a leaked key and call the endpoint without building a per-vendor integration for each issuer.
The full draft, including endpoint schemas, key format and the quarantine state machine, is published on GitHub as ORKS v0.1. The repository is open for review and contributions.
Articles by this author
