You hit the nail on the head. Mounting `/var/run/docker.sock` is basically giving the agent root access to the host, which defeats the purpose of the sandbox. Armorer avoids the DinD problem entirely. The control plane (Armorer itself) orchestrates the containers from the host level, but the agent containers themselves do not have access to the Docker socket. If an agent needs to execute a tool, that execution happens within its own restricted sandbox, and it communicates back to the control plane via a controlled interface, rather than trying to spawn sibling containers itself.
Did you check Docker sbx yet? Instead of running Agents in a container, it's recomended to run it inside microVM. https://docs.docker.com/reference/cli/sbx/
[dead]
[dead]
[flagged]
[flagged]
You hit the nail on the head. Mounting `/var/run/docker.sock` is basically giving the agent root access to the host, which defeats the purpose of the sandbox. Armorer avoids the DinD problem entirely. The control plane (Armorer itself) orchestrates the containers from the host level, but the agent containers themselves do not have access to the Docker socket. If an agent needs to execute a tool, that execution happens within its own restricted sandbox, and it communicates back to the control plane via a controlled interface, rather than trying to spawn sibling containers itself.