Revocable API Keys Get an Open Standard Called ORKS

The Problem: Leaked Keys That Nobody Can Turn Off

A draft open standard published this week proposes a fix for one of the most stubborn gaps in application security: the leaked API key that stays valid because nobody with the authority to kill it knows it exists. The proposal is called ORKS, the Open Revocable Key Standard, introduced by Matt Honea, CISO at Hippocratic AI, with a v0.1 draft specification open for review on GitHub.

• ORKS is a draft specification, published as v0.1 and open for public review — not a shipped product or an adopted standard
• Keys carry their issuer in the format orks_issuer_secret_check, so anyone who finds one can tell where it came from offline
• Issuers publish a discovery file at /.well-known/api-key-config listing revocation endpoints and supported constraints
• Possession is proof — you revoke a key by POSTing the key itself, with no account or authentication required

The gap the proposal targets is a timing mismatch. Honea cites research indicating that the majority of leaked secrets are still active years after exposure, while the window to respond is measured in hours or days and an attacker needs only minutes. Between those two numbers sits the reason so many breaches start with a credential that was public the whole time.

How Possession-Based Revocation Works

The clever move in ORKS is deciding who is allowed to press the button. Today, if a security researcher spots your API key in a public repository, their options are to file a ticket, email an address that may not be monitored, or do nothing. All three take longer than the attacker needs.

ORKS inverts that. Holding the key is treated as sufficient authority to revoke it, because anyone who has the key can already do whatever the key permits — revocation is strictly the least harmful thing they could do with it. So a finder POSTs the full key to the issuer's published revocation endpoint, and it dies. No account, no ticket, no wait.

The prefix format makes this discoverable without any lookup. Embedding the issuer domain in the key itself means a scanner that finds a string can determine offline which vendor to contact, then fetch the discovery file at /.well-known/api-key-config to learn the revocation endpoint and which constraints that issuer supports — IP allowlists, expiry, scopes, mTLS.

What Is Quarantine Mode?

The obvious objection to instant revocation is that it hands anyone a denial-of-service button against your production system. ORKS answers with an optional quarantine mode: rather than killing a reported key outright, the issuer downgrades it to read-only with throttling for 24 hours, notifies the owner through several channels, and revokes automatically if nobody responds.

That is a sensible compromise. A read-only, rate-limited key cannot be used to exfiltrate at speed or to write anything, so the attacker's advantage evaporates immediately, while a legitimate owner who is simply asleep gets a day to notice and rotate on their own terms.

Why a Standard Rather Than a Feature

Several large platforms already offer some version of this privately, and secret-scanning partnerships between code hosts and vendors have existed for years. What they lack is a common shape. Every issuer invents its own key format, its own reporting path, its own response policy, so tooling has to be written per vendor and coverage stops at whoever was worth the integration effort.

A published format plus a well-known discovery path turns that into one implementation that works everywhere adoption reaches. That is the same logic that made security.txt and RFC 9116 useful — modest specifications whose value is entirely in being uniform.

Worth being precise about status: no major vendor adoption was announced alongside the draft, and a standard with no issuers implementing it revokes nothing. The idea is sound and the spec is public; whether it becomes infrastructure depends on who picks it up. It fits a broader run of constructive defensive work this year, from open post-quantum migration priorities to practical fixes like the PostgreSQL logical decoding patch. More in our AI security coverage.

Sources: SecurityWeek — September 9, 2026; ORKS draft specification on GitHub — accessed September 9, 2026.