PentAGI: The Self-Hosted AI Team That Hacks Your Application Before Someone Else Does

Most security tools perform the checks they are designed to run. A scanner identifies potential vulnerabilities, a fuzzer tests inputs, and individual tools produce results that a security engineer must interpret and connect. Turning those findings into a coherent assessment still requires human judgment, investigation, and decisions about what to test next.

PentAGI, short for Penetration Testing AGI, takes a different approach. It is an open-source, self-hosted multi-agent system designed to automate penetration-testing workflows from a natural-language description of a target and an assessment goal. Instead of relying on a single tool or a fixed sequence of checks, it coordinates specialized AI agents to plan tasks, research potential weaknesses, select testing strategies, and execute commands using more than 20 security tools, including Nmap, Metasploit, and sqlmap.

The workflow brings planning, tool execution, and reporting into one system. PentAGI runs its testing operations within a Docker-based environment designed to isolate them from the host, then presents the results as a vulnerability report that can be viewed in the web interface, copied, or exported as Markdown or PDF. Developed by VXControl, a security engineering company based in Dubai, the project targets penetration testers, security engineers, researchers, and red teams who want to run AI-assisted assessments on infrastructure they control.

As with any autonomous security-testing system, isolation alone does not establish authorization to test a target or guarantee that every action is harmless. PentAGI is intended for authorized assessments, where the scope, permissions, and potential impact of testing remain important considerations.

Why Autonomous Pentesting Matters

A professional penetration test is expensive and infrequent. A thorough engagement from an external firm commonly costs somewhere between ten thousand and thirty thousand dollars, and most organizations can only justify doing this once a year. That leaves a long gap between assessments, during which new code ships, new dependencies are added, and new misconfigurations creep in, all without anyone actively trying to break the system from an attacker's perspective.

PentAGI is positioned to fill that gap. Because it runs on infrastructure the operator already owns, there is no per-engagement fee and no need to schedule time with an outside firm. The system can, in principle, be pointed at a target as often as needed, including every day of the year rather than once. That does not replace a professional engagement conducted by experienced humans, particularly for the most sophisticated or high stakes assessments, but it does provide a continuous layer of automated pressure testing that can catch regressions and obvious weaknesses long before the next scheduled audit.

The core requirement running through every part of the project is authorization. PentAGI is meant to be pointed only at systems the operator owns or has explicit written permission to test, and this expectation is stated directly in the project's usage terms. An autonomous system that can run real exploitation tools is powerful, and that power is only appropriate within a properly scoped and authorized engagement.

The Team Behind the Single Prompt

What happens after a single sentence is typed is the most distinctive part of PentAGI. The system does not treat the request as a single call to a single model. Instead, it delegates work across a team of specialized agents, each with a narrow role, similar in spirit to how a human penetration testing team might divide labor among a lead, a researcher, and operators.

An orchestrating layer breaks the overall goal into a sequence of tasks and subtasks. A research-oriented agent studies the target, gathers information about its technology stack, and looks up known weaknesses relevant to what it finds. A planning agent, sometimes called the developer or generator role depending on the stage, works out an approach for a given subtask. An execution agent then carries out that approach using real tools, running commands such as port scans, exploitation framework modules, or SQL injection probes, and observing the results.

This division of labor is not just an architectural preference. It reflects a practical reality about how large language models perform on complex, multi-step tasks. Asking a single agent to simultaneously plan an entire engagement, remember everything that has happened so far, and execute low-level tool commands tends to produce less reliable results than splitting those responsibilities among agents that can each focus on a narrower job with a cleaner context. The system includes a long list of specialized agent types, among them a primary reasoning agent, an assistant for interactive guidance, a generator for content and strategy, a refiner for improving on earlier attempts, an adviser for expert consultation, a reflector for catching failures, a searcher for information gathering, an enricher for expanding context, a coder for writing and analyzing code, an installer for environment setup, and a pentester agent focused specifically on security assessment tasks.

Professional Tools, Not Reinvented Wheels

