AI Pentest Agents Part 4: PentAGI and the Cost of Docker Root

PentAGI is the other major open-source multi-agent pentesting project in this series, with over 10,000 GitHub stars, and it makes the opposite infrastructure bet from PentestCode (Part 2 of this series). Where PentestCode ships as a self-contained binary with no Docker requirement at all, PentAGI is built around Docker sandboxing as its core safety model — every operation runs inside an isolated container, by default a Kali Linux image pre-loaded with more than twenty tools including nmap, Metasploit, and sqlmap. That’s a real architectural trade-off, not just a packaging difference, and it’s worth understanding both sides before picking either one.

The agent roster

PentAGI’s specialist agents are named differently from PentestCode’s recon/scanner/enumerator/exploiter roster: Coder, Pentester, Installer, and Memorist, coordinating through a Go backend (76% of the codebase) with a React/TypeScript frontend, communicating over GraphQL. The Coder and Installer agents point at something the other tools in this series don’t really have — the ability to write and install its own tooling mid-engagement rather than being limited to a fixed toolset — and Memorist gives the system smart, long-term memory for research results, distinct from PentestCode’s engagement-state graph but solving a similar underlying problem: don’t lose what you’ve already learned when the immediate task changes.

PentAGI also ships a built-in browser and integrations with Tavily, Traversaal, and Google Custom Search for the system to gather current information mid-engagement — a capability none of the other tools in this series advertise explicitly, and a sensible one for a field that changes as fast as CVE disclosure and exploit-availability does.

The privilege model, and why it matters

This is the part worth being precise about, because it’s easy to wave away as “well, it’s Docker, of course it needs some privilege.” PentAGI’s docker-compose.yml runs the PentAGI service itself as root, because the service needs access to docker.sock to manage the sandbox containers it spins up per task. Installation similarly needs either root privileges directly, or a user added to the docker group — and adding a user to the docker group is, functionally, granting that user root-equivalent access to the host, because anyone who can talk to the Docker daemon can mount the host filesystem into a container and read or write anything root could. This isn’t a PentAGI-specific flaw; it’s a well-known property of Docker’s socket-based architecture that applies to any tool built the same way. PentAGI’s own documentation acknowledges it and offers a real mitigation: connecting to Docker over TCP/IP instead of the local socket file removes the need for root entirely, running as the default unprivileged pentagi user instead — at the cost of a slightly more involved network-based Docker setup.

Minimum requirements are modest for what it does — 2 vCPUs, 4 GB RAM, 20 GB disk — with installation via Docker Compose directly or an interactive installer covering Linux, macOS, and Windows.

Why this is the opposite bet from PentestCode, and why both are defensible

PentestCode’s root-free single binary means the agent process itself runs with exactly the privileges of whoever launched it, and nothing more — but it also means the tools PentestCode orchestrates (nmap, Nuclei, NetExec, and the rest) run directly on the host, in whatever environment you happened to install them into, with no container boundary between “the agent decided to run this” and “this ran against your actual filesystem.” PentAGI’s Docker sandboxing gives you a real, enforced boundary around every action the agent takes — a compromised or simply overzealous agent can’t reach outside its container without an explicit escape — but it buys that boundary by needing root or root-equivalent access to set up in the first place.

Neither is strictly safer in the abstract; they’re safer against different threats. PentestCode’s model is safer if your worry is “I don’t want to grant this agent broad host privileges to install it.” PentAGI’s model is safer if your worry is “I don’t trust the agent’s own judgment about what it should and shouldn’t touch, and I want a container wall regardless of what it decides to run.” For a personal lab like the one this series is aiming its Part 7 demo at — an isolated Proxmox bridge with no physical uplink, the same lab built for AI Part 7 — the network isolation is already doing the job PentAGI’s container boundary is designed for, which is exactly why PentestCode’s simpler, root-free install is the more practical choice for that demo. It would be a different call entirely on a shared or less-isolated host.

What PentAGI doesn’t publish

Notably absent from PentAGI’s documentation, compared to PentestGPT’s benchmark suite in Part 3 and PentestCode’s own limitations section in Part 2: no published cost-per-engagement figures, no benchmark-suite success rate, and no equivalent of PentestCode’s blunt “not stealthy” admission. That’s not necessarily a mark against the project — plenty of good tools don’t publish self-benchmarks — but it does mean a prospective user has less to go on when deciding what to expect from a real run, and it’s part of why Part 6 of this series, on detection surface, leans more heavily on PentestCode’s own documented limitations than on PentAGI’s.

Part 5 pairs NodeZero and XBOW — the two entrants in this series that aren’t open-source developer tools at all, but production platforms with real commercial track records, and a genuinely different bar for what “safe to run unattended” needs to mean.