Open Source Project #236: PentAGI — A Fully Autonomous Multi-Agent Penetration Testing System With 20+ Pro Tools Built In, 28k+ Stars

An open-source, self-hosted multi-agent system for autonomous penetration testing: describe a target and a goal, a team of specialized AI agents plans the work, runs 20+ professional tools like nmap, Metasploit, and sqlmap inside an isolated Docker sandbox, remembers what it learned, and hands you a report. Go + React, MIT license, 28k+ Stars, supports 10+ LLM providers.

·11 min read·AI Tools
open-sourcesecuritypentestai-agentmulti-agentgolangoffensive-securityself-hosted

Introduction

PentAGI = Penetration testing Artificial General Intelligence

This is article #236 in the "One Open Source Project a Day" series. Today's project is PentAGI — an open-source, self-hosted, fully autonomous multi-agent system for penetration testing, built by security engineering company VXControl, 28,770 Stars, MIT license, and a Trendshift trending repository across daily, weekly, and monthly rankings.

Penetration testing has an awkward reality: skilled security engineers are in short supply, and a huge chunk of their time gets eaten by repetitive reconnaissance, tool invocation, and report-writing work. PentAGI's answer is to let a team of AI agents carry that repetitive load. You describe the target system and the testing goal in plain language. A team of specialized agents — researcher, developer, executor — plans the work on its own, runs 20+ professional security tools inside an isolated Docker sandbox, stores what it learns in a vector database for later reuse, and ultimately produces a vulnerability report with exploitation guides.

A note on scope: PentAGI is explicitly built for security engineers, penetration testers, researchers, and red teams, for authorized testing only. Respect the project's intended use and don't use it for unauthorized attacks.

What You'll Learn

  • PentAGI's multi-agent division of labor: an Orchestrator coordinating Researcher / Developer / Executor roles
  • How a three-layer memory system (long-term, working, episodic) lets agents "remember" attack experience across runs
  • Execution monitoring and intelligent task planning: how to keep agents reliable even with sub-32B open models
  • Quick start: from the interactive installer to your first login
  • The two ways agents can access Docker, and the sharply different security trade-offs between them

Prerequisites

  • Basic familiarity with the penetration testing workflow (reconnaissance, vulnerability discovery, exploitation, reporting)
  • Working knowledge of Docker / Docker Compose
  • Some understanding of how LLM agents operate helps when digging into the architecture

Project Background

Overview

PentAGI isn't another "wrap an LLM and let it generate attack scripts" tool — it's a production-oriented autonomous pentesting infrastructure: your own servers, your choice of model, a persistent memory system, a full observability stack, and REST/GraphQL APIs ready for automation. PentAGI Enterprise adds agent profiles, plugins, MCP server support, customer-ready reports, and a real-time attack-chain view — but the open-source core alone is already a fully functional system.

Author / Team

  • Developed by: VXControl, a security engineering company based in Dubai
  • Primary language: Go (backend) + React/TypeScript (frontend)
  • License: MIT License
  • Created: 2025-01-06
  • Status: Actively developed, a Trendshift trending repository across daily, weekly, and monthly rankings

Project Stats

  • ⭐ GitHub Stars: 28,770+
  • 🍴 Forks: 4,325+
  • 📄 License: MIT
  • 📅 Created: 2025-01-06
  • 👥 Core contributors: sirozha leads with 615 commits, followed by asdek (204), mason5052 (93), and several other active contributors, plus regular dependency updates from dependabot
  • 🏷️ Topics: ai-agents, ai-security-tool, autonomous-agents, golang, multi-agent-system, offensive-security, penetration-testing, security-automation, self-hosted

Quick Start

System Requirements

  • Docker and Docker Compose (or Podman)
  • Minimum 2 vCPU, 4GB RAM, 20GB free disk space
  • Internet access for downloading images and updates

Using the Interactive Installer (Recommended)

