Darkmoon

Darkmoon is an open-source autonomous penetration testing platform published under GPL-3.0 by ASC-IT, a security firm based in Toulouse, France. Mehdi Boutayeb is its lead maintainer.

It belongs to the same wave as Strix and RunSybil : AI agents that run an offensive campaign end to end rather than matching signatures the way a classic DAST scanner does.

The project is young. The repository was created in November 2024 and carries 806 stars, 135 forks, and 8 contributor accounts as of August 2026.

Development is active rather than dormant. Thirty-nine commits landed in the 30 days to 3 August 2026, and an “Agents Expansion” release on 2 August added 16 new sub-agents.

What makes Darkmoon worth a look is not the agent count. It is the architecture: by design, the LLM does not execute tools directly, and real IP addresses are swapped for placeholders before a prompt leaves the machine.

What is Darkmoon?

Darkmoon is a self-hosted platform that runs a full penetration test from a single target string, then produces an evidence-backed report.

You give it a target. An orchestrator agent discovers the environment, fingerprints the stack, models the attack surface, and dispatches specialist sub-agents that match what it found.

The repository ships 50 Markdown agent definitions in conf/agents/: one orchestrator plus 49 technology specialists. Agents are plain Markdown, so they are readable, diffable, and version-controlled.

The agent definitions describe coverage of web applications and APIs, Active Directory, Kubernetes, cloud accounts, CI/CD, IaC, databases, secret stores, and IoT firmware images.

That is the scope the agent set claims. Only 6 of those planes ship as coded MCP workflows; the rest is agent instructions driving toolbox binaries.

Three components make up the runtime. OpenCode talks to the LLM and plans, while an MCP server executes approved actions.

A separate Docker toolbox holds the real offensive tooling, isolated from both the model and the host.

How does Darkmoon run an assessment?

A Darkmoon campaign starts with one line: TARGET: example.com. Everything after that is decided by Darkmoon’s orchestrator agent, not by a fixed tool sequence.

Reconnaissance comes first: port scanning, protocol detection, HTTP service discovery, banner analysis. The goal at this stage is understanding, not exploitation.

Fingerprinting then builds a technology profile from response headers and behaviour, and that profile drives which agents get dispatched. WordPress triggers the CMS agent, a GraphQL endpoint triggers the GraphQL agent.

The loop is reactive. When an agent finishes, its results are re-analysed, and newly discovered technologies can pull in further agents mid-campaign.

Findings are gated on evidence. A vulnerability is only promoted when the executed request, the payload, and the raw response exist; anything weaker is labelled UNCONFIRMED SIGNAL.

Credential-dependent planes are held back deliberately. Cloud, CI/CD, IaC, secret stores, databases, Active Directory, and Kubernetes agents fire only when a concrete artifact names that plane, or when you authorize them.

Help Net Security, which interviewed the maintainer in June 2026, described the toolbox as an isolated Docker container holding more than fifty security utilities .

Several of those binaries have their own pages here. The template scanner is Nuclei , and the Kubernetes side leans on kubescape and kube-bench .

Scope control is command-line shaped. Flags such as OUT, EXCLUDE, FOCUS, NOISE, SEVERITY, and SAFE_HARBOR narrow the engagement, and any flag after the URL switches the run into bug-bounty mode.

What does Darkmoon’s Privacy Gateway do?

Darkmoon’s Privacy Gateway tokenizes sensitive values before any prompt leaves your machine. It is the feature ASC-IT leads with, and the one that separates Darkmoon from Strix and RunSybil .

Autonomous pentest agents have an awkward property: to reason about your infrastructure, they normally have to send your infrastructure to a model provider. Real IPs, real hostnames, real credentials.

The Privacy Gateway breaks that. Sensitive values are replaced with deterministic placeholders like IP_PRIVATE_001 and HOST_INTERNAL_001 before the prompt leaves the machine.

Real values are reinjected locally, an instant before a tool executes, then masked back out of the result before it returns to the model. The model reasons entirely on placeholders.