A system that merely talks about security testing is far less useful than one that actually drives the tools professionals already trust. PentAGI ships with a built in suite of more than twenty professional security tools, including nmap for network scanning, Metasploit for exploitation, and sqlmap for automated SQL injection testing, alongside many others that cover reconnaissance, exploitation, and post-exploitation needs.

Because these tools run inside sandboxed Docker containers rather than directly on the operator's host, the system can invoke genuinely powerful and sometimes destructive utilities without putting the operator's own environment at risk. The platform also includes smart container management, which automatically selects an appropriate Docker image based on the specific requirements of a task, so an agent working on a web application assessment is not stuck with a bare-minimum image lacking the tools it needs.

Beyond the core toolset, the system extends its reach into the web itself through a built in browser style scraper for gathering current information from online sources, and through integration with external search systems. Supported search providers include Tavily, Firecrawl, Traversaal, Perplexity, DuckDuckGo, Google Custom Search, a specialized search tool for exploit databases called Sploitus, and SearXNG as a meta search aggregator. This matters because an effective penetration tester does not rely purely on built-in knowledge. Effective testing often requires looking up the latest disclosed vulnerabilities, checking for recent proof of concept exploits, or researching an unfamiliar piece of software encountered on the target. Giving the agents the same research capability a human tester would use closes an important gap.

Memory That Persists Across Sessions

One of the most practical advantages of PentAGI over a plain chat-based assistant is memory. Every command run and every result observed during a flow is stored, which means a later test does not start from zero. If an approach already worked against a particular target or a particular type of target, that knowledge is retained and can inform future attempts, rather than being rediscovered from scratch every single session.

This persistent storage is built on PostgreSQL with the pgvector extension, which allows the system to store and search information using vector embeddings in addition to standard relational data. All commands and their outputs land in this store, giving the platform a durable record it can draw on later.

For teams or individuals running repeated engagements against the same application as it evolves over time, this persistent memory is a significant advantage. Rather than an assistant that forgets everything between conversations, the system behaves more like an analyst who has worked on this particular target before and remembers what has already been tried.

An Optional Knowledge Graph for Deeper Context

Beyond the core vector-based memory, PentAGI offers an optional integration with a knowledge graph system built on technology called Graphiti, which itself runs on the Neo4j graph database. When enabled, this layer tracks semantic relationships among hosts, services, findings, tools, and techniques, building up a structured picture of how everything observed during an engagement connects to everything else.

Where the primary memory system is good at recalling what happened, a knowledge graph is particularly good at answering questions about relationships: which hosts share a vulnerable service, which successful techniques tend to be followed by which further discoveries, or how a particular finding relates to earlier evidence gathered elsewhere in the same engagement. The project describes this as semantic relationship tracking and advanced context understanding, and it complements rather than replaces the primary memory system.

This feature is explicitly marked as optional and currently in beta, and it is disabled by default. Enabling it introduces additional infrastructure, additional model calls for extraction of structured knowledge from agent interactions, and therefore additional cost, so it is best treated as something to turn on deliberately for engagements where that deeper relational understanding is worth the overhead, rather than something enabled blindly on every deployment.

Watching the Agents Work: Monitoring and Self-Correction

Autonomous systems that take real actions need real oversight, and PentAGI builds supervision directly into its architecture rather than treating it as an afterthought.

The platform includes what it calls execution monitoring. When enabled, the system watches for patterns that suggest an agent has gotten stuck: repeating the same tool call too many times, or accumulating too many total tool calls without making meaningful progress toward the goal of the current subtask. When these thresholds are crossed, an adviser agent is automatically invoked. This adviser analyzes whether the acting agent is actually advancing toward its objective, detects loops and inefficiencies, and recommends alternative strategies when the current approach is failing. It can also suggest searching for established solutions rather than letting an agent reinvent an approach from first principles.