PentAGI ships an interactive installer with a terminal UI, supporting Linux, macOS, and Windows, which walks you through system checks, LLM provider setup, search engine configuration, and security hardening.

# Create an installation directory
mkdir -p pentagi && cd pentagi
 
# Download the installer (Linux amd64 example)
wget -O installer.zip https://pentagi.com/downloads/linux/amd64/installer-latest.zip
unzip installer.zip
 
# Run the interactive installer
./installer

The installer needs access to the Docker API — in production, run it with sudo ./installer; in development, you can add your user to the docker group instead, keeping in mind that this effectively grants root-equivalent privileges.

The installer automatically handles: system checks → generating a .env file → configuring an LLM provider (10+ supported, including OpenAI, Anthropic, Gemini, Bedrock, Ollama, DeepSeek, GLM, Kimi, Qwen, MiniMax, Mistral, xAI, and custom OpenAI-compatible endpoints) → configuring search engines (DuckDuckGo, Google, Tavily, Firecrawl, Perplexity, SearXNG, and more) → generating secure credentials and SSL certificates → starting everything with docker-compose.

Production Deployments: A Two-Node Architecture

For production or security-sensitive deployments, the project strongly recommends a distributed two-node architecture — isolating actual worker execution on a separate server from the main system, to prevent untrusted code execution and network access issues from bleeding into your primary infrastructure. The two-node setup provides isolated execution, network isolation, Docker-in-Docker with TLS authentication as a security boundary, and dedicated port ranges for out-of-band (OOB) attack techniques.

Core Deep-Dive: Multi-Agent Division of Labor and Layered Memory

Role Division Under Orchestrator Coordination

At PentAGI's core is a team of agents coordinated by an Orchestrator. The sequence diagram in the README makes the flow clear:

  1. Initialization: the Orchestrator queries the vector store for similar past tasks and loads relevant context from the knowledge base
  2. Research phase: the Researcher analyzes the target, searches the vector store for similar cases, queries the knowledge base for known vulnerabilities, and stores new findings back to the vector store
  3. Planning phase: the Developer plans the attack, querying available exploitation techniques and tool capabilities
  4. Execution phase: the Executor runs the plan, loads tool usage guides, and stores results back to the vector store

This "researcher → developer → executor" three-stage split essentially maps the standard pentesting workflow (reconnaissance → planning → execution) onto specialized agent roles, instead of having one general-purpose agent try to handle everything end to end. Each role stays focused on its own subtask, keeping context cleaner and making it far easier to localize where things went wrong.

A Three-Layer Memory System: Long-Term, Working, Episodic

PentAGI's memory architecture is split into three layers — this is the key design that sets it apart from "one-shot conversational" pentesting tools:

  • Long-term memory: a vector store (PostgreSQL + pgvector) records successful attack patterns, and a knowledge base records domain expertise and tool usage patterns — these experiences carry across Flows (tasks), meaning what an agent learns during one engagement doesn't vanish when the task ends
  • Working memory: the current task's context state, active goals, and system resources — supporting continuity across a single run
  • Episodic memory: historical actions, action results, and success patterns — this layer records "what happened," feeding into later pattern distillation

There's also optional Graphiti + Neo4j knowledge graph integration for semantic relationship tracking and deeper contextual understanding, automatically capturing agent responses and tool executions into a knowledge base scoped to a single flow.

Chain Summarization: Fighting Context Window Bloat

Pentesting tasks often require many rounds of tool calls and reasoning, and conversation context can blow past token limits fast. PentAGI's chain summarization system converts a conversation chain into a structured representation (ChainAST) that preserves tool-call and response types, then selectively summarizes oversized message pairs while guaranteeing the last section stays fully intact and uncompressed. The global summarizer and the Assistant-specific summarizer can be configured independently (last-section byte size, number of QA pairs to retain), with the Assistant mode defaulting to a larger context allowance so it preserves more recent conversation history.

Execution Monitoring and Intelligent Task Planning: A Safety Net Built for Smaller Models

