I'm trying to run several isolated coding agents with strong restrictions: they shouldn't be able to communicate with one another, and some shouldn't have web access at all. I disabled WebSearch because the request is handled outside the sandbox, which could potentially bypass the isolation I want.
I'm using managed-settings.json to control the agents, but I'm concerned that an agent could use sudo—or Docker-in-Docker if the setup permits it—to modify that file and restore disabled tools. I've already tightened the environment by disabling passwordless sudo, removing the agent user from sudo, wheel, and docker groups, and using a non-privileged base image without a Docker daemon.
I understand that permissive defaults can be useful for running agents in an unrestricted or "YOLO" mode, but why provide passwordless sudo in the first place? What practical use does it serve, and why isn't there an official setting to disable it? Also, should important policy files such as managed-settings.json be mounted somewhere the agent cannot modify?
3 Answers
Passwordless sudo is also a practical image-building choice: it lets the default user perform common setup tasks without embedding a password in the image. Passwords are awkward here anyway, and putting one in a Dockerfile can leave it exposed in the image layers. For a hardened agent, though, removing sudo access and using a non-root image is the better configuration.
The default is mostly about convenience and compatibility. Images often need a non-root user that can install packages, change system settings, or run development tools without stopping for a password. It isn't meant to be a security boundary inside the sandbox. The safer assumption is that anything running inside it is hostile, and the sandbox itself should be treated as disposable.
A strong approach is to provide managed-settings.json as a read-only bind mount. Then the container runtime enforces that it cannot be changed from inside the environment, including by root. Be careful not to use options such as --privileged or add SYS_ADMIN, since those can undermine the protections you're relying on.
That makes sense. Is a read-only bind mount preferable to making the file immutable with a filesystem flag?