The documentation also states that exfiltration attempts are blocked, for example a placeholder smuggled into a URL pointed at a third-party host.

None of this is Pro-only marketing. The module sits in the open-source tree at mcp/src/privacy/ as two Python files, gateway.py and vault.py, so the substitution logic is readable.

What Pro adds on top is guard-sealed storage, an audit trail, and a compliance-grade statement in the signed report. The tokenization itself is not the paywalled part.

Darkmoon vs Strix

Strix is Darkmoon’s closest open-source comparison, and the two projects have picked genuinely different centres of gravity. Both run autonomous AI agents that confirm findings by exploiting them.

Strix is Apache 2.0, installs with a single curl command, and is shaped like a developer tool. You point it at a local directory, a git repository, or a live URL.

It can also scope testing to a pull-request diff, which makes it a natural fit inside the software development lifecycle. It runs headless in CI and hands back a proof-of-concept per finding.

Strix also carries the higher star count: over 47,000 against Darkmoon’s 806.

Darkmoon is shaped like an infrastructure assessment tool instead. Its agent set reaches past the web application into Active Directory, Kubernetes, cloud accounts, CI/CD systems, secret stores, and IoT firmware images.

The other structural difference is data handling. Strix supports local models, which keeps data on your infrastructure if you run one.

Darkmoon adds tokenization on top, so you can use a frontier cloud model and still keep real IPs and credentials inside the perimeter.

Pick Strix if your target is an application, your workflow is pull-request shaped, and you want the lighter install.

Pick Darkmoon if the engagement spans infrastructure and identity, or if sending real hostnames to a model provider is a compliance problem you cannot solve otherwise.

Darkmoon vs RunSybil

RunSybil attacks the same autonomous pentest problem as Darkmoon, but from the commercial, hosted end of the market.

RunSybil is a managed AI-native offensive security service. The vendor operates the platform, so there is no Docker stack to build, no LLM provider to configure, and no GPU sizing question to answer.

That model suits teams who want autonomous testing as an outcome rather than as infrastructure.

The trade is a commercial contract instead of a repository you can read. RunSybil is vendor-operated, so check its documented data residency and retention terms against your own requirements.

Darkmoon inverts every one of those choices. You host it, you supply the model, you read the agents, and you can rewrite them.

The agents are Markdown files mounted from a volume, so an edit applies without a rebuild. That control has a real cost, though.

You own the Docker stack, the LLM bill, the model selection problem, and the operational burden of keeping a young open-source project running.

Pick RunSybil if you want autonomous offensive testing delivered as a service, with a vendor accountable for it.

Pick Darkmoon if self-hosting is a requirement, if you want to audit and modify the methodology, or if data sovereignty rules a hosted platform out entirely.

How much does Darkmoon cost?

Darkmoon Community is free under GPL-3.0 as of this review, and Pro is listed at €149 per month billed €1,788 annually. ASC-IT publishes those numbers openly, which is unusual in this category.

The licence fee is not the whole cost. Darkmoon drives a frontier-grade model through hundreds to thousands of tool calls per campaign, and that usage is billed by your LLM provider.

Boutayeb told Help Net Security that a typical web application assessment using Claude Opus runs around ten dollars in API charges, with Active Directory and multi-host engagements costing more.

That is a maintainer estimate, not an independently reproduced benchmark.

Running a local model instead removes the API bill and replaces it with hardware. The documentation’s local recommendations start at a 24 GB GPU with 128 GB of system RAM.

How do you get started with Darkmoon?

Darkmoon is a Docker Compose stack. The Community edition needs Docker, Docker Compose, and an LLM the autonomous loop can actually drive.

1. Clone and install — git clone https://github.com/ASCIT31/Dark-Moon.git, then run ./install.sh. The script checks prerequisites, resets the stack, rebuilds images, and brings everything up.
2. Configure the model — the installer opens an interactive provider form on first run, and ./install.sh --init forces it again later. You choose a cloud provider, an Anthropic-compatible endpoint, or a local Ollama or llama.cpp server. The non-interactive --provider, --model, and --api-key flags belong to the Pro installer.
3. Run an assessment — ./darkmoon.sh "TARGET: http://172.19.0.3:3000" starts a blackbox campaign against a lab container. Add flags like FOCUS=sqli,idor only when you want to narrow it.
4. Monitor the session — ./darkmoon.sh --log <session_id> streams agent output, tool executions, and findings as they land. Reports are written to ./reports.

