Should All Credentials Be Able to Self-Invalidate?

Agents have made almost everything about a leaked credential easier. In the wrong hands, an agent can find a compromised key, check that it still works, and start abusing it faster than ever. In the right hands, the same agent can find that key, and confirm that it’s live, just as quickly. What hasn’t gotten correspondingly easier is the part that actually ends the problem: getting credentials invalidated, particularly in bulk.

There are some exceptions. If certain credentials end up in certain places, there are systems built to catch them. GitHub’s Secret Scanning Partner Program is one: when a partner’s token is pushed to a public repository, GitHub notifies the partner of the match, and the partner can revoke it automatically, without anyone emailing anybody. GitHub is also one of the (relatively) few companies with a credential revocation API for the credentials it issues itself. Outside of those lanes, remediation looks much like it always has. You work out who owns the key, you find some way to contact them, and you wait for a person to read your message and rotate it.

My position is that, given the risk, we’re at the point as an industry where a “good citizen” who finds a compromised credential should be able to use that credential to invalidate itself. Not report it, not file a ticket, not hope that somebody is watching the security@ inbox. Use the key once, to kill the key.

The Coordination Window Is Gone#

Responsible disclosure has always leaned on an assumption about time. If you found something, it was fair to assume that nobody else had found it at the same moment, and that there was some human-time-scale window available to coordinate remediation and disclosure. You contact the owner, they rotate the key, and everyone moves on.

I don’t believe that’s a fair guess anymore. Sweeping public repositories, paste sites, leaked build logs, and client-side bundles for anything shaped like a secret was already cheap, and agents make it cheaper still. If your white-hat agent finds something, a black-hat agent is more-likely-than-not only a couple of steps behind you. It may well be a couple of steps ahead.

That changes what the disclosure window actually is. Every hour spent tracking down the right contact, and waiting on a reply, is an hour in which you should assume the key is in use by someone who has no intention of reporting it. Human-time-scale remediation against machine-time-scale abuse is not a race the owner is likely to win.

It also doesn’t scale. An agent working through a leaked dump doesn’t find one credential; it finds whatever is in there, across however many providers that happens to be. Finding a hundred keys is one job. Getting a hundred keys revoked is a hundred separate conversations, each with its own process (if a process exists at all). Detection got faster. Bulk invalidation didn’t.

Possession Is Already Authority#

The obvious objection is that letting anyone holding a credential revoke it hands attackers a new capability. I don’t think it does, or at least not a meaningful one.

Anyone holding a bearer credential can, in general, already do everything that credential allows. That’s what a bearer credential is.¹ If the key can read your customer database, whoever holds it can read your customer database. Of all the things a holder can do with a leaked key, invalidating it is very likely the least harmful option on the menu.

The real cost is availability. If the key is still wired into a production service, revoking it breaks that service, and a bad actor could use self-invalidation purely to cause an outage. That’s a legitimate cost, but it’s worth being honest about what’s actually being lost. Once a key has leaked, it has to be rotated anyway. Every reasonable incident response ends with that key dead. Self-invalidation doesn’t decide whether the key dies; it decides when, and who gets to make the call.

Put another way: a leaked key has already lost its confidentiality, and whatever it can write is one bad actor away from being changed. Giving up some availability to close that window early is a trade I’d take almost every time.

Where This Fits#

“All” is doing a lot of work in the title. Self-invalidation isn’t a fit for every credential, but I’d rather describe the conditions that make it work than list the cases where it doesn’t, because most of those conditions are things an owner or issuer can go and create.

Self-invalidation is a fit when the owner finds out. A key that silently stops working is an outage with no explanation attached. Revocation by a third party should notify the owner the same way a provider’s own leak detection would, with when it happened, and where the key was found if the reporter can say.

It’s a fit when rotation is cheap. If replacing a key means a firmware update, a customer migration, or a week of coordination, then a surprise revocation is going to hurt. The answer there isn’t to protect the key from being revoked, though. A key you can’t rotate quickly was already a problem the moment it leaked; self-invalidation just surfaces it sooner.

And it’s a fit when the credential is actually meant to be secret. API keys, personal access tokens, and service account keys map cleanly onto this. A publishable key that is designed to sit in a web page does not. It was never leaked, and letting anyone kill it would hand a denial-of-service button to every visitor. The line is one that already exists: if exposure would trigger a rotation, exposure should also be enough to trigger a revocation.

What It Would Take#