A related capability is intelligent task planning. Before specialist agents begin work on a subtask, a planner, which is the adviser agent operating in a planning mode, generates a focused set of several specific, actionable steps based on full context gathered by an enrichment agent. This structured plan keeps agents focused on the current subtask rather than drifting into unrelated territory, and it highlights critical actions, likely pitfalls, and points where results should be verified before moving forward.

Both of these supervision mechanisms carry a real cost. Enabling them tends to increase execution time and token consumption by a factor of roughly two to three, because the system is now spending extra effort on analysis and planning rather than purely on action. In exchange, testing on a smaller open-weight model reportedly showed about twice the improvement in result quality when both monitoring and planning were switched on, compared to running without that supervision. For teams using smaller or less capable open models, particularly in air-gapped or fully offline environments where only local inference is available, this kind of built-in correction mechanism can be the difference between a test that wanders in circles and one that actually completes its objective.

Beneath these optional layers sit hard limits that are always active, regardless of configuration. General-purpose agents and more narrowly scoped agents each have a maximum number of tool calls they are permitted to make, which prevents a runaway process from consuming unbounded resources. A reflector mechanism also activates automatically whenever the underlying model fails to produce a valid tool call after a few attempts, stepping in to guide the agent back toward proper tool usage or toward a graceful stopping point.

Running on the Model of Your Choice

A notable design decision in PentAGI is its refusal to lock operators into a single model provider. The platform supports more than ten large language model providers directly, including OpenAI, Anthropic, Google's Gemini, Amazon Bedrock, and a growing list of providers with strong reasoning or coding-focused models, among them DeepSeek, GLM from Zhipu AI, Kimi from Moonshot AI, Qwen from Alibaba Cloud, MiniMax, Mistral, and xAI. On top of these named providers, a generic custom configuration accepts any endpoint compatible with the OpenAI chat completions format, which covers Azure OpenAI deployments and numerous aggregator services as well.

For operators who want zero-cost inference or who need to keep everything entirely within their own network, Ollama support allows the system to run against locally hosted models with no cloud dependency at all. The project even documents a production-grade local deployment using vLLM together with a capable open-weight model, demonstrating that a fully local, cloud-independent setup is a genuinely supported path rather than an afterthought.

This flexibility extends down to the level of individual agents. Rather than forcing every agent in the system to use the same model, PentAGI allows different agent roles to be configured with different models through per-agent provider configuration files. A common pattern across the supported providers is to assign a fast, inexpensive model to simple or high-frequency roles such as basic completions and reflection, while reserving a stronger and more expensive model for roles that demand deeper reasoning, such as generating an attack strategy or advising when an agent is stuck. This lets an operator balance cost against capability rather than paying flagship model prices for every single step of the workflow.

Getting PentAGI Running

The project is designed to be approachable even for teams that are not deeply experienced with container orchestration. An interactive, terminal-based installer is available for Linux, macOS, and Windows, and it walks through system checks, environment configuration, provider setup for whichever language model and search services will be used, and basic security hardening before finally deploying the stack with Docker Compose.

Embedded content

The minimum system requirements are modest by modern standards: two virtual CPUs, four gigabytes of RAM, twenty gigabytes of free disk space, and an internet connection for downloading container images and updates. A typical quick installation on Linux looks like creating a directory, downloading the installer archive, extracting it, and running the interactive program:

mkdir -p pentagi && cd pentagi
wget -O installer.zip https://pentagi.com/downloads/linux/amd64/installer-latest.zip
unzip installer.zip
./installer

mkdir -p pentagi && cd pentagi
wget -O installer.zip https://pentagi.com/downloads/linux/amd64/installer-latest.zip
unzip installer.zip
./installer

Because the installer needs to interact with the Docker daemon to manage containers, it typically needs elevated access, either by running as root or by having the invoking user added to the Docker group on the host machine. The installer then takes care of verifying system requirements, writing a sensible environment configuration, setting up whichever model and search providers the operator chooses, generating secure credentials, and finally starting the full stack.