Start against a deliberately vulnerable target. The documentation’s own examples use OWASP Juice Shop and DVGA on a local Docker network.

That is the right way to see how the agent behaves before you point it anywhere real.

One practical gotcha: the TUI runs inside a container and copies through OSC 52, so terminals that drop that escape sequence, GNOME Terminal among them, will silently paste nothing.

What are Darkmoon’s limitations?

The contributor base is narrow. Eight contributor accounts on a repository this young is a real bus-factor risk for a tool that executes exploitation logic against your infrastructure. Budget time to read the agents yourself.

Documentation lags the repository. The agents chapter still describes four agents while conf/agents/ ships 50, and the marketing site quotes 18 in one place and 33 in another.

The repository’s conf/agents/ directory, which currently ships 50, is the verifiable count.

The model requirement is a hard floor, not a preference. The docs are explicit that 7B and 13B models cannot hold the autonomous loop and leave campaigns stuck in Unknown.

That is a real barrier for teams who assumed self-hosting meant cheap.

Agent-definition scope outruns the shipped workflow set. The definitions describe cloud, IoT, SCADA, and firmware capability, but only 6 MCP workflows ship in the repository.

The rest of the surface is agent instructions driving toolbox binaries, which is more variable than a coded workflow.

The vendor’s benchmark is self-published. ASC-IT publishes an OWASP Juice Shop result in its own benchmark repository. No independent replication exists yet, so the figure is omitted from this page.

Autonomy cuts both ways. Agents are explicitly written never to ask for confirmation and to chain attacks until vectors are exhausted.

That is the point of the tool. It is also why it needs written authorization and a lab run first.

When should you use Darkmoon?

Darkmoon fits teams who want autonomous offensive testing but cannot send infrastructure detail to a model provider. Among the alternatives on this page, it is the only one that solves that with local tokenization you can read.

Regulated environments, EU public sector, and defence-adjacent work are the obvious cases. The Privacy Gateway plus a GPL-3.0 codebase gives a security architect something concrete to audit.

It also suits internal red teams who want to modify the methodology. Agents are Markdown, mounted from a volume, and applied without a rebuild, a genuinely low barrier to encoding your own playbooks.

Consultancies and MSSPs running repeat engagements are the third fit. The Pro dashboard, scheduled campaigns, and HackerOne or Bugcrowd report formats are built for that workflow.

It is a poor fit if you want a scanner you can point at production on day one, or if your testing is application-only and pull-request shaped.

Pick Strix for application-only, pull-request-shaped testing.

It is also the wrong tool if nobody on the team wants to own a Docker stack and an LLM budget. Managed platforms like Astra Security or Pentest Tools remove that burden entirely.

What are the alternatives to Darkmoon?

The closest Darkmoon alternatives are Strix, RunSybil, Astra Security, Pentest Tools, ZeroThreat, and Nuclei. The autonomous pentest category is young, so these tools differ more by shape than by capability claim.

• Strix — Apache 2.0 autonomous AI agents that exploit an application and attach a proof-of-concept per finding, scoped to a repository or pull-request diff.
• RunSybil — commercial AI-native offensive security delivered as a managed service, with no self-hosting requirement.
• Astra Security — AI-assisted continuous pentest platform combining automated scanning with human review and a compliance-oriented reporting workflow.
• Pentest Tools — hosted toolkit that packages established scanners behind one interface for teams who want breadth without running the stack.
• ZeroThreat — AI-powered DAST with automated pentesting features and a freemium entry point.
• Nuclei — the template-driven open-source scanner Darkmoon itself calls, worth running standalone if you want deterministic checks instead of agent reasoning.

For a wider view of dynamic testing, see the full DAST tools category page.

Frequently Asked Questions