Comment by mfro

17 hours ago

If you haven’t already been running your agents in containers, you’re crazy. That said, this looks like a great way to manage those containers.

Depends what you mean with "agents"... LLMs in coding harnesses, or fully autonomous agents?

If you mean the former, I think you'll find probably 90% of devs are "crazy", running Claude Code or Codex on their bare metal using the auto-classifier.

I used to always run claude with `--dangerously-skip-permissions` in a dev container, but I had to rebuild my container 10 times a day to update the firewall so it can access documentation.

Now I find the included auto-classifier is very reliable. If you keep tasks contained instead of open-ended long-horizon work, it doesn't seem much goes wrong with frontier models. The worst unintended action claude did for me in the past months is that it once discarded an unstaged file which wasn't committed yet, without asking.

But I realize it's still playing with fire, no matter how good the auto-classifier is.

You're running them in containers, and not in VMs on separate network through network filter and logger?

  • I haven't gone to network filter and logger yet, but I'm running mine in a VM, using lima (https://lima-vm.io/) to make it painless. Works on Mac and Linux, has an untested Windows version.

    • What's the difference between lima and conventional fat VM using kvm/virtualbox?

      I only heard about smolvm yet and they are YC, so I'm hesitant to use them as they will probably one day pull the rug.

      2 replies →

  • So far I've settled on one jumbo VM with many Incus containers inside. Nothing goes inside the VM that I can't afford for agents to exfiltrate. I've been really happy with this setup.

  • I’d like to know more about your use case, could you tell us more? And are there any specific tools you find useful here?

    I ask because I’ve found that as isolation increases, so does friction, and then of course capabilities.

  • For real.

    My agentic workloads happen on two physical machines dedicated only to agentic workloads that share a VLAN with only eachother, with single token access to the specific repositories they are meant to push to and limited scope, hard limited credentials pulled from the hardware store on hardware token/fingerprint request only.

    I view the safety around unmonitored agentic work in a similar way to how I view working with viruses or bacteria in a disease lab.

    This stuff isn’t magic, it isn’t intelligent, but it is dangerous and needs to be handled with careful intent.

But then it decides to exfiltrate all your shit even inside the container. Which is something I'm trying to lock down at work atm.

Everything needs to go through a proxy, whitelisted domains only, plus credential swapping/re-signing so that the agent never has the real credentials. Docker sandbox looks quite good (September) but I've been using iron proxy (if the author is reading this, fucking thank you bro!) to great effect.

I still haven't cracked "what if the agent decides to drop parts of your codebase somewhere it shouldn't" yet, but I'll figure it out.

  • Been thinking about this a lot lately, and it’s a surprisingly difficult problem.

    All it needs is public access to anything it can have the tiniest effect on, and it can exfiltrate data. Something as simple as a read count on some obscure forum post would be enough, albeit very slow.

    • Yeah, exactly. I'd say it borders on almost unsolvable for any agent of reasonable complexity.

      You see some of the vulnerability chains humans come up with and they're just insane.

      Even scanning network data for sensitive strings (say matching against a codebase or data set it works on) is tough because you can only check so granularly before you get loads of false positives.

      But maybe like a "rolling" sort of check would help with that, % of outbound data matching private dataset (which should be operated on but not transmitted) over time. That way it minimises what gets out while dealing with false positives. Some biz thresholds might be >20% of data others might be >0.5%. Hmm.

    • I am tackling this using the Lethal Trifecta principle.

      The idea is that agents never have all parts of the trifecta, maximum 2: untrusted content, private data or network access.

      Harness have network access by default since they are driven by their provider API, unless you use offline models. So that's a problem.

      I am then passing around messages that are tagged trusted/untrusted and the engine can monitor if any agent in the project ever completes the Lethal Trifecta and thus, is vulnerable.

      Usually this means for most workflows, the "work" gets done by an offline LLM after some input/classification stages. There's not many ways around it.

      Yes, it's a difficult problem.

      5 replies →

    • If you can make any request to the outside world you can exfiltrate data, period. You can even include data in the uri or headers and they will appear in logs.

      That obviously includes talking with the provider.

      If you want it secure, it has to be off the internet and on your own hardware.

      3 replies →

  • You would need a human reviewing every single action of the agent to prevent them from exfiltartimg data. There are just too many possible side channels for a predefined solution. I believe currently what you want is a locally hosted decision model scoring every agent action againt a set of rules with a human in the loop once the decision model isnt 'confident' the actions are harmless.

  • I've been thinking a lot about this problem. Also, I think like the idea might be to look at the issue with code mode. Like basically, we know that all agents can write bash and execute it and that is what agents default code mode is.

    But like if you only allowed for example JavaScript code that could be executed in a WASM sandbox, then you would have better control instead of just locking down with proxies. Basically there would be a very large API, basically tools, that the agent would codemode execute. My guess is that this would need a tool router to optimize the loading of these into the context. But it would give you very fine control over what code execution can and cannot be done.

I have been running my dev setup in orb machines before agents. Very convenient when you have 50 Python or nodes deps.

As an example I run opencode and anything related agent-related in its own dedicated KVM VM with its own LVM logical volumes for storage on a headless server. This has no access whatsoever to the personal data that lives on my laptop and workstation desktop PC. The VM gets periodically imaged and backed up, and is relatively easy to move between host machines if I need to.

One benefit of doing this is that I can leave it doing long term slow things with slow but capable LLMs on a truly 24x7 basis without worrying about it being interrupted by a laptop being closed/going to sleep, or workstation level software updates/reboots on my primary desktop PC.

not everyone is building a webapp that can just run in a container...

how am i gonna run a game and do all development inside docker...?