I wouldn’t recommend this. What if GitHub’s token scanning service went down. Ideally GitHub should expose an universal token revocation endpoint. Alternatively do this in a private repo and enable token revocation (if it exists)

You're revoking the attacker's key (that they're using to upload the docs to their own account), this is probably the best option available.

Obviously you have better methods to revoke your own keys.

it is less of a problem for revoking attacker's keys (but maybe it has access to victim's contents?).

agreed it shouldn't be used to revoke non-malicious/your own keys

The poster you originally replied to is suggesting this for revoking the attackers keys. Not for revocation of their own keys…

there's still some risk of publishing an attacker's key. For example, what if the attacker's key had access to sensitive user data?

All the more reason to nuke the key ASAP, no?

> What if GitHub’s token scanning service went down.

If it's a secret gist, you only exposed the attacker's key to github, but not to the wider public?

They mean it went down as in stopped working, had some outage; so you've tried to use it as a token revocation service, but it doesn't work (or not as quickly as you expect).

Sure, that's a valid worry. Though that's not all that different from a special purpose public token revocation service: they can also go down.

True, just more to rely on with the scanning too I suppose.

Haha this feels like you're playing chess with the hackers

“Hack the hackers back” is a pretty old idea with (IIUC) very shaky legal grounds and not a lot of success. It would be much better if Anthropic had a special reporting function for API abuse.

Rolling the dice in a new kind of casino.

So that after the attackers exfiltrate your file to their Anthropic account, now the rest of the world also has access to that Anthropic account and thus your files? Nice plan.

For a window of a few minutes until the key gets automatically revoked

Assuming that they took any of your files to begin with and you didn't discover the hidden prompt

Pretty brilliant solution, never thought of that before.

If we consider why this is even needed (people “vibe coding” and exposing their API keys), the word “brilliant” is not coming to mind

To be fair, people committed tokens into public (and private) repos when "transformers" just meant Optimus Prime or AC to DC.

Except is there a guarantee of the lag time from posting the GIST to the keys being revoked?

Is this a serious question? Whom do you imagine would offer such a guarantee?

Moreover, finding a more effective way to revoke a non-controlled key seems a tall order.

If there’s a delay between jets being posted and disabled they would still be usable no?

I'm being kind of stupid but why does the prompt injection need to POST to anthropic servers at all, does claude cowork have some protections against POST to arbitrary domain but allow POST to anthropic with arbitrary user or something?

In the article it says that Cowork is running in a VM that has limited network availability, but the Anthropic endpoint is required. What they don't do is check that the API call you make is using the same API key as the one you created the Cowork session with.

So the prompt injection adds a "skill" that uses curl to send the file to the attacker via their API key and the file upload function.

Yeah they mention it in the article, most network connections are restricted. But not connections to anthropic. To spell out the obvious—because Claude needs to talk to its own servers. But here they show you can get it to talk to its own servers, but put some documents in another user's account, using the different API key. All in a way that you, as an end user, wouldn't really see while it's happening.

why would you do that rather than just revoking the key directly in the anthropic console?

It’s the key used by the attackers in the payload I think. So you publish it and a scanner will revoke it

oh I see, you're force-revoking someone else's key

Which is an interesting DOS attack if you can find someone's key.

The interesting thing is that (if you're an attacker) your choice of attack is DoS when you have... anything available to you.

Does this mean a program can be written to generate all possible api keys and upload to github thereby revoke everyone's access?

They are designed to be long enough that it's entirely impractical to do this. All possible is a massive number.

That's true tho... possible, but impractical.

Not possible given the amount of matter in the solar system and the amount of time before the Sun dies.

Only possible if you are unconstrained by time and storage.

Not only you, but GitHub too, since you need to upload.

Storage is actually not much of a problem (on your end): you can just generate them on the fly.

Could this not lead to a penalty on the github account used to post it?

No, because people push their own keys to source repos every day.

Including keys associated with nefarious acts?

Maybe, the point is that people, in general, commit/post all kinds of secrets they shouldn't into GitHub. Secrets they own, shared secrets, secrets they found, secrets they don't known, etc.

GitHub and their partners just see a secret and trigger the oops-a-wild-secret-has-appeared action.