PentAGI Alternative: Open-Source vs Managed Pentest

If you are looking for a PentAGI alternative, or trying to work out whether PentAGI means you can stop paying for penetration tests, the honest answer has two halves. PentAGI is a genuinely good piece of engineering that a competent team can run and get real findings from. It also cannot produce the one artefact most people are actually shopping for when they buy a pentest, and that has nothing to do with how well it is built.

The Slack Message That Starts This

Someone on your team posts a GitHub link in #security with a one-line comment: "why are we paying for pentests?" Nobody argues. The repo has more stars than most of the tools in your production stack, the architecture diagram in the README is legitimately interesting, and the licence is MIT. Within an hour someone has volunteered to spin it up on a spare box "just to see".

That is a fair question asked in good faith, and it deserves a real answer rather than a defensive one. So here is the thesis first. PentAGI is good engineering. The cost of running it is not zero, and most of that cost is not in the parts people look at when they are excited about a repo. And the thing your auditor, your enterprise customer, or your insurer asked for is not a finding list. All three are true at once, which is why this conversation goes sideways: everyone in the thread is right about a different thing.

There are two ways this Slack thread ends badly.

The first is quiet and financial. You adopt a piece of free software and discover you have taken on a small infrastructure programme: a multi-service stack, a database with a vector extension, optionally a graph database, an observability layer, and an inference bill that scales with how autonomously the thing runs. None of that was in the budget line, because the budget line said "free". The software is free. The system is not the software.

The second is loud and lands on a deadline. Nine months later you are in audit week, or a $400k deal is sitting at security review, and you hand over output your own tooling produced, about your own systems, from a stack your own team runs. The person on the other side asks who performed the test. There is no good answer at that point, because the answer needed to be arranged months earlier.

Neither failure is a criticism of PentAGI. Both are a criticism of assuming a tool and an attestation are the same category of thing. Before that distinction, the tool deserves a fair hearing.

What PentAGI Actually Is (the Generous Version)

PentAGI is an open-source autonomous penetration testing system from the PentAGI Development Team, published under the MIT licence at github.com/vxcontrol/pentagi. As at August 2026 it sits at roughly 21.8k stars, well past the threshold where a project is one person's weekend experiment, and it picked up mainstream security press coverage in April 2026 including a write-up in Help Net Security.

Architecturally it is a multi-agent system, not a scanner with a language model bolted to the front. An orchestrator coordinates multiple specialist agents. The researcher, developer and executor loop is the visible core, and the project's own prompt-engineering documentation names further roles alongside it: searcher, adviser, memorist, pentester, and installer, each with its own prompt template. We are not putting a total on the cast, because the project does not publish one. The division of labour is the point: the agent that decides what to investigate is not the agent that writes the payload, which is not the agent that runs it. That separation is what lets the system pursue a multi-step objective rather than emit a list of independent checks.

Execution is sandboxed in Docker, with pentest tasks defaulting to the project's own Kali Linux image carrying 20 or more standard tools including nmap, Metasploit, and sqlmap. That matters more than it sounds: the system is not asking a model to imagine what nmap would return, it is running nmap and reading the output. Findings are grounded in tool execution.

Findings and context persist in PostgreSQL with pgvector, stored as embeddings, so the system queries its own prior knowledge semantically rather than by string match. A later agent can retrieve "we found something like this on a different host" without anyone having written the grep. On top sits an optional Graphiti knowledge graph on Neo4j, persisting entity relationships across sessions rather than within one run.

The model layer is deliberately unopinionated: the project claims ten or more providers, with OpenAI, Anthropic, Google Gemini, AWS Bedrock, Ollama, DeepSeek, and OpenRouter among them. You choose the provider, and with it the price and the data-handling posture. Around all of that sits an optional but full observability stack: Grafana, Loki, Jaeger, VictoriaMetrics, and Langfuse for LLM-specific tracing. Whoever designed this expected people to need to debug agent behaviour in anger, which is a mature assumption to have made.

Where It Is Genuinely Excellent