This is one of PentAGI's most notable engineering details. The project is explicit: for open models under 32B parameters, enabling both Execution Monitoring and Task Planning is essential, not an optional nice-to-have:

  • Execution monitoring: an Adviser agent (acting as a mentor) automatically steps in when execution patterns look off — e.g. 5+ identical tool calls in a row, or more than 10 total tool calls (both configurable) — to judge whether the agent is actually progressing toward the subtask goal, catch loops and inefficiencies, and suggest alternative strategies
  • Intelligent task planning: before specialist agents start work, a Planner breaks the original request into 3-7 concrete, actionable steps, wraps them in a <task_assignment> structure, and keeps agents from scope-creeping beyond their current subtask

In the project's own testing with Qwen3.5-27B-FP8, turning on both capabilities together doubled result quality — at the cost of 2-3x more tokens and execution time. That trade-off is stated honestly: smaller models tend to fixate on a single approach and loop on failure, and trading tokens for explicit supervision is a reasonable deal — one that matters a lot for air-gapped or offline deployments where you can't just call a cloud frontier model and have to run a local one instead.

Two Ways Agents Access Docker: a Real Security Trade-Off

Many pentesting workflows need docker available inside the agent's sandbox. The README lays out two approaches and is direct about the risk difference between them:

  • Recommended: point the sandbox at a hardened, standalone dind (Docker-in-Docker) daemon over TLS. Set DOCKER_INSIDE=true, mount no socket at all, and configure only the remote TLS endpoint.
  • Not recommended: bind-mounting a Docker socket (DOCKER_SOCKET) directly — which has two real failure modes. First, a boot-order race: a mount source that doesn't yet exist gets created by Docker as a directory, and if a worker container starts before dind has recreated its socket, that directory sits where the socket should be. Second, and more serious — a bind-mounted host Docker socket hands an autonomous agent the host's full Docker API: it can launch a privileged container, mount /, and compromise the entire node, PentAGI included.

The candor here is worth calling out: instead of glossing over "mounting the socket is convenient," the docs spell out exactly how each approach can fail and what the blast radius is, letting the operator make an informed call for their environment.

Resources

Summary

PentAGI answers a practical question about "AI + penetration testing": getting an autonomous agent to run attack tools isn't the hard part — the hard part is doing it reliably, controllably, and auditably in production, instead of just impressing people in a demo.

Three things worth noting:

The three-stage role split plus the three-layer memory system explicitly encode the standard pentesting methodology into the system's architecture. Many AI security tools are just an LLM wrapped around tool-calling. PentAGI makes the Researcher/Developer/Executor division and the long-term/working/episodic memory layers first-class architectural concepts — which means the system's behavior pattern more closely resembles a real security team's collaborative process than a single agent improvising on its own.

The honest framing of execution monitoring and task planning as "built specifically for smaller models" is this project's most valuable engineering judgment. Plenty of open-source AI projects quietly assume you're running a top-tier closed model. PentAGI gives a concrete recommendation — enable supervision for sub-32B models — backed by actual measured data, which is genuinely useful guidance for enterprise users who need to run local models in air-gapped or internal-network environments.

The disclosure around Docker access options reflects the kind of self-scrutiny a security tool should have. It would be ironic for a penetration-testing tool to leave its own sandbox-escape backdoor open by default. PentAGI doesn't dodge the fact that bind-mounting a Docker socket hands host-level privileges to an autonomous agent — it states the specific failure modes of both the recommended and discouraged approaches directly. That level of transparency isn't common in security tooling.

If your team is looking for a way to automate the repetitive grind that accumulates during penetration testing, and can work within the "authorized testing only" boundary, PentAGI's architecture is worth a serious look.

Explore PrimeSkills — a curated marketplace of AI agents and skills, each validated against real enterprise workflows. No hype, just what actually works.

Visit my personal site for more insights and interesting products.

← Back to Blog