DarkMoon: An Autonomous Pentest Engine That Tokenizes Your Infrastructure Before the Model Sees It

The problem is not finding bugs, it is finding them without shipping your network map to a vendor

Most autonomous pentest tooling in this category assumes the model runs somewhere you do not control. That is fine for a lab target and awkward for anything else. The moment an agent needs to reason about an internal hostname, a service account, or a database connection string, that string has to reach the model provider. Security teams respond to this by not running the tool against the assets that matter, which is precisely where an autonomous agent would save the most time.

DarkMoon's answer is a local tokenization layer it calls the privacy gateway. Real IPs, hostnames, URLs, credentials and paths become deterministic placeholders such as IP_PRIVATE_001. The model reasons over placeholders. Rehydration happens locally at the moment a tool executes, and results are masked back before they return to the model. The README makes a specific claim about failure behaviour that is worth quoting because it is the design decision most tools get wrong: when a value is headed somewhere it must not go, the command still runs and the far end receives the placeholder instead. That is a deliberate choice to preserve scan continuity over strict blocking.

The target user is a security team or DevSecOps group that wants agent-driven coverage across a wide asset surface and is unwilling to send asset identifiers to a third party. The README positions it as not replacing the pentester, clearing the repetitive portion of an assessment with evidence attached. That framing is honest about scope.

Fifty agents, an MCP boundary, and a placeholder that never reaches the model

The architecture has three visible layers. At the top, a reasoning and planning component decides what to do next. Below it, roughly 50 specialist agents cover distinct domains: web and APIs, Active Directory, Kubernetes, cloud across AWS, Azure and GCP, CI/CD, databases, IoT firmware, and AI/LLM inference endpoints. At the bottom, an MCP layer mediates every offensive action. The README states the AI never runs a command directly; each action flows through that controlled, logged interface.

That MCP boundary is the load-bearing part. It is where the privacy gateway sits, where session logging happens, and where the tool inventory lives. The named tools include Nuclei, NetExec, BloodHound, sqlmap, Impacket, Naabu, httpx and ffuf. The README describes these as orchestrated over MCP rather than invoked by the model.

Agent methodology is stored as plain Markdown, which the README presents as an auditability feature: you can read, diff and fork each agent's approach. For a security tool this matters more than it would elsewhere. If an agent's methodology is prose you can inspect, you can argue about it in review. If it is a compiled prompt, you cannot.

The LLM endpoint agent is a separate concern from the rest. It probes OpenAI-compatible servers, Ollama, vLLM and TGI for the OWASP LLM Top 10 categories named in the README: prompt injection, jailbreaks, system-prompt leakage and unsafe output handling. Release v1.4.0 added this agent alongside what the release notes call a garak toolbox, so garak-backed probes are the mechanism rather than bespoke test cases.

Installing it: three commands and one interactive script

The documented path is Docker and Docker Compose, plus an LLM provider. The README lists cloud providers (Anthropic, OpenAI, OpenRouter) and local models (Ollama, llama.cpp) as supported. Local model support is what makes the privacy claim coherent; a cloud provider in the loop reintroduces the question the gateway exists to answer, though the tokenization layer still limits what any provider sees.

Clone and enter:

git clone https://github.com/ASCIT31/Dark-Moon.git cd Dark-Moon

Configuration runs through install.sh, which the README says handles provider setup interactively so you do not edit docker-compose.yml by hand:

./install.sh ./install.sh --init ./install.sh --help

The first form skips the configuration form if .opencode.env is already populated. The second forces reconfiguration. The third prints usage. That .opencode.env filename is the only config artifact the README names, and it is also the file you would need to manage if you want to script installation rather than answer prompts.

Launching an assessment and following it:

./darkmoon.sh "TARGET: example.com" ./darkmoon.sh --log <session_id>

The README states that session logs display every command executed by the MCP server. That is the audit trail, and it is also, as far as the supplied material shows, the primary output surface. GPU setup, NVIDIA driver troubleshooting and environment variable details are deferred to docs/full.md rather than covered in the README, so treat the quickstart as covering CPU-capable or already-configured hosts only.

The 57-vulnerability Juice Shop benchmark is reproducible, which is both its strength and its limit

The headline number is 57 vulnerabilities against OWASP Juice Shop in a black-box run on a local LLM, broken down as 8 critical, 24 high, 21 medium and 4 low, in 28.5 minutes of wall-clock time, with proof-of-exploitation per finding. The README points to a separate repository, ASCIT31/Darkmoon-Benchmarks, and invites reproduction and comparison.

That is a better disclosure than a screenshot. A published harness that anyone can rerun is the only kind of benchmark claim worth reading. But be clear about what it measures. Juice Shop is a deliberately vulnerable single web application. It is not Active Directory, not a Kubernetes cluster, not a firmware image, and not a cloud account with IAM sprawl. The breadth claimed across ten domains is not evidenced by this number, and the README does not present it as if it were.

