Worker node

In production, keep untrusted tool execution off the machine that runs PentAGI. A worker node hosts the agents' containers behind TLS-protected Docker endpoints, so commands an agent runs never touch the main host.

Why a worker node

• Isolation. Tool containers run on dedicated hardware with their own network boundary.
• Controlled Docker access. Agents that need Docker talk to a hardened Docker-in-Docker daemon through an authorization policy instead of the host daemon.
• Out-of-band testing. A dedicated port range on the worker supports OOB callbacks.

Connection modes

• Standard (recommended) — PentAGI connects to the worker's host Docker over TLS to create worker containers; workers reach Docker-in-Docker over its TLS endpoint. Set DOCKER_INSIDE=true together with DOCKER_INSIDE_HOST, DOCKER_INSIDE_TLS_VERIFY and DOCKER_INSIDE_CERT_PATH, and leave DOCKER_SOCKET empty: the .env template's /var/run/docker.sock would also mount the worker node's host Docker socket into every sandbox. Without DOCKER_INSIDE_HOST, agents get no Docker access.
• Direct — PentAGI talks to Docker-in-Docker directly; host bind-mounts are then denied by policy, so Docker access for agents must be disabled.

Set it up

The complete procedure — TLS certificates for both daemons, the hardened Docker-in-Docker configuration, policy updates and verification — is in the worker node guide in the repository.