You should not be using docker with LLMs. You should be using VMs, which have a much, much smaller attack surface than Docker, and significantly more reasonable defaults.

▲

embedding-shape 6 hours ago | parent | next [-]

The "attack vector" people try to protect themselves is "agent edited wrong file", not "LLM blew 0day on escaping sandboxing", containers are more than enough for what stupid stuff agents sometimes try, no need to go for a full-blown VM. Even UNIX permissions would be enough, but I think that's lost knowledge at this point.

▲

apitman 5 hours ago | parent | next [-]

If your agent has access to the internet at any point it may read something that convinces it to try breaking out of its sandbox.

▲

fragmede 6 hours ago | parent | prev | next [-]

Not if the host's version of .git is accessible inside the container via a bind mount.

	▲	embedding-shape 5 hours ago \| parent [-]
		Obviously if you setup a bi-directional share/link between what you are trying to contain and your host, you're not quite containing it at all... Don't do that! :)

▲

TZubiri 5 hours ago | parent | prev [-]

Using the least amount of security features is a huge amateur mistake.

Best practice is to use 2 redundant layers of security, such that if one fails, there is still another one.

Using just the minimum amount of security technically possible is almost by definition hubris.

An example would be that you never point a gun at someone you don't want to shoot, regardless if there's bullets in the gun. If someone tells you, "you don't need to control where you point the gun, you just need to keep the gun unloaded and you can point it in jest to whoever you want, you can even pull the trigger technically", you know you have a reckless fool, regardless of whether they are technically right.

▲

embedding-shape 5 hours ago | parent | next [-]

> Using the least amount of security features is a huge amateur mistake.

Not understand your threat I'd say would be a even bigger amateur mistake, you're not trying to protect yourself against some forever 3rd party attacker here, you're trying to prevent a agent rewriting the wrong file on your disk, that's basically it.

Give it the least amount of permissions, don't bi-directionally sync stuff, pass things in, then take them out again, literally the agent couldn't and wouldn't try to break through 2 layers of security in order to get your banking details or whatever.

▲

singpolyma3 5 hours ago | parent | prev [-]

This is true but it's not really a security scenario. The LLM isn't an attacker it's just an unreliable tool.

▲

syntheticnature 5 hours ago | parent | next [-]

Unreliable/stupid is worse than malice, here.

	▲	TZubiri 3 hours ago \| parent [-]
		Let's ignore the fact that the LLM did an LPE, and let's assume it did it without malice. It can still get infected and be used as an attack vector by some hidden prompt or some other equally advanced state of the art vuln like "disregard all previous instructions"

▲

felixgallo 5 hours ago | parent | prev [-]

all unreliable tools are attackers. Even if you're using well-aligned LLMs like Opus, you should assume that any input you give it -- including all dependencies from npm, etc. -- are at risk of compromise, which could result in attempted exfiltration of data or system takeover. You can be absolutely sure that there are thousands of well-motivated hacker groups, both national and private, looking for ways in.

▲

teravor 4 hours ago | parent | prev [-]

you can configure docker to use a VM container runtime or gVisor.