A manual installation path also exists for operators who prefer full control, which involves creating a working directory, fetching an example environment file, filling in the required API keys for at least one language model provider, adjusting security-related settings such as cookie signing salts and credentials, and then starting the stack directly:

curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/master/docker-compose.yml
docker compose up -d

curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/master/docker-compose.yml
docker compose up -d

Once running, the web interface becomes available locally, with a default administrator account provided for the very first login. Changing that default password immediately is an obvious and important first step before putting the instance to any real use.

For production deployments or anywhere security really matters, the project recommends a distributed two node architecture, where the actual worker operations that run penetration testing tools are isolated on a separate server from the main management backend. This separation provides a meaningful security boundary, keeping untrusted or potentially risky code execution away from the primary system, and it supports dedicated network isolation along with handling for out-of-band techniques such as reverse shell callbacks that need their own open ports.

Using PentAGI Day to Day

Once the stack is running and an operator can log in, the central concept for everyday use is the flow. A new flow can be created in one of two modes. Automation mode runs fully autonomously toward a stated testing goal from start to finish. Assistant mode instead offers an interactive, back-and-forth style of engagement where a human steers the investigation step by step, optionally still delegating subtasks to specialized agents when the investigation grows complex enough to benefit from that division of labor.

A good first prompt for a flow typically names the target system, describes the type of assessment wanted, states any scope limitations or rules of engagement, and specifies the kind of result expected, whether that is a full vulnerability report or validation of a specific hypothesis about how the application might be vulnerable. A representative example looks like describing a target web application, asking the system to focus on authentication, file handling, and injection issues, instructing it to stay strictly within the provided target, and asking it to summarize confirmed findings along with reproduction steps.

After a flow is submitted, the interface opens the flow page automatically, where an operator can watch messages, agent activity, and task progress unfold in close to real time, inspect the raw terminal output of tools as they run, and review the tasks and subtasks the system has generated to understand exactly what it is doing and why. Once enough results have accumulated, a report can be opened directly in the browser, copied to the clipboard, or downloaded as either a Markdown file or a PDF document.

Every flow also exposes an assistant view that allows a human to step in and redirect an active, otherwise autonomous run. This is particularly useful when an automated pass surfaces something unexpected that calls for human judgment rather than a hard restart of the whole engagement. Through this view, an operator can check the current status of the flow, stop whatever task is currently running, submit new follow-up instructions, or adjust the remaining planned subtasks before the next step executes, all without losing the context and progress already accumulated.

Each flow also keeps its own scoped set of files, separated from every other flow on the system. Files can be uploaded directly through the interface, attached from a reusable personal resource library, or pulled as read-only snapshots from inside the running agent container for inspection. Files that an operator uploads, along with any attached resources, are automatically made available to the running agents inside the sandbox and are referenced in the agent's own system prompts, so the assistant and automation agents can work with them by path without needing the raw contents pasted directly into the conversation.

Programmatic Access Through REST and GraphQL

Beyond the web interface, PentAGI exposes comprehensive REST and GraphQL APIs, which makes it straightforward to fold autonomous testing into existing automation pipelines, continuous integration processes, or custom internal tooling rather than relying purely on manual, interactive use through the browser.

Access to these APIs is controlled through bearer tokens generated from the settings area of the web interface. Each token can be given a descriptive name and an expiration date ranging anywhere from a single minute up to three years, and because the full token value is shown only once at creation time, it needs to be copied and stored securely immediately. A token inherits the permissions of the user account that created it.

Using a token in practice is a matter of including it as a bearer credential in the authorization header of an HTTP request. A GraphQL query to list flows might look like this:

curl -X POST https://your-pentagi-instance:8443/api/v1/graphql \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query": "{ flows { id title status } }"}'

curl -X POST https://your-pentagi-instance:8443/api/v1/graphql \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query": "{ flows { id title status } }"}'

A roughly equivalent request against the REST interface looks like this:

curl https://your-pentagi-instance:8443/api/v1/flows \
  -H "Authorization: Bearer YOUR_API_TOKEN"