Cross-session memory is a real architectural idea, not a feature bullet. Most security tooling is amnesiac: every run starts from zero and rediscovers the same context. A system that carries entity relationships between engagements is doing something structurally different, and pgvector plus a knowledge graph is a credible way to do it.

Provider flexibility means no model vendor lock. If your provider changes its pricing, its terms, or its safety posture in a way you dislike, you change a config value. Very few commercial tools give you that lever. Ollama support goes further and lets you drive the agents from locally hosted models, so no testing data reaches an external model provider at all. If your data cannot cross that boundary, it is a capability worth weighing seriously, and it is not one we offer. Worth being precise, though: removing model-provider egress is not the same as an air-gapped build, since the project still expects internet access for image pulls and updates.

And the sandboxing is thoughtful. Isolating tool execution in containers, with documented guidance on separating the execution host from the control plane, reflects someone having thought carefully about what happens when an autonomous system is holding exploitation tooling. That is not a given in this category.

None of that is faint praise and none of it needs a caveat. The caveats are about operating it, not about the design.

The Bill for Free Software

The documented footprint is 2+ vCPU, 4+ GB RAM, 20+ GB disk, and that is the only sizing figure published. There is no recommended number to size against, which is the first thing to notice: a stated floor is the number at which software starts, not the number at which it works. Whatever you actually need, you will find out by running it.

What lands on your infrastructure is easy to under-read, because the core Compose file looks modest. Four services: the PentAGI application container serving both API and UI, PostgreSQL with pgvector, a Postgres metrics exporter, and an isolated browser scraper. That is the number you see on your first docker compose up, and it is a fair reason to think this is a small deployment.

The optional stacks are where it grows. Observability ships as its own Compose file adding eight more services (Grafana, VictoriaMetrics, ClickHouse, Loki, Jaeger, an OpenTelemetry collector, node-exporter, and cAdvisor). Langfuse adds another six, including a second ClickHouse, MinIO, Redis, and a Postgres of its own. Graphiti adds Neo4j and the Graphiti service. Enable everything and you are at roughly twenty containers. Every one is a real service with a real upgrade path, real disk consumption, and a real failure mode at 3am. You did not choose to run an observability platform. You chose a pentest agent, and an observability platform came with it.

Production guidance goes further. The project strongly recommends, for production or security-sensitive environments, a distributed two-node architecture that isolates worker operations on a separate server, with sandboxes reaching a hardened Docker-in-Docker daemon over TLS rather than through a mounted socket. That is correct advice and you should follow it. It is also a second host, two separate certificate authorities, and a network boundary to design, document, and maintain.

Laid out as a sequence, standing up a deployment you would actually trust in production looks like this.

Then there is the part nobody budgets. The software is free; the tokens are not. An autonomous multi-agent system is an inference-consumption machine by design: it reasons, executes, reasons about the result, and decides what to do next, across every agent role in the chain, for as long as the objective is unmet. The whole value proposition is that it keeps going without you, and that is exactly the property that makes token consumption hard to bound in advance.

One detail will bite you early, and it is a property of the provider rather than of PentAGI. If you route through AWS Bedrock, Bedrock applies per-model request and token quotas, and the defaults on a new account are low enough to throttle a busy multi-agent workload. Check the quotas for the exact models you have chosen in your region and raise them through AWS Service Quotas before your first real run. A multi-agent system throttled mid-run does not fail cleanly. It fails as a confusing, half-finished engagement that costs you tokens and tells you nothing. The same caution applies to any provider you pick: read its rate limits before you read its price list.

We are deliberately not putting a dollar figure on any of this, because any number we gave you would be wrong for your situation. Cost depends on your provider, your model choice, how aggressively and how often you let the agent run, and how many of the optional stacks you take on. What we can give you is the list of categories to price yourself: control-plane compute, isolated worker-node compute, storage for PostgreSQL and Neo4j and the log stack, inference tokens per engagement, and engineer-hours for setup, upgrades, and incident response. Price those five honestly against a vendor quote and you have a real comparison instead of a rhetorical one.

Cost you can at least forecast. The next set of considerations you cannot, because they are decisions rather than line items.

The Risks That Are Not in the README

