I missed getting hit by the worst supply chain attack in recent memory by thirty minutes. That’s not a flex. That’s not even luck. It’s the difference between a coffee break and a catastrophe.
Thirty minutes earlier, and my SSH keys, my GPG signatures, my entire identity as a developer—gone. Exfiltrated by a package I never should have run in the first place.
Here’s what I learned in the aftermath: I was living in a fantasy where I thought my local machine was safe. It’s not. Every AI agent you run is a stranger you’ve invited into your home, and you’ve handed them the keys to the safe.
So I built something about it. Two tiny tools—dirblock and envblock—that together weigh less than a single image file. They are 67KB and 119KB of pure, focused paranoia.
The LiteLLM Wake-Up Call
You probably remember the LiteLLM attack. If you don’t, you’re exactly the person this article is for. A popular open-source tool got compromised, and everyone who installed it in a certain window handed over their environment variables—including cloud tokens, API keys, and database credentials.
I was thirty minutes away from being in that group. Thirty minutes. And I’ve been running AI coding agents on my machine for months now. Claude reads my code. Codex reads my shell history. They all read each other’s session files.
That’s the part nobody’s talking about. Your AI agents are already spying on each other, and they’re not even trying to be malicious. The user who tested my tool found it immediately: Claude reads Codex’s traces. Codex reads Claude’s. Every harness freely reads every other harness’s session history.
You’ve probably watched an AI agent work. It reads files, it writes code, it executes commands. That’s the whole point. But have you thought about what it reads when it’s not working? What it touches when you’re not watching?
I’ll tell you. It reads your ~/.ssh directory if it can. It reads your ~/.aws/credentials if they’re accessible. It reads any environment variable that’s been exported to your shell. And it does this because it CAN, not because it’s evil.
That’s the fundamental problem with our current security model. We built AI to be helpful, and we gave it the keys to everything to make it helpful. We forgot to take the keys back.
The Inversion: Deny by Default
Here’s where I’m going to lose some of you, and I’m okay with that. The answer isn’t better detection. It’s not smarter firewalls. It’s not AI-powered threat hunting.
The answer is to invert the entire model. Stop asking who’s trying to break in. Start asking why anything is allowed in at all.
dirblock uses fanotify to block access to ~/.ssh, ~/.gpg, and any other sensitive directories you specify. But here’s the key: it doesn’t block everything. It whitelists the specific programs you trust—your actual SSH client, your actual GPG tool—and denies everything else by default.
envblock does the same thing for environment variables. It runs on eBPF and intercepts reads of GH_TOKEN, AWS_SECRET_ACCESS_KEY, and similar secrets. If a trusted program asks, it gets the real value. If anything else asks, it gets a poisoned fake.
This is the opposite of how most security tools work. Most tools try to detect the attack after it starts. These tools prevent the attack from ever succeeding, because the secrets are simply not there.
Failure Is a Feature
Here’s the part that will make security engineers uncomfortable: these tools are designed to fail open or fail poisoned. They are not trying to be a full Mandatory Access Control system. They’re not trying to be SELinux. They’re not trying to sandbox your entire operating system.
They’re deliberately small. Deliberately narrow. Deliberately incomplete.
And that’s exactly why they work.
If dirblock fails, your files become readable again—but you’ll know, because your workflows still work. If envblock fails, your real secrets get through—but you’ll know, because the poisoned values stop appearing. In security, a tool that fails loudly and obviously is worth more than a tool that fails silently and invisibly.
I’ve been running both on my own machines for months. Setup takes under an hour once you know which directories and variables actually matter to you. Configuration is TOML. There are dry-run modes. It’s not rocket science.
It’s just discipline.
The Gap Only You Can Fill
Here’s the hard truth, and I’m going to say it directly: these tools are not a complete solution. They’re a boundary. They set the perimeter. But they don’t patrol it.
That’s on you.
You need to know which directories hold your secrets. You need to know which environment variables feed your cloud providers. You need to know which programs legitimately need access to which resources.
That’s the configuration discipline. That’s the part that takes under an hour. But it’s also the part that most developers never do, because it requires you to actually think about your own security posture.
Let me be blunt: if you’re using AI coding agents and you haven’t thought about what they can access on your machine, you’re not a developer. You’re a liability.
The tools are free. They’re open source. They’re on GitHub right now. And they’re 67KB and 119KB respectively. There is no excuse for not trying them.
Because the next LiteLLM won’t give you thirty minutes. It won’t give you thirty seconds. And when it hits, you’ll want to be the one who says “not me, not today.”
I was thirty minutes from being the cautionary tale. Now I’m the one telling you to prepare. Your AI agents are reading each other’s secrets. Make sure they’re not reading yours.
FAQ
Q: What exactly happened with LiteLLM, and why should I care if I wasn't affected?
A: LiteLLM, a popular open-source LLM proxy, was compromised and attempted to exfiltrate environment variables from developers who installed it during a specific window. The author missed it by 30 minutes. If you weren't affected, you're lucky—but the next attack won't wait. Supply chain attacks are becoming the #1 vector for credential theft, and AI tools make them worse because agents inherently need broad access to be useful.
Q: How is a whitelist-based approach different from antivirus or EDR tools?
A: Traditional tools detect known attack patterns and block them. Whitelist tools deny everything except explicitly approved programs. Detection tools fail when an attack is novel or unknown. Whitelist tools fail only when you misconfigure them. For protecting static secrets like SSH keys and API tokens, whitelisting is categorically more secure because there's no detection step to bypass.
Q: Doesn't a whitelist approach break legitimate workflows?
A: Sometimes, temporarily. That's the point. When a legitimate program is denied access, you'll notice immediately and can add it to the whitelist. This is a feature, not a bug—it forces you to be intentional about which programs touch your secrets. The author has run these tools for months and reports setup takes under an hour for a standard development environment. The trade-off is worth the security.
Q: Can I just use permissions or restrictive file modes instead?
A: No. File permissions mean nothing when you're running an AI agent as your user. The agent runs with your privileges, so it can read anything you can read. The whole point of AI coding tools is that they operate as you. Tools like dirblock and envblock intercept at the kernel level (via fanotify and eBPF), which means they can distinguish between 'you running ssh' and 'an AI agent trying to read your ssh keys.' File permissions can't make that distinction.