This Key Will Self-Destruct: An Open Standard for Revocable API Keys

Summary

A new proposal, the Open Revocable Key Standard (ORKS), aims to address the common problem of leaked API keys by introducing a standardized, self-destructing mechanism. Inspired by OAuth's token revocation, ORKS would embed issuer information directly into keys and establish discoverable revocation endpoints, allowing scanners to automatically revoke compromised credentials.

Full text

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.Advertisement. Scroll to continue reading. 4. Declared constraints. The discovery file advertises which bindings the issuer supports, such as IP allowlists, mandatory expiry, scopes, and mTLS. Suddenly “does this vendor support IP-pinned keys?” is a question your procurement tooling can answer with a single GET instead of a two-week email thread. The pull cord that doesn’t stop the line The strongest objection to unauthenticated revocation is availability. If possession grants revocation rights, a leaked key isn’t just a confidentiality problem. Anyone who finds it can break your production integration with one curl command. Toyota’s answer to a similar dilemma was the andon cord: any worker can pull it, but pulling it doesn’t instantly halt the factory. It summons attention, and the line stops only if the problem isn’t resolved within a window. ORKS borrows that design with an optional quarantine mode. An unauthenticated revocation request doesn’t kill the key on the spot. Instead: The owner is notified immediately, on every registered channel, with the reporter’s evidence attached. The key is instantly restricted: read-only, throttled, destructive operations blocked, everything logged. A timer starts (24 hours by default, advertised in the discovery file). When it expires, the key dies automatically. The owner can expedite to instant revocation, or cancel after explicitly acknowledging the evidence, through their authenticated dashboard only, never an email link. Griefing becomes a supervised wind-down instead of an outage. A genuinely leaked key spends its final hours handcuffed instead of fully live. And for high-risk key classes like payments and admin, the issuer can simply declare immediate mode. The trade-off becomes an explicit, published policy instead of an accident of whoever reads the security inbox first. Why AI agents make this urgent Everything above was true when a credential holder meant a developer and a CI pipeline. It becomes acute now that the holder is increasingly an autonomous AI agent. Agents are credential multipliers. A single agent wired into your tooling holds keys for email, code, CRM, payments, and cloud infrastructure all at once, and teams deploy agents faster than they inventory them. Agents also leak differently: they can be induced through prompt injection to exfiltrate their own credentials, and they echo secrets into logs at machine speed. The window between compromise and abuse collapses from days to seconds, which makes any revocation path that starts with an email categorically too slow. ORKS fits the agent era in three ways. A machine-readable kill switch is exactly the interface an autonomous system can use. A guardrail that catches an injection attempt mid-flight can quarantine the credential itself, as a reflex. Declared constraints are how you hand a key to something you don’t fully trust: IP-pinned, scoped, short-lived. And my favorite pattern inverts the framing entirely: an agent that finishes its task should revoke its own key on the way out. Keys minted with an immediate-self-revoke policy plus a short TTL give you least-privilege in the time dimension. A key found in a log after its task completed is already dead, and the revocation call doubles as an audit event. The industry is converging on OAuth-flavored answers for agent identity, and it should. But the transitional reality is millions of agents holding static keys for services that offer nothing better. A revocation standard doesn’t make those keys good. It makes them killable, which, for an agent that might be manipulated into misusing them, is the property that matters most. Where this goes The beauty of well-known conventions is that they need no central authority and no big-bang adoption. One provider can ship this next sprint: prefix your keys, publish one static JSON file, stand up one endpoint. The scanners racing to build per-provider revocation integrations get a generic detector instead. Every new issuer makes every scanner more useful, the same flywheel that made security.txt normal. The endgame is boring in the best way. A key leaks, a scanner or the agent holding it finds it in minutes, decodes the issuer, hits the well-known endpoint, and quarantines the credential. The owner wakes up to a notification, an evidence link, and a rotation button instead of a fraud report. Your mission, should you choose to accept it: make every key you issue capable of self-destructing. This proposal will not disavow you. The full draft spec (ORKS v0.1), including endpoint schemas, the key format, and the quarantine state machine, is open for review and contributions at github.com/6d6b68/ORKS. Feedback, objections, and prior art I’ve missed are all welcome: open an issue or a pull request. Written By Matt Honea Matt Honea is CISO at Hippocratic AI. He previously served as head of Security and Compliance at Forward Networks. He is a security leader and has a background in the areas of threat intelligence, networking, system forensics and discovery, enterprise security auditing, malware analysis and physical security. He is an

Entities