No, you can block this with sandboxing tools. For my LLM agents, I use a tool called Nono, whose macOS implementation is built on the same foundation as sandbox-exec. One of the key features it supports (and it's not the only tool that does this) is proxying and the injection of credentials via the proxy. For example, when I run Codex at work, Codex does not have access to my Azure AI Foundry API credentials. It sends out requests via dummy credentials, and the proxy injects the real ones outside the sandbox.
The other thing that proxy does is let you restrict network access in various ways. So you can run something like LiteLLM so that it doesn't have access to the internet at large; it can only talk to Azure AI Foundry or AWS Bedrock or whoever your inference provider is. You sandbox LiteLLM separately from your agents, and you give it access to much less. The software firewall stuff isn't perfect but it is a significant defense against things like this.
There are also lots of other restrictions that are easy to do which mitigate this. Nono blocks access to the root of $HOME, then selectively allows access to paths within it, and also explicitly blocks access to common paths to secrets. So it's pretty easy to make sure that access to important things are blocked: SSH credentials, GnuPG socket (and local Unix sockets in general), local OS keyrings, etc.
The way I use tools like this is exclusively by writing policy, testing it, and revising where the policy is inadequate. I never get approval fatigue because I don't do approvals.
You're right that attacks like this are hard to defend against, and that we're used to tool sprawl, and also that LLMs can do things like install tools we don't expect them to themselves! But there are ways to anticipate and mitigate attacks like this. Sandboxing tools (including contained and VMs) that support credential injection are genuinely useful for this.
LiteLLM is frequently used in roughly the same scenario - trading virtual LAN-only keys for real ones as it relays requests to the inference providers.
LiteLLM isn't a sandboxing tool so it just can't perform as much risk reduction even when everything is working as intended.
And what nono adds over sandbox-exec is a uniform interface across platforms and some policy management tools. You can impose the same restrictions via the OS built-in mechanisms yourself via Seatbelt or a built-in interface like sandbox-exec. You can also combine an OS-level sandboxing tool like nono, zerobox, Anthropic's srt, Seatbelt, landrun, Bubblewrap, Fence, etc., with a VM-based one like Docker's sbx, smolvm, krunvm, microsandbox, or Shuru. So now you need two simultaneous supply chain attacks in unrelated projects to line up just right at the same time.
"Eventually you have to trust some part of your security stack" is neither particularly interesting nor evidence that there's no way to defend against supply chain attacks. Even if you only have one sandboxing tool and it's OS-level rather than VM-based, that becomes a single part of your stack that you can give special attention to in evaluating updates in a way that LiteLLM can't be.
There's also just the empirical fact that at this point, trusting LiteLLM's maintainers to lock down their release pipelines looks foolhardy. This is the second supply chain attack they've had in 7 months. It's absolutely wiser to choose a sandboxing tool you like, audit it to examine its release pipelines, code signing requirements, attestation strategy, and whatever else, then put LiteLLM inside that tool's sandbox than to just thow your hands up and say "I gotta trust something, so it might as well be LiteLLM!". Maybe nono ain't it either, idk. I'm still experimenting to figure out how I want my setup to work.
But I think neither the defeatism nor the relativism in this thread are very compelling.
Sandbox comes in for the unknown ones and yes, its a pain to get the profile right.
From some of them perhaps, but plenty hide for -years- undetected.
I mean okay, it probably helps in some random cases, but the disease will not care at all. Easy to route around and we just wasted a lot of developer energy treating symptoms and ignoring the actual problems.
People are running around acting like cooldowns fix supply chain attacks. This is completely absurd. Imagine an antivirus that just makes you wait one day to install any new software or updates. Should we do that too? We should question what problem are we actually solving before this type of thinking gets even more out of hand.
What we need is actually reviewing all heavily used OSS code with as many eyes and agents as possible in a coordinated and decentralized way, and then federated reproducible signed releases. If we are going to have a one day cooldown, we must do something actually useful with it or people will see it does no good and stop doing it. Without a review plan, a day might as well be a year.
Like literally fund this with taxes or something like caring for public roads. Add it to our internet bill like a utility safety fee.
I mean, didn't Linux shells invent pop-up fatigue? I thought we (yes, we) all used to -y flag preemptively so the upgrades and installations/setups go through. Linux really did do it first, the agents are just more needy and their popups more verbose now, but not exactly new.
VM isn't a silver bullet.
Either way it's got nothing to do with security - I was never going to catch a vulnerability in the central debian repos by reading a list of dependent packages.