curl https://your-pentagi-instance:8443/api/v1/flows \
  -H "Authorization: Bearer YOUR_API_TOKEN"

For teams exploring the API interactively, an integrated GraphQL playground and a Swagger-based documentation page for the REST endpoints are both available once the instance is running, and type-safe client code can be generated automatically from the published GraphQL schema or OpenAPI specification using any of several widely used code generation tools. Sensible operational hygiene applies here just as it would for any other API credential: tokens should never be committed to version control, should be rotated periodically, should be scoped separately per application where practical, and their usage should be monitored and unused tokens revoked.

Monitoring, Analytics, and Observability

Because autonomous agents are taking real actions with real consequences, visibility into what the system is doing matters a great deal, and PentAGI treats observability as a first-class concern rather than an afterthought bolted on later.

An optional monitoring stack built around OpenTelemetry for unified data collection, Grafana for real-time dashboards and alerting, VictoriaMetrics for efficient time series metrics storage, Jaeger for distributed tracing that helps with debugging complex multi-agent interactions, and Loki for scalable log aggregation, gives operators the same kind of operational insight they would expect from any serious production system.

A separate but complementary analytics layer centers on Langfuse, which specializes specifically in large language model observability, letting an operator dig into token usage, latency, and the detailed behavior of individual model calls across the whole system. This layer is backed by ClickHouse for analytical storage, Redis for caching, and MinIO for storing larger artifacts in an S3-compatible way.

Both of these optional stacks can be enabled independently of each other and run alongside the core platform using their own separate Docker Compose files, so an operator can choose to bring in exactly the amount of observability that suits a given deployment without being forced to adopt the full set if only basic usage is needed.

A Practical Note on Scope and Responsibility

It is worth stating plainly what PentAGI is and what it is not. The project describes itself today as an autonomous and assistant-guided penetration testing platform, not a predefined campaign-style breach and attack simulation product with fixed adversary emulation scripts. Capabilities around agent-authored attack scripts in that style are described as conceptual or future work rather than something already implemented and ready to rely on.

The system is genuinely powerful, and that power comes with genuine responsibility. Because it can run real exploitation tools against real targets, the single rule that governs every legitimate use of the platform is authorization: only point it at systems that are owned outright or for which explicit written permission to test has been obtained. This expectation is written directly into the project's end user license terms, and it deserves to be treated as a hard boundary rather than a formality, exactly the same way it would be treated before launching any traditional, human-driven penetration test.

Final Thoughts

Someone built a team of AI hackers that breaks into your app on its own, finds the holes, and hands you the report.

It's called PentAGI, short for Penetration Testing AGI. 25,500 developers have already starred it.

Here's how it works.

You type one sentence, like "test my web app for login and injection bugs."

Then the team goes to work:

An orchestrator splits the job into tasks, a researcher studies the target and looks up known weak spots, a developer plans the attack, and an executor runs it with real tools: nmap, Metasploit, sqlmap, and 20+ more.

Everything runs inside an isolated Docker sandbox, never on your own machine.

When it's done, you get a full vulnerability report. Web view, Markdown, or PDF.

Here's the part that got me.

It remembers. Every command and result gets stored, so the next test starts from what already worked. Turn on the optional knowledge graph, and it maps how targets, actions, and results connect.

It also catches itself. Switch on execution monitoring, and if an agent repeats the same move 5 times, an adviser agent steps in, works out why, and forces a new angle.

The team tested this on a small local model, Qwen3.5–27B. With the adviser switched on, results came out 2x better.

And it runs on whatever you want. OpenAI, Claude, Gemini, DeepSeek, or fully local through Ollama. Run it locally, and nothing leaves your network.

Minimum to start: 2 CPUs, 4GB RAM, 20GB disk. An installer walks you through the rest.

One rule. Only point it at systems you own or have written permission to test. The project's EULA says the same.

A real pentest costs $10K to $30K and happens once a year.

This runs the other 364 days for free.

The repository is available at: https://github.com/vxcontrol/pentagi