← Back to context

Comment by lucasluitjes

19 hours ago

> What you’re NOT protecting against:

> a malicious AI trying to escape the VM (VM escape vulnerabilities exist, but they’re rare and require deliberate exploitation)

No VM escape vulns necessary. A malicious AI could just add arbitrary code to your Vagrantfile and get host access the first time you run a vagrant command.

If you're only worried about mistakes, Claude could decide to fix/improve something by adding a commit hook. If that contains a mistake, the mistake gets executed on your host the first time you git commit/push.

(Yes, it's unpleasantly difficult to truly isolate dev environments without inconveniencing yourself.)

12 comments

lucasluitjes

Reply
johndough  18 hours ago 

    > A malicious AI could just add arbitrary code to your Vagrantfile
    > [...]
    > Claude could decide to fix/improve something by adding a commit hook.

You can fix this by confining Claude to a subdirectory (with Docker volume mounts, for example):

    repository/
    ├── sandbox <--- Claude lives in here
    │   └── main.py <--- Claude can edit this
    └── .git <--- Claude can not touch this

martinflack  9 hours ago

Maybe before 'vagrant up' you run 'sudo chattr +i Vagrantfile' to make it immutable. Seems to disallow removal of the attribute inside the VM, but allow it outside.

embedding-shape  14 hours ago

Doesn't this assume you bi-directionally share directories between the host or the VM? Or how would the AI inside the VM be able to write to your .git repository or Vagrantfile? That's not the default setup with VMs (AFAIK, you need to explicitly use "shared directories" or similar), nor should you do that if you're trying to use VM for containment of something.

I basically do something like "take snapshot -> run tiny vm -> let agent do what it does -> take snapshot -> look at diff" for each change, restarting if it doesn't give me what I wanted, or I misdirected it somehow. But there is no automatic sync of files, that'd defeat the entire point of putting it into a VM in the first place, wouldn't it?

  • lucasluitjes  12 hours ago

    It's the default behaviour for Vagrant. You put a Vagrantfile in your repo, run `vagrant up` and it creates a VM with the repo folder shared r+w to `/vagrant` in the VM.

    • embedding-shape  11 hours ago

      That's because Vagrant isn't "VM", it's a developer tool you use locally that happens to use VMs, and it was created in a era where 1) containers didn't exist as they do today, 2) packaging and distribution for major languages wasn't infected with malware and 3) LLM agents now runs on our computers and they are kind of dumb sometimes and delete stuff.

      With new realities, new workflows have to be adopted. Once malware started to appear on npm/pypi, I started running all my stuff in VMs unless it's something really common and presumed vetted. I do my banking on the same computer I do programming, so it's either that or get another computer.

      2 replies →

dist-epoch  16 hours ago

Another way is malicious code gets added to the repo, if you ever run the repo code outside the VM you get infected.