RedAmon: an agentic red team framework that runs recon, exploitation and patching in one pipeline
An AI-powered agentic red team framework that automates offensive security operations, from reconnaissance to exploitation to post-exploitation, with zero human intervention.
At a glance
- What is it?
- RedAmon is an MIT-licensed Python framework that chains reconnaissance, exploitation and post-exploitation into a single agent pipeline, then triages findings and opens pull requests. Here is what the repository documents, how the Docker install works, and where the design shows its edges.
- Who is it for?
- Adopt RedAmon if you already run authorized offensive engagements and want the recon-to-report loop automated, and if you can give it a dedicated host: the compose file sizes Postgres from host RAM and the GVM feed sync takes roughly 10 to 15 minutes on first run. Skip it if you need a lightweight scanner on a laptop, or if you cannot grant an agent write access to a repository for the CypherFix remediation step.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What RedAmon automates that a scanner does not
A conventional scanner hands you a list. RedAmon's README frames the project as an autonomous framework that chains reconnaissance, exploitation and post-exploitation into a single pipeline, and then goes further by triaging every finding, implementing code fixes and opening pull requests on your repository. That last clause is the part worth pausing on. Most offensive tooling stops at the finding; RedAmon's stated scope continues into remediation and a merge request, which is a software-engineering workflow, not a security-tooling one.
The intended user is a red teamer or pentester working under written authorization, on a target they own or are contracted to test. The README carries a legal disclaimer in bold at the top and points to a separate DISCLAIMER.md. That is not boilerplate here: an agent that discovers an exploit and then writes a patch touches production code, and the repository is explicit that use is limited to authorized testing, education and research.
The project's headline claim is a benchmark result. According to the README, RedAmon solves 101 of 104 problems (97.1%) on the XBOW web-security benchmark fully black-box, described as the leading open-source black-box score on that corpus. The README also states that every solve ships a complete raw agent session and a reproducible walkthrough. Treat the percentage as a claim to audit, not a fact to quote; the accompanying sessions are what make auditing possible at all.
The Neo4j knowledge graph is the actual architecture
The mechanism the README describes is a shared knowledge graph rather than a linear scan script. Multiple reconnaissance tools launch in parallel, each feeding results into the graph in real time. Tools adapt their scope based on live discoveries and coordinate without manual intervention, so subdomains, ports, endpoints and parameters accumulate as connected nodes instead of separate report files. Neo4j is the store, and the repository ships a graph_db/ directory alongside recon/, recon_orchestrator/, agentic/, mcp/, scanners/ and webapp/.
That layout tells you where the seams are. recon_orchestrator/ is the coordinator that fans work out to the tools under scanners/ and recon/. agentic/ holds the agent logic, and mcp/ suggests the agent reaches its tools through the Model Context Protocol rather than hardcoded shell calls. The webapp/ tier is a separate service that talks to the databases, and .env.example lists distinct keys for each hop: AUTH_SECRET for webapp JWT signing, INTERNAL_API_KEY for webapp-to-agent and webapp-to-service auth, ORCHESTRATOR_API_KEY for the webapp-to-recon-orchestrator link using an X-Orchestrator-Key header, and SCANNER_API_KEY as a scoped token injected into scan containers instead of the master internal key.
That last detail is a real design decision. Per .env.example, SCANNER_API_KEY is accepted only on GET /api/users/[id]/settings, GET /api/projects/[id] and the agent /llm/* routes, and cannot mint admins or read llm-providers. Scan containers are the least trusted part of an offensive pipeline because they run against target networks, so giving them a token that cannot escalate is the right shape. The README does not document what happens when a scanner container is compromised beyond that token scope, and no threat model for that scenario appears in the repository.
Installing RedAmon with Docker Compose and redamon.sh
The repository ships docker-compose.yml at the top level, plus docker-compose.dev.yml and docker-compose.gpu.yml variants. The compose file's own header comments give the start, stop and log commands, and note that the GVM scanner starts automatically with the default up command. First run takes roughly 10 to 15 minutes for feed sync, according to those comments.
docker compose up -d
docker compose logs -f
docker compose downBefore that, copy .env.example to .env. The example file is explicit that you normally do not set the secrets yourself: redamon.sh install, up and update generate strong random values into the real .env on a fresh install. POSTGRES_PASSWORD and NEO4J_PASSWORD are required, and the database containers refuse to start if they are unset.
cp .env.example .env
./redamon.sh installThe GVM credentials deserve attention because they are the one place two systems must agree. The compose header states that gvmd auto-creates admin/admin, after which redamon.sh install --gvm rotates it to a strong GVM_PASSWORD pinned in .env, and that both sides read GVM_PASSWORD. To change it later, the documented path is:
docker compose exec -u gvmd gvmd gvmd --user=admin --new-password='<password>'After that you set the same value as GVM_PASSWORD in .env and recreate recon-orchestrator. The header warns to keep them in sync. The same warning applies to the database passwords: .env.example notes that POSTGRES_PASSWORD and NEO4J_PASSWORD are baked into the data volumes at first init, so changing them after the volumes exist locks you out, and redamon.sh detects this and warns rather than rewriting. There is also a build profile for the tool images:
docker compose --profile tools buildThe README does not walk through a first scan end to end, so the practical entry point is the webapp tier once the stack is up.
Where RedAmon is the wrong tool
The resource footprint rules it out for casual use. The compose file sizes Postgres with mem_limit, pids_limit and cpus values that redamon.sh derives from host RAM, and it ships a GPU compose variant. Running Postgres, Neo4j and a GVM scanner with 185,000-plus detection rules is a server workload, not a laptop one. If your need is a single nmap sweep and a report, this stack is several orders of magnitude more machinery than the task.
The autonomous framing is the second constraint. RedAmon's own README describes the pipeline as operating with human oversight at every critical step, which is a sensible design but sits in tension with the repository description's zero-human-intervention phrasing. Budget for a human in the loop regardless of which sentence you read first.
The third issue is upgrade behavior. Release v6.14.1 is titled "update no longer refuses to pull after a scan", which tells you that before that version, an update could be blocked while a scan was in flight. If you are on an earlier release, expect the updater to interact badly with running scans. The release notes for that fix are the only source here; the README does not document rollback, and there is no documented downgrade path for a version that has already migrated the database volumes.
Finally, CypherFix, the auto-remediation component, opens pull requests on your repository. That is a write operation against source code performed by an agent. Teams that cannot accept automated commits to a protected branch should disable or ignore that part of the pipeline rather than run it against a real repo.
RedAmon compared with PentAGI and HexStrike AI
The searches that surround this project name PentAGI and HexStrike AI as peers, and the comparison is real rather than cosmetic. All three sit in the agentic pentesting category, where an LLM drives tool calls instead of a human typing them.
The difference worth understanding is where each stops. RedAmon's stated pipeline continues past exploitation into triage, code fixes and pull requests, and it stores findings in a Neo4j graph that persists across the run. A graph-backed model means a later stage can query earlier discoveries as relationships, which is how the recon tools adapt scope mid-run. HexStrike AI is described in the searches as an AI tool for offensive security, and PentAGI as an autonomous pentesting agent; neither is documented in this repository, so any claim about their internals belongs to their own projects, not here.
The practical selection question is integration surface. RedAmon wires Metasploit and OpenVAS directly into the compose stack and exposes an MCP layer for agent tool access. If your existing toolchain already standardizes on MCP, that is a shorter path than adapting a tool that assumes shell invocation. If you want a single binary you can run against one host, none of these agent frameworks is the right shape.
Licence, maintenance and the cost of staying current
RedAmon is MIT licensed, and the repository carries a THIRD-PARTY-LICENSES.md file. That file matters more than usual because the stack bundles Metasploit, OpenVAS, mitmproxy and a large detection-rule corpus. MIT covers RedAmon's own code; it does not relicense what it pulls in, and some of those components carry their own terms. Read THIRD-PARTY-LICENSES.md before redistributing a bundled image, and treat that as an engineering checklist item rather than a legal opinion.
Maintenance looks current. The last push was on 2026-09-14, two days before this writing, and the repository is not archived. Recent releases run from v6.2.2 in late July 2026 through v6.2.5 and v6.14.1 in September, so the version numbering is not strictly sequential and you should read release titles rather than assume a linear progression.
Upgrade cost is dominated by the databases. Because POSTGRES_PASSWORD and NEO4J_PASSWORD are baked into volumes at first init, a careless rotation is an outage, and redamon.sh warns rather than repairs. The GVM feed sync adds roughly 10 to 15 minutes to a cold start, which is the number to plan around if you tear the stack down between engagements. The repository also ships AGENTS.md and CLAUDE.md at the top level, which suggests the agent behaviour is configured through files you will need to read before changing anything about how it reasons.
Editorial conclusion
Adopt RedAmon if you already run authorized offensive engagements and want the recon-to-report loop automated, and if you can give it a dedicated host: the compose file sizes Postgres from host RAM and the GVM feed sync takes roughly 10 to 15 minutes on first run. Skip it if you need a lightweight scanner on a laptop, or if you cannot grant an agent write access to a repository for the CypherFix remediation step. Before trusting it, verify two things yourself: read the XBOW scorecard rows and their raw sessions rather than the headline percentage, and confirm your GVM_PASSWORD in .env matches what gvmd holds, because the two sides read the same variable and drift locks you out.
Frequently asked questions
What is meant by red teaming?
The repository does not define the term. It describes RedAmon's own scope as authorized security testing, educational purposes and research only, and points to a separate DISCLAIMER.md for the full statement.
Which AI tool is best for red teaming?
The repository does not rank tools. It states that RedAmon solves 101 of 104 (97.1%) of the XBOW web-security benchmark fully black-box, described as the leading open-source black-box score on that corpus, and ships raw agent sessions so the claim can be audited.
What is the role of a red teamer?
The repository does not describe the role in general terms. It positions RedAmon for authorized security testing, educational purposes and research, and its README describes the pipeline as operating with human oversight at every critical step.
What is llm red teaming?
The repository does not define LLM red teaming. It does ship an AI Gauntlet wiki page labelled offensive AI testing, and lists agentic-ai and cybersecurity among its topics, but the README does not explain the term.
Community notes