Three things transfer to you the moment you self-host. None of them make PentAGI unsafe. All of them make it yours.

Data egress. Testing data flows to whichever LLM provider you configure: reconnaissance output, response bodies, error messages, and whatever else the agents pull in while working. Depending on the target that can include customer data, internal hostnames, or credential material that turned up somewhere it should not have. This is a data-classification decision, and somebody with authority needs to make it explicitly rather than letting it happen by default when an engineer picks a model in a config file. You can avoid the egress entirely with local models through Ollama, but be clear about the trade: more infrastructure, and generally lower model capability driving the agents.

Non-determinism. Autonomous agent behaviour is not fully deterministic and can drift from the target you intended. In most agentic applications drift is an annoyance. In a system holding exploitation tooling, drift is a scope-control problem. The blast radius of an agent that wanders is bounded by your network segmentation and your sandbox configuration, not by your intent. That is exactly why the project's two-node isolation guidance is worth taking seriously. We wrote about what happens when agent containment assumptions fail in practice, and the lesson generalises: the boundary you can prove is the boundary you have.

Authorisation. The repository carries two documents, and it is worth reading both. The source code is under the MIT licence. Alongside it sits an End User License Agreement granting a non-exclusive, non-transferable, revocable licence to use the software solely for lawful penetration testing, in environments where you have explicit permission from the network owner. The EULA states that where it conflicts with the MIT licence, the MIT terms prevail for the source code. None of that is unusual or unreasonable. What changes when you self-host is who carries the burden of proving lawfulness. When a vendor scopes an engagement, the scoping process is itself a guardrail: someone checks that you own the asset, that authorisation is in writing, and that the test window is agreed. Self-hosting removes that layer. The burden falls on the operator, which means it falls on whichever engineer typed the target into the interface. If a shared hosting provider, a SaaS vendor, or a cloud tenant neighbour is in the blast radius, that is now your legal exposure.

Handle these three and you have a running system producing real findings against systems you are authorised to test. Which is when a different kind of problem arrives.

The Question No Engine Can Answer

The system is up. It is finding things, some of which your last commercial engagement missed, which is satisfying and entirely plausible. Then a security questionnaire lands from a prospect, and somewhere around page four is a line asking whether a third-party penetration test was performed in the last twelve months.

Let us be scrupulously fair about what the frameworks actually say, because the sloppy version of this argument is that self-run testing is worthless, and that is not true. PCI DSS v4.0.1 requirements 11.4.2 and 11.4.3, covering internal and external penetration testing respectively, each expressly permit the work to be done by a qualified internal resource or a qualified external third party, provided organisational independence of the tester exists. The standard adds that the tester is not required to be a QSA or an ASV. Requirement 11.4.1, separately, is what obliges you to have a documented, industry-accepted methodology in the first place. So the requirement is not "buy from a vendor". It is competence, independence, and a methodology you can hand over. We go through the detail in our guide to PCI DSS 4.0 penetration testing requirements.

The narrower and more useful claim is this: when the person asking sits outside your organisation, they generally want evidence produced outside it too. An auditor assessing your controls, a prospect assessing your risk, an insurer pricing your policy, a regulator reviewing your programme. Each is solving the same problem, which is that they cannot verify your self-assessment without doing the work themselves. Independence is a shortcut for that verification problem, not a ritual.

The sequence below is illustrative rather than a customer account, but it is the shape the problem almost always takes, and the ordering is the point.

Separating three terms resolves almost all of the argument.

A finding is a statement that something is broken: the header is missing, the endpoint accepts an unauthenticated request, the parameter is injectable. PentAGI produces findings, from real tool execution, which is more than a lot of things claiming the label.

A report is findings organised with scope, methodology, severity ratings, evidence, and remediation guidance. That is a formatting and process problem, and a competent team could build a pipeline that produces one. Nothing structural is in the way.

An attestation is a named professional, independent of you, putting their credential and their professional accountability behind the assertion that this test was performed, in this scope, to this methodology. That is what the questionnaire is asking for, and it is what no self-hosted engine can produce. Not because of any engineering deficiency, and not because the findings are worse. It is structural: the attesting party would be the party being assessed. A signature is worth something precisely because the signer has something to lose and no stake in the outcome. Run the tool yourself and both properties are gone, whatever the quality of the output.