Not a lot, which is part of why I think this is worth pushing on.

One half is a call on the issuer’s own API that accepts the credential itself as the only proof required. There’s no account to sign up for, and nobody on the other end of an email to wait on. Present the key, the key stops working, and the owner gets told. It also gives the person holding the key an explicitly sanctioned thing to do with it, which is more than most finders can say today.²

The other half is where to send it. Finding the right issuer doesn’t need anything new. Anyone who wants to abuse a key already has to work out where that key is useful, and a good citizen can work that out just as easily. If a key works against an API, that API is where it should be revocable. The same discovery that makes a leaked key dangerous should be enough to kill it. What it doesn’t tell you is how to make the call once you’re there, and forty APIs with forty different revocation shapes is still forty integrations.

What That Could Look Like#

I’d want two pieces, both deliberately boring.

The first is a revocation call with a standard shape. Over HTTP, that’s an unauthenticated POST to a revoke endpoint, with the credentials in the body:

POST /revoke HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"credentials": ["<leaked-credential>", "<another-leaked-credential>"]}

For a gRPC API, the same thing is an auth.RevokeToken call whose request carries the tokens and nothing else. Either way, the request should take a list, since an agent working through a dump may well be holding more than one key for the same issuer.

The second is a standard place to find that endpoint, on the host the key already works against. security.txt (RFC 9116) is the obvious home. It already sits at a well-known path, it already exists to tell outsiders how to report a security problem, and the spec allows new fields to be added through an IANA registry. One more field would do it:

Contact: mailto:[email protected]
Expires: 2027-04-17T00:00:00Z
Credential-Revocation: https://api.example.com/revoke

To be clear, Credential-Revocation isn’t a real field; that’s the proposal. An agent holding a key that works against api.example.com fetches https://api.example.com/.well-known/security.txt, finds the field, and posts the key to it. Tools that read security.txt are required to ignore fields they don’t support, so adding it doesn’t break anything that reads the file today.

Some of This Already Exists#

None of this is a new idea, and for a couple of issuers it’s already been built.

GitHub’s revocation API, generally available since April 2025, is very nearly the whole proposal. It accepts GitHub personal access and OAuth tokens the caller doesn’t own, found anywhere, up to a thousand in a single request, and rejects authenticated requests outright. The request is essentially the one sketched above: a POST with a list of credentials. The owner is notified when one of their tokens is revoked. GitHub also automatically revokes its own tokens when they’re pushed to a public repository. Where all of this stops short is that the API covers one issuer, and the partner program only helps when a token lands somewhere GitHub happens to be scanning.

Slack has a smaller version. Its auth.revoke method takes nothing but the token itself, and needs no scopes, so anyone holding a Slack token can revoke it.

PyPI shows a more guarded version. It has a reporting API built for third parties who find PyPI tokens, and tokens reported through it have been revoked automatically, at least when GitHub is the reporter. Access, though, is granted case-by-case, and the current partners are GitHub and deps.dev. Third-party revocation exists, but only for the third parties the issuer has already decided to trust.

Google Cloud has already made the availability trade on its customers’ behalf. Since June 2024, exposed service account keys are disabled by default when Google detects them, typically in public repositories. That’s the same “the key dies now, and the owner deals with it” call I’m arguing for. The difference is only in who gets to trigger it.

Possession as authority isn’t new at the protocol level either. ACME, the protocol Let’s Encrypt is built on, lets a certificate be revoked by a request signed with the certificate’s own private key, no account required.

The clearest objection is OAuth. RFC 7009 requires the revoking client to authenticate (or present a valid client ID), and the token has to belong to that client. A third party holding a leaked token can’t revoke it, unless the token belongs to a public client, whose ID was never a secret anyway. OAuth even has the discovery half already: authorization server metadata advertises a revocation_endpoint at a well-known path, though it assumes client authentication there by default. RFC 7009’s own security considerations make the core argument regardless: someone who guesses a public client’s ID (or a confidential client’s credentials) and one of its tokens “could do much worse damage by using the token elsewhere than by revoking it.”

Closing the Gap#

Agents have put leak detection and leak abuse on the same clock. GitHub has shown that an issuer can accept a revocation from anyone holding one of its tokens. For most other issuers, as far as I can tell, revocation is still running on a human clock, and I don’t think that gap closes until the credential itself can be used to end it.

If holding a credential is enough to abuse it, holding it should be enough to kill it.