PentAGI: What Multi-Agent Coordination for Security Actually Looks Like

By Prahlad Menon 6 min read

There’s a version of the PentAGI story circulating on LinkedIn right now that claims it will disrupt the entire cybersecurity industry, eliminate $150K pentest retainers, and requires no expertise to use. That version is wrong.

Here’s the accurate version: PentAGI is a genuinely well-architected multi-agent system for autonomous penetration testing. The architecture is interesting enough to write about on its own merits — without the hype.

What It Actually Is

PentAGI is an open-source system that coordinates a team of specialized AI agents to perform penetration testing tasks autonomously. It’s built for authorized security testing by security professionals — the same people who currently run nmap, metasploit, and sqlmap manually, and who write reports for clients who’ve contracted them to find vulnerabilities.

It’s not magic. It doesn’t bypass anything a human pentester couldn’t bypass. What it does is automate the coordination overhead between research, tool execution, and exploit development — and remember what works across engagements via a persistent knowledge graph.

8,200+ GitHub stars. MIT license. Real project with real architecture decisions worth understanding.

The Agent Team

The interesting thing about PentAGI isn’t any individual capability — it’s the delegation model. Most “AI security tools” are a single model with tool-calling. PentAGI has four distinct agents with defined roles:

Orchestrator Plans the full attack chain. Given a target scope and objective, it breaks the engagement into subtasks and delegates them. It decides when to re-research based on new findings, when to hand off to the developer for custom exploits, and when the engagement is complete.

Researcher Handles intelligence gathering. It uses built-in web scraping, plus integrations with Tavily, Traversaal, Perplexity, DuckDuckGo, Google Custom Search, and Sploitus (a vulnerability search engine) to gather: open-source intel on the target, known CVEs for identified software versions, public exploit code, and configuration guidance for relevant tools.

Developer Writes custom exploit code when existing tools don’t cover the attack path. This is the agent that makes PentAGI more than a tool wrapper — it can generate Python, bash, or targeted payload code for novel vulnerabilities the Researcher identifies.

Executor Runs the actual tools. 20+ professional security tools are available: nmap for network scanning, metasploit for exploitation, sqlmap for SQL injection, and more. The Executor selects the right Docker container image automatically for each tool — keeping everything sandboxed.

Each agent can be monitored individually. The optional execution monitoring layer lets you watch what each agent is deciding in real time — useful both for learning and for auditing what the system did during an engagement.

The Knowledge Graph

The persistent memory layer is where PentAGI diverges most from simpler tools.

It uses Graphiti (built on Neo4j) to maintain a knowledge graph across engagements. The graph tracks semantic relationships between:

  • Targets (hosts, services, applications)
  • Vulnerabilities (CVEs, configurations, discovered weaknesses)
  • Tools (which tools worked against which target types)
  • Techniques (successful attack chains, failed approaches)

The practical implication: an engagement against a web application running Apache 2.4.49 will benefit from what the system learned from a previous engagement against the same stack. The Orchestrator can query the graph before deciding on an attack path — “what worked last time against this configuration?” — rather than rediscovering the same techniques from scratch.

This is the closest thing PentAGI has to genuine learning. It’s not model fine-tuning — it’s structured experience retrieval. The distinction matters: it gets better at routing and tool selection over time, but the underlying model capability doesn’t change.

Sandboxing Architecture

All tool execution happens inside isolated Docker containers. The Executor selects the appropriate container image for each task automatically — a port scan gets a different container than a metasploit module.

This mirrors good red team OPSEC practice: keep tool execution isolated from the control plane so a failed exploit, a crashing tool, or an unstable payload can’t propagate. It also means the system can safely run tools that would be dangerous to execute directly on a host (sqlmap against a target you want to stay connected to, for instance).

For teams using NanoClaw-style sandbox isolation for their agent infrastructure, this pattern will look familiar — it’s the same philosophy applied to security tooling.

Getting Started

# Clone and configure
git clone https://github.com/vxcontrol/pentagi
cd pentagi
cp .env.example .env
# Edit .env — add your LLM API key and search API keys

# Start the stack (includes Neo4j, observability, frontend)
docker compose up -d

# The frontend is at http://localhost:3000
# Create a new engagement, set your target scope, and start

The frontend gives you a dashboard to create engagements, monitor agent activity, and review findings. The API is also available if you want to integrate PentAGI into an existing security workflow.

For LLM configuration, PentAGI supports any OpenAI-compatible API — so you can run it against Claude, GPT-4, or a locally hosted model via Ollama. The agent team works better with more capable models; the Researcher and Developer agents in particular benefit from strong reasoning.

What It Won’t Do

To be direct about the limitations:

It won’t replace enterprise pentests. Enterprise engagements involve scoping calls, legal agreements (rules of engagement, liability), custom reporting aligned to client risk frameworks, remediation guidance, and stakeholder communication. PentAGI produces findings — not engagements.

It requires authorized access. Running PentAGI against systems you don’t own or have written permission to test is illegal. The tool has no mechanism to prevent misuse — that’s entirely on the operator.

It’s not a red team. Red teaming involves adversary simulation, social engineering, physical intrusion testing, and custom TTPs matched to specific threat actors. PentAGI is a vulnerability discovery and exploitation tool — closer to an automated scanner with exploit capability than a red team.

Model quality limits output quality. The Developer agent writing custom exploit code is only as good as the underlying model’s coding capability. Novel, complex exploits will require human review and refinement.

The Honest Value Proposition

For security professionals doing authorized testing, PentAGI is a legitimate productivity tool. The combination of automated recon, coordinated tool execution, and persistent knowledge graph handles the mechanical parts of an engagement — letting the human focus on the strategic decisions: what to prioritize, how to chain findings into a narrative, what the business risk actually is.

For developers building multi-agent systems in other domains, the architecture is worth studying. The Orchestrator/Researcher/Developer/Executor pattern — specialized agents with clear role boundaries, coordinated by a planner, with persistent memory spanning sessions — is a clean example of how to structure agent teams for complex multi-step tasks. We covered similar patterns in the DeepAgents architecture post.

The CrustClaw security gateway work is exploring the defensive side of the same question: as agents gain more capability to take real-world actions, what does responsible sandboxing and access control look like? PentAGI is an interesting case study in what happens when you apply that kind of architectural discipline to an inherently adversarial domain.


PentAGI is open-source at github.com/vxcontrol/pentagi. MIT license. Use only on systems you are authorized to test.