The whitelist approach works until it doesn't. The tricky part is that even "safe" commands can be dangerous in combination or with certain arguments. `cat /etc/shadow`, `grep -r password`, or `tail -f` on the wrong log file.
What's worked better for me: giving the agent access to a read-only replica for DB queries, and for SSH, using a restricted shell (rbash) with PATH limited to specific binaries. Still not bulletproof, but removes the "approve every ls command" friction while keeping the obvious footguns out of reach.
The mental model shift that helped: treat it less like "allow/deny lists" and more like designing a sandbox where the worst outcome is acceptable. If the agent can only read and the worst case is it reads something sensitive - that's a different risk profile than if it can write or delete.
The "capture everything immediately" approach never worked for me. I'd end up with thousands of notes I never looked at again.
What helped was accepting that most ideas aren't actually that good - they just feel urgent in the moment. Now I use a deliberate friction test: if I still remember the idea after an hour without writing it down, maybe it's worth capturing. The truly important stuff has a way of recurring.
For the stuff that IS worth keeping, voice memos work better than typing for me. Lower friction means I actually do it, and listening back forces me to process rather than just hoard.
For document processing in a side project, I've been using a local all-MiniLM model with FAISS. Works well enough for semantic matching against ~50k transaction descriptions.
The real challenge wasn't model quality - it was the chunking strategy. Financial data is weirdly structured and breaking it into sensible chunks that preserve context took more iteration than expected. Eventually settled on treating each complete record as a chunk rather than doing sliding windows over raw text. The "obvious" approaches from tutorials didn't work well at all for structured tabular-ish data.
The proxy pattern here is clever - essentially treating the LLM context window as an untrusted execution environment and doing credential injection at a layer it can't touch.
One thing I've noticed building with Claude Code is that it's pretty aggressive about reading .env files and config when it has access. The proxy approach sidesteps that entirely since there's nothing sensitive to find in the first place.
Wonder if the Anthropic team has considered building something like this into the sandbox itself - a secrets store that the model can "use" but never "read".
> a secrets store that the model can "use" but never "read".
How would that work? If the AI can use it, it can read it. E.g:
secret-store "foo" > file
cat file
You'd have to be very specific about how the secret can be used in order for the AI to not be able to figure out what it is. You could provide a http proxy in the sandbox that injects a HTTP header to include the secret, when the secret is for accessing a website for example, and tell the AI to use that proxy. But you'd also have to scope down which URLs the proxy can access with that secret otherwise it could just visit a page like this to read back the headers that were sent:
Basically, for every "use" of a secret, you'd have to write a dedicated application which performs that task in a secure manner. It's not just the case of adding a special secret store.
I guess I don't understand why anyone thinks giving an LLM access to credentials is a good idea in the first place? It's been demonstrated best practice to separate authentication/authorization from the LLM's context window/ability to influence for several years now.
We spent the last 50 years of computer security getting to a point where we keep sensitive credentials out of the hands of humans. I guess now we have to take the next 50 years to learn the lesson that we should keep those same credentials out of the hands of LLMs as well?
I'll be sitting on the sideline eating popcorn in that case.
The accounting pain nicbou mentioned is real. Bank reconciliation seems simple - two lists, match them - but then you hit timing differences where something cleared on different dates in each system, or description mismatches where the bank shows "PAYPAL *ACME" but you recorded "Acme Ltd - Invoice 4521".
Transaction categorisation is arguably worse because there's no universal standard. What one accountant calls "Office Expenses" another puts in "General Admin" - both correct for their context. Any automation that works for one client's books tends to break when you switch to another.
The timezone handling alone makes Temporal worth the wait. I've lost count of how many bugs I've shipped because Date silently converts everything to local time when you least expect it.
The ZonedDateTime type is the real win here - finally a way to say "this is 3pm in New York" and have it stay 3pm in New York when you serialize and deserialize it. With Date you'd have to store the timezone separately and reconstruct it yourself, which everyone gets wrong eventually.
Only downside I can see is the learning curve. Date was bad but it was consistently bad in ways we all memorized. Temporal is better but also much larger - lots of types to choose between.
The DoorDash pizza arbitrage comparison is apt. Both cases expose the same fundamental thing: venture-subsidised pricing creates artificial market conditions that clever people will exploit.
What I find interesting is how long these windows stay open. You'd think someone at Stamps.com or UPS would notice the pricing anomaly, but large organisations are often too siloed. The team setting international rates probably doesn't talk to whoever monitors small parcel economics.
The author mentions making a few hundred dollars - but the real question is scalability. At what volume does this become attractive enough for the postal services to close the loophole? There's probably a sweet spot between "not worth their attention" and "actually profitable."
Building CodeIQ - an AI tool that automates transaction coding for accountants and bookkeepers.
The interesting technical bit: it analyses your historic general ledger to reverse-engineer how you specifically categorise transactions. So instead of generic rules, it learns your firm's actual patterns - "oh, they always code Costa Coffee to Staff Welfare, not Refreshments" - that kind of thing.
Posts directly to Xero, QuickBooks, Sage, and Pandle. The VAT handling turned out to be surprisingly gnarly (UK tax rules are... something).
Been working on it about 6 months now. Still figuring out the right balance between automation confidence and "just flag this for human review".
The point about grid size assumptions is interesting. I studied physics and one of the first things you learn is that your choice of coordinate system can make a problem trivially easy or impossibly hard. Same underlying reality, wildly different solution paths.
Reminded me of a pattern I keep seeing in business software - teams spend months optimizing the wrong abstraction. They'll build an incredibly efficient data pipeline that turns out to process information nobody actually needs, or an algorithm that minimizes compute time when the real bottleneck is waiting for a human approval that takes 3 days.
The simulated annealing approach wasn't wrong per se - it's just that "minimise distance walked" was never actually the objective function that mattered to the humans doing the walking.
The measurement problem here is real. "10x faster" compared to what exactly? Your best day or your average? First-time implementation or refactoring familiar code?
I've noticed my own results vary wildly depending on whether I'm working in a domain where the LLM has seen thousands of similar examples (standard CRUD stuff, common API patterns) versus anything slightly novel or domain-specific. In the former case, it genuinely saves time. In the latter, I spend more time debugging hallucinated approaches than I would have spent just writing it myself.
The atrophy point is interesting though. I wonder if it's less about losing skills and more about never developing them in the first place. Junior developers who lean heavily on these tools might never build the intuition that comes from debugging your own mistakes for years.
What's worked better for me: giving the agent access to a read-only replica for DB queries, and for SSH, using a restricted shell (rbash) with PATH limited to specific binaries. Still not bulletproof, but removes the "approve every ls command" friction while keeping the obvious footguns out of reach.
The mental model shift that helped: treat it less like "allow/deny lists" and more like designing a sandbox where the worst outcome is acceptable. If the agent can only read and the worst case is it reads something sensitive - that's a different risk profile than if it can write or delete.
reply