> specific situations in which Claude Code will embed a user's GitHub CLI OAuth token into a response body, and in situations where response bodies are logged, these tokens may appear in LiteLLM logs.

That's pretty hand wavy. What did y'all have CC doing that it had your GitHub CLI OAuth token in its context at all?

Stuff like this is why my coding agent is a coding agent not shell agent that basically own the machine. Mine has no tool for shell use narrow tools specific things like ripgrep, finding files, and deleting files that limit the paths to explicit workspace directory.

I take care of commits, push/pull, building wheels, and publishing wheels myself. It really doesn't take the much time and the coding agent frees up a lot of my time.

> I take care of commits, push/pull, building wheels, and publishing wheels myself.

I too was surprised when I see my colleagues telling me that these actions are "not maximizing your efficiency".

They'd rather hand all controls to the LLM, and then be surprised when shit hits the fan.

Yeah, I don't get either. I look at source control as the first line of defense for when agents screw up to badly. I'm not going let the agent mess with the easiest way to undo its screw ups.

> narrow tools specific things like ripgrep

Ripgrep has the `--pre` flag and `--hostname-bin` flag that enables it to execute arbitrary commands.

> finding files, [...]

Does that tool invoke the `find` command? Because `find` has the `-exec` flag which could then be used to invoke arbitrary commands.

I really think the only safe option is putting your agent in a virtual machine with only a copy of your code (sans credentials), let the agent work, and then copy it back and manually audit it.

The implementation of the tools don't execute processes (i.e. the implementations aren't wrappers for shell commands).

It's not a novel attack: it's novel negligence.

The best improvement would be to blame yourselves instead of Claude.

Hi fny,

That's fair feedback. What I'm trying to express is the complexity of it.

For this to work:

1. The attacker had to get access to our internal gateway

2. Claude code had to embed the github oauth cli token in tool call responses (not directly, but as part of an embedded url call).

3. We had to enable request/response logging.

4. The attacker had to be aware of this token logging circumstance, then harvest multiple user account tokens (one of which had to belong to an org admin)

5. The attacker had to wait for / hope that we would expand the release trust boundary (as we did on Monday)

among other things. This wasn't a "whoops we had shitty governance around our auth tokens" kind of situation, it involved a number of non-trivial circumstances many of which were beyond the attacker's direct control, including Claude Code behavior of which we were not previously aware of, and a sophisticated attacker.

- Krrish

FYI - accidentally logging secrets is a fairly common thing that happens. Request/response bodies are fairly common place that would include secrets or PII. but in general you’d be surprised what other actually innocent places that end up accidentally including secrets. Having credential scanners on the logs is a way to catch these early.

As for sophisticated attackers, I think that phrase should probably be retired at this point. Every attacker is a fairly sophisticated now since you can automate that sophistication. Attackers before used to have a set of tools that would try to connect or execute a bunch of automated prescripted checks, while any attacker now can automate the generation of those tools and scripts on demand

Amateur hour again.

Original articles says it was likely a comprimised maintainer machine?

From our investigation, the token compromised was included by claude code in the tool call.

This was captured in the request/response logs.

The attacker, having gotten access to the logs, then looked for this and used it.

So - yes a local github cli oauth token, but not the machine.

What about adding a human in the loop? So the actual releases to the package registry would be done manually after reviewing the package?