This has been a known Docker "feature" since the beginning, nothing new here. This pattern is used to configure host machines by some tools.
It would be cooler if the llm said something like:
> I noticed the machine doesn't have copy-fail patched, here is a quick workaround for not having root access for now.
> // TODO: find a better way to do this in the future.
I realize this is supposed to be a post about how scary the security vulnerabilities these agents will find are.
But personally I love when agents do things like this and appreciate the help. Last thing in the world I want is for them to nerf the models.
This is one of the main reasons people like Podman. Docker has this "feature" but as far as I remember, it needed some obscure configuration. I guess they don't add it as default as it will break many current setups.
I did that more than a decade ago as a new hire. My manager forgot to gave me sudo access to the shared build server. I gave myself sudo access through this method after getting his permission.
Needless to say, I have podman in rootless mode at home as soon as that became available.
The interesting question is what was the user request. If the user asked it to restore the thing from backup, then sure, fine, why not. If the user asked it to debug an issue and somewhere in the process of debugging the LLM decided that it needed to override some file that was not easily writeable - hell no danger danger danger! Most likely the user did not expect it to have access to that without asking, and did not consent to it.
Also, everything the LLM doesn't hesitate to do because the user asked, it won't hesitate to do because the prompt injection asked.
This is why you need either a rootless container setup or user namespaces to remap the container user to irrelevant host users. https://docs.docker.com/engine/security/userns-remap/
Weak that this isn't the default.
Maybe a dumb question, but can't you put into CLAUDE.md something like this?
"When an action fails with an 'access denied' or 'insufficient permission' error, report the error to the user and immediately stop. Do not try to find a fix or workaround for the error. Do not try any alternative approaches."
I was playing with gemeni-cli a couple months ago and I asked it to edit some files in a directory it didn't have permission to. It didn't say anything about the permissions, it just used sed to make the edits. The only reason I finally noticed is it had to do some trickier edits and it was struggling to write a python script to edit the files and I finally realized what it was doing. I wonder how many tokens that wasted
Run coding agents in a docker container with limited permissions. FWIW, I run it with
--cap-drop=ALL
--pids-limit=4096
--runtime=runscThis was of course dependent on yolo mode, but automatic approval has also been pulling stunts like this. A recent example is data that was purposely kept away from Codex in a folder far far away. When it found a single reference it just went for the data when having an issue. Lesson learned, keep essential data and Codex separated on different machines. Codex remote ssh actually helps here.
I feel like everyone pointing out "known Docker vulnerability" is missing the point: the presence of a security hole should not be seen as permission to exploit.
Another security hole would be storing your passwords in a plaintext file on the desktop. Stupid? Yes. But I still would not want my agent to assume permission to access email when it's being blocked by 2FA.
Even in "bypass permissions" mode I expect it to pause and clarify and not behave as a paperclip maximizer.
So in Linux, every process I start has my group permissions? I guess I knew that...but I have to say, have we reached a point where the Linux security model is just way to broad?
Docker moment
sudo can work non-interactively via settings in sudoers and sudoers.d . I am not sure about run0, but I would bet it has something similar.
Using docker for such a task seems to me overly over-engineered. Or maybe I need more context there.
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.
rootless docker. pain to install but can mitigate a catastrophe.
Another surprising security feature regarding docker is that it bypasses firewall rules.
https://oneuptime.com/blog/post/2026-03-02-ufw-docker-fix-by...
I don't have sudo or docker on mine!
Always run AI inside secured containers.
This is a classic attack path that was already captured by plenty of EDRs/XDRs/CWPPs a couple years ago.
this is the new GTD
[dead]
[dead]
Should have used my AI Agent Guardrails. Its free. Check it out at sigmashake.com
Every time I try to install Docker there's a warning that being in the "docker" group is equivalent to having root access.
You should probably know about this workaround by now.