The Sandbox Is a Boundary, Not a Guarantee

PentAGI's agents eventually leave the language layer and execute commands, read files, open network connections, and sometimes create further containers. This chapter examines the boundary around that execution: what the primary container can do, what Docker authority it can reach, and how the recommended worker-node design narrows the blast radius. The useful deployment judgment is not “Is PentAGI sandboxed?” but “Which authority does this Flow receive, through which daemon and network, and what remains exposed if that boundary fails?”

The primary container trades isolation for testing power

Each Flow gets a primary execution environment with a standard workspace, per-Flow storage, deterministic port allocation in bridge mode, log rotation, restart behavior, and cleanup. Terminal operations run through Docker exec and are associated with the Flow's container and Task/Subtask context. The terminal tool normalizes requested timeouts so agents do not receive an unlimited command window; the configured default is capped at three hours. Container startup is verified after Docker accepts the start request, because a process can die immediately even though the daemon reports that it started successfully.

The capability policy is explicit. PentAGI drops all capabilities and adds back a selected allow-list that includes permissions needed by common security and debugging tools, such as raw network access and process tracing. NET_ADMIN is opt-in for workflows that need interface, routing, or firewall control. Several powerful capabilities are deliberately absent, including MKNOD and SYS_ADMIN. The design is not “remove every privilege.” Penetration testing tools need privileges that ordinary application containers do not, and package installation or debugging can fail if the list is too narrow.

That is a real engineering trade-off. A minimal application sandbox would reduce authority but make many network and binary-analysis tasks impossible. A realistic test environment needs raw sockets, package management, and sometimes advanced networking. PentAGI therefore tries to make the privilege set explicit and bounded, but the resulting container remains a powerful environment for an autonomous process. The operator must evaluate whether the enabled capabilities and image are appropriate for the target and the worker host.

Resource limits add another kind of boundary. A default PID limit of 2048 constrains fork-bomb and process-exhaustion behavior without making ordinary parallel scans impossible. Terminal operations have time limits, and Docker logs rotate rather than growing without bound. The Flow gets its own volume or work directory, and cleanup removes containers and associated resources when a Flow is released. These controls protect host capacity and improve lifecycle hygiene; they do not prevent a permitted command from producing an undesirable network effect within its reachable scope.

Network mode changes the meaning of the container boundary. In bridge mode, PentAGI places workers on a configured network and maps Flow-specific ports. In host mode, the container shares the host network stack and does not use ordinary port mapping.