This is why "our findings are better than the vendor's" is a true statement that does not help. It answers a technical question when the question asked is an accountability question. We unpacked what auditors actually check when AI-generated pentest output turns up in an audit, and the pattern holds regardless of which engine produced it.

PentAGI vs a Managed Pentest, Side by Side

The middle rows are not a quality comparison. They compare what each thing structurally is. A self-hosted agent can outperform a vendor on finding count and still be the wrong artefact for a procurement conversation, and a signed report can contain fewer findings and still be the only thing that closes the deal.

Verified August 2026 against the public repository and documentation. If any detail here has drifted, tell us and we will correct it: we would rather be accurate than flattering. If you are asking the same question about a cloud-native agent rather than an open-source one, the sibling analysis is AWS Security Agent versus an independent pentest.

Who Should Actually Run PentAGI

Plenty of teams should, and it would be dishonest to write this post without saying so clearly.

Run it if you are a solo researcher or a red team with the operating capacity to own a multi-service stack across two hosts and the judgement to scope your own targets. Run it if you have an internal security function and want coverage in the gaps between engagements, because the gap between annual tests is where regressions live. Run it if you want to learn how multi-agent security architecture actually works, because reading this codebase beats any amount of vendor marketing about agents. And run it for pre-audit hygiene, so the engagement you are paying for finds interesting things rather than burning its first day on missing headers and expired certificates.

Do not run it if nobody owns the stack on Monday morning. An unmaintained security tool holding credentials and exploitation tooling is worse than no tool. Do not run it if your testing data cannot leave your boundary and you cannot realistically run local models well, because the honest version of that constraint is a much bigger project than the one you signed up for. Do not run it if your driver is a compliance deadline with a third-party requirement attached, because you will spend three months building something that does not answer the question. And do not run it if the answer to "who maintains this in six months" is silence in the channel.

If pre-engagement hygiene is what you are after and you are not ready to run a full stack for it, start smaller. Our free security check gives you an external view in minutes, and the header checker, SSL checker, and subdomain finder cover what most often wastes the opening hours of a paid engagement. On the general question of how far automation gets you, we worked through the boundary in when automated pentesting is enough.

Running Both, in the Right Order

The framing that causes all the trouble is treating this as a purchase decision with one winner. These two things do different jobs, and the sequence matters more than the choice.

The agent runs in your pipeline. It catches regressions between engagements, gives your engineers a fast feedback loop, and means your application is probed more than once a year. The independent scoped engagement produces the artefact that leaves the building: it goes to the auditor, into the data room, to the prospect's security team, and to the insurer. It is the document with a name on it.

Run in that order and the first improves the second. A team that has been self-testing all year hands over a cleaner surface, so the paid engagement starts on the interesting parts of it instead of the obvious ones. Better report, same money.

Be clear-eyed about what the paid engagement covers too. We handle the systematic 80 percent of an attack surface properly and we sign for it. Genuinely novel business logic, the multi-step authorisation abuse that depends on knowing what your application is for, still rewards human creativity beyond what any automated approach reaches, ours included. If your application moves money or manages multi-tenant permissions, budget for that separately rather than assuming any engine or any engagement absorbs it.

For the second half: with CyberOrbit you set your own targets, our platform scopes and runs the assessment, and a certified security professional independently reviews and signs the completed report you select, which comes back within 48 hours of scope sign-off. A retest is included, with no second statement of work once you have fixed things. That pitch is deliberately narrow, because the first half of the sequence is a job you can do yourself with tools like PentAGI.

To decide whether you need the independent signed report at all, work through these. Any one is enough.

If none apply, run the agent and spend the budget elsewhere. If any one applies, keep running the agent, and understand that it is not the thing that closes the gap. Pricing is on the pricing page, and if you want to talk through where the line sits for your situation, get in touch. We will tell you honestly if you do not need us yet.

Frequently Asked Questions