There is also a scoring ambiguity the README does not resolve. Fifty-seven findings with per-finding proof does not tell you the false-positive rate, because a proof-of-exploitation is evidence that a finding is real, not evidence that the set is complete or that nothing spurious was also reported. If you are evaluating this against a manual assessment, ask what was missed, not only what was proven. The benchmark repository is the place to look for that, and it is outside the material available here.

What the README does not tell you, and why it matters before you deploy

Several things an adopter needs are absent from the supplied documentation. There is no stated REST API, no documented CI/CD integration mechanism beyond the general claim of being pipeline-native with findings as artifacts, and no described export format for findings. The comparison table asserts CI/CD native support; the quickstart shows an interactive shell script. Those two things are not the same, and the gap is where a DevSecOps evaluation will stall.

Resource requirements are also unstated. Running 50 agents with a local Ollama or llama.cpp backend implies hardware, and the README defers all of that to docs/full.md. If you plan to run this on a laptop, the documentation does not support that expectation either way.

The MCP layer is described as controlled and logged, but the README does not say how the tool allowlist is configured, whether it can be narrowed per engagement, or what happens when an agent requests a tool outside the set. For a tool that executes real exploits, that is the control you most want documented.

Finally, there is the failure mode inherent in the privacy gateway's design. The README states plainly that when a value must not leave, the command still runs and the far end receives the placeholder. That preserves scan flow. It also means a command can execute against a placeholder rather than the intended target, and the README does not describe how such a run is detected or reported. If your assessment depends on a specific host being reached, verify that behaviour yourself before trusting a clean result.

Against a conventional scanner: Metasploit plus Nuclei in a scripted pipeline

The honest alternative for most teams is not another autonomous agent. It is the combination they already have: Nuclei for templated web and network checks, Metasploit or Impacket for exploitation, BloodHound for Active Directory path analysis, driven by a CI job and a results database. DarkMoon wraps several of these same tools, which is worth noting: Nuclei, Impacket, BloodHound, sqlmap, ffuf and httpx appear in its own tool list.

The difference is the control loop. A scripted pipeline executes a fixed sequence and reports what the templates matched. DarkMoon's agents choose the next action based on what the previous one returned, which is how chained exploitation becomes possible across domains rather than within one. The cost of that flexibility is predictability. A fixed pipeline produces the same output for the same input, which makes regression comparison trivial. An agent-driven run does not, and nothing in the supplied material describes a determinism or replay mechanism.

There is a second difference worth weighing. A scripted pipeline has no model in the loop, so it has no privacy problem to solve and needs no tokenization layer. DarkMoon's gateway exists because it introduced an LLM. If your environment already permits sending hostnames to a model provider, the gateway is overhead rather than a feature. If it does not, the gateway is the reason the tool is usable at all.

Licence, upgrade path and what GPL-3.0 means for embedding

DarkMoon is GPL-3.0. For internal security assessment, running it as a self-hosted service against your own assets, the licence is not a practical obstacle. For anyone who wants to embed the engine in a commercial product, or offer it as a hosted service with modifications, GPL-3.0 carries source-disclosure obligations that a permissive licence would not. That is a product decision, not a legal one, and it is worth a conversation with counsel rather than a guess.

The release cadence visible in the supplied material is tight. v1.3.0 and v1.3.1 landed on the same day, 2026-08-23, with v1.3.0 described as a 50-agent roster plus GPU cracking and reliability work, and v1.3.1 as privacy gateway parity for workflows. v1.4.0 followed on 2026-09-07 with the LLM endpoint agent, privacy gateway hardening and the garak toolbox. Three releases in roughly two weeks, with the middle one a targeted fix for gateway parity, suggests active development and also suggests the gateway behaviour has been changing recently. If you build on it now, pin a version rather than tracking master.

Upgrade cost is not documented in the supplied material. There is no migration guide, no schema version for findings, and no statement about whether .opencode.env survives an upgrade or is regenerated by install.sh --init. The install script's ability to force reconfiguration is convenient on a fresh host and ambiguous on an existing one. Verify that before running --init on a configured deployment.

Editorial conclusion

DarkMoon is worth a pilot if you already run authorized internal assessments and your blocker has been that no cloud-hosted agent could be pointed at production address space. It is the wrong tool if you need a documented REST API for pipeline integration today, or if your findings have to land in an existing ticketing workflow without glue code. Before installing, verify three things in the repository: whether a non-interactive install path exists besides ./install.sh, whether the MCP tool allowlist is configurable rather than fixed, and whether findings export to a machine-readable format or only to session logs. The GPL-3.0 licence is a real constraint for anyone embedding this in a closed product.

Official sources

1. ASCIT31/Dark-Moon on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases