I'm trying to run several isolated coding agents with as little access as possible. Some should not be able to reach the web or communicate with one another, so I disable WebSearch because the request is handled outside the sandbox and could potentially introduce prompt-injection risks. I'm using managed-settings.json to control the available tools, but an agent with passwordless sudo—or access to Docker-in-Docker—could potentially modify that configuration and restore tools I intentionally disabled. I've started hardening the setup 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. What I don't understand is why passwordless sudo is enabled by default in the first place. Is it mainly for convenience and YOLO-style workflows? What practical benefit does it provide, and why isn't there an official toggle for disabling it? More broadly, why is an important file like managed-settings.json writable from inside the sandbox instead of being protected by the host or runtime?
3 Answers
Passwordless sudo is usually a convenience choice for images that run as a non-root user. Agents can install packages, change system settings, or perform build steps without getting stuck on an interactive password prompt. It does increase the damage possible inside the guest, but the assumption is that the guest boundary—not sudo configuration—is the main security boundary. Also, putting secrets or important build inputs directly into an image can leave them permanently exposed in layer history, so those should be supplied through safer external mechanisms.
The intended security model is that the sandbox or microVM is disposable and hostile code may gain full control inside it. Passwordless sudo makes setup and development tasks easier for agents, but it is not meant to protect configuration from a compromised process inside the sandbox. Anything that must remain trusted should be enforced outside the guest, then recreated when the sandbox is discarded.
A strong option is to bind-mount managed-settings.json as read-only. The runtime enforces that mount, so even root inside the container cannot write to it. Make sure the sandbox is not running with --privileged or broad capabilities such as SYS_ADMIN, since those options can undermine the isolation. This is generally preferable to relying on filesystem flags like schg inside the guest.
That makes sense. I’ll look into a read-only bind mount instead of trying to make the file immutable from inside the sandbox.