Every security leader has lived some version of this incident. A researcher, a scanner, or a well-meaning stranger finds one of your API keys sitting in a public repository. Now the clock is running, but instead of a kill switch, what follows is a scavenger hunt. Which company issued this key? Who do I contact? Is there a security.txt? Does anyone read that inbox? By the time the right person revokes the right credential, hours or days have passed, and attackers needed minutes. Bots scrape public repos constantly, and the majority of leaked secrets are still active years later.
Here’s what strikes me about this problem: we already solved it once. In 2013, OAuth got RFC 7009, a standardized token revocation endpoint discoverable through a well-known configuration URL. Any conformant client can kill a token programmatically. Then the industry kept right on shipping plain API keys, the credential type that actually leaks the most, with no revocation story at all.
The one bright spot is GitHub’s Secret Scanning Partner Program: providers register key patterns, GitHub scans public commits, revocation happens by webhook. It works, and it’s proprietary, centralized, and invite-only. Meanwhile, look at where the open-source scanning world is heading. The new generation of scanners all list the same roadmap item: automatic revocation via provider APIs. Every one of them will have to hand-build integrations, provider by provider, because there is no standard way to ask an issuer “please kill this key.”
That’s the gap. So let me sketch the standard I want to exist. I’m calling it ORKS, the Open Revocable Key Standard, with a draft spec now on GitHub. Like Mission: Impossible’s briefing tapes, the idea is simple: credentials should come with self-destruct built in.
The proposal, in four parts
1. Keys that name their issuer. Every key carries a fixed prefix, an encoded issuer domain, the secret, and a checksum: orks_{issuer}_{secret}_{check}. GitHub already proved both halves of this pattern. Its token prefixes made scanning tractable, and its embedded checksums killed false positives. The new part is the issuer domain, so any scanner that finds a key knows, offline, exactly who to call.
2. A discoverable kill switch. Every issuer serves a small JSON file at /.well-known/api-key-config listing its revocation endpoint, an optional introspection endpoint, a security contact, and which key constraints it supports. Same playbook as OIDC discovery and security.txt.
3. Revocation by possession. POST the full key to the revocation endpoint. No authentication required. The logic: anyone holding the key can already abuse it, so letting them destroy it instead is strictly an improvement. Requiring the complete key means there’s nothing to enumerate, and the endpoint returns the same “accepted” response whether the key was live, dead, or never real.