Dark-Moon Breakdown: Sanitize Real IPs and Credentials Locally First, Then Let the AI Attack

1. At a Glance: Is It Worth Your Time

Rating: ★★★★☆ (4 / 5)

Why this score: it tackles the single real-world problem that most blocks enterprise adoption of autonomous pentesting — you cannot send traffic containing real IPs, internal domain names, or credential fragments to a cloud LLM, yet local small models cannot carry complex reasoning. Dark-Moon’s answer is the Privacy Gateway: reversible local tokenization. Real values are turned into deterministic placeholders (for example, 10.0.0.1 becomes __HOST_A__) before they ever leave your boundary, and are rehydrated locally only at the exact moment a tool actually executes. Because the placeholders are deterministic, the model can still do correlation reasoning like “the same host showed up three times” — but the text sent out contains no real assets.

The second plus is that the tools are the real deal, and there are plenty of them: a multi-stage Docker build packs in 140+ security tools (Nuclei, sqlmap, WPScan, NetExec, BloodHound, 30+ Impacket scripts, kubectl, aws/az/gcloud, hashcat, john…), not a shell where “the AI pretends to scan.”

The missing star goes to four places: GPL-3.0 (milder than AGPL, but still strong copyleft); the Pro edition has an outsized presence in the README (the big dashboard screenshots and the “auto-fix that opens a PR” chain are all paid — the open-source edition is CLI only); that 57-vulnerability benchmark was run with a cloud frontier model (Anthropic Claude), and the README itself says local-model coverage “depends on the model you run” — so the headline number does not represent what a local deployment achieves; and only 2 open issues, meaning the community sample is still very small.

Key Data (as of 2026-09-30)

Who It’s For

Building on It

2. What It Is, What It Isn’t

• Not a wrapper around a vulnerability scanner. It does not produce “scores” — the README’s own words are Evidence, not scores: every finding ships with the exact command and raw output.
• Not a tool that lets the AI touch your systems directly. The architecture states it bluntly: The AI never runs a command directly — every action goes through MCP, a controlled and logged interface.
• Not a pure cloud SaaS. It can run fully local (Ollama / llama.cpp), and that is its most fundamental difference from strix and shannon.
• Not a swarm of “50 agents each doing their own thing.” It is an agentic system doing the reasoning and planning, dispatching expert agents on demand.

Three keywords: Privacy Gateway (local reversible sanitization), MCP Gatekeeper (the controlled layer between the AI and the tools), sub-agent dispatch (specialists dispatched by detected tech stack).

3. Privacy Gateway: The Design That Makes It Worth Its Salt

Let’s state the threat model clearly first. When you send an AI agent after your internal network, it will see: real IPs, internal domains, URL paths, internal identifiers that may appear in response bodies, even the credentials you hand it. All that text has to go to the LLM for reasoning. If the LLM is in the cloud, you have effectively sent your asset mapping results to a third party.

Dark-Moon’s approach:

Reversible local tokenization turns real IPs, hosts, URLs and credentials into deterministic placeholders, rehydrated only locally at the moment a tool runs.

Three keywords in that sentence deserve unpacking:

1. Reversible — not hashed beyond recovery. When the tool actually needs to hit 10.0.0.1, the placeholder must be restorable to the real address, or nothing can be scanned.
2. Deterministic — the same real value maps to the same placeholder every time. This is the key to whether reasoning works at all: the model must be able to see that “step 3 and step 7 encountered the same host.” If placeholders were random, that correlation breaks and planning quality collapses.
3. Rehydrated only locally, at the moment a tool runs — the rehydration window is extremely short and never crosses the local boundary. What enters the model context is always the placeholder.

This line of thinking is consistent with how the industry does “LLM data-loss prevention,” but adapting it specifically to asset identifiers in pentest scenarios is Dark-Moon’s original contribution. If an enterprise genuinely wants to deploy autonomous pentesting, this is close to a hard requirement.

But to be honest: the README describes the mechanism only, and gives no quantitative data on sanitization coverage (which fields get tokenized, whether anything slips through, how placeholder collisions are handled). If you want to rely on it for compliance, audit the code yourself before drawing conclusions.

4. Architecture: The AI Can Only Issue Orders Through MCP

1

User ──> DarkmoonCLI ──> OpenCode (AI Brain) ──> MCP (Security Gatekeeper) ──> Docker Toolbox (Real Tools)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

sequenceDiagram
  participant U as User
  participant O as OpenCode
  participant A as AI Agent
  participant M as MCP Darkmoon
  participant T as Docker Toolbox

  U->>O: User prompt
  O->>A: Delegate task
  A->>M: MCP function call
  M->>T: Execute real tool
  T-->>M: Results
  M-->>A: Structured output
  A-->>O: Next decision
  O-->>U: Summary / result

The three layers have clean responsibilities: the AI reasons and plans, MCP decides what may be executed, and the Toolbox runs isolated tools inside Docker.

One detail deserves to be pulled out on its own — planes that are meaningless without credentials are never dispatched on inference:

Planes that require credentials to be meaningful (cloud accounts, CI/CD, secret stores, databases, Active Directory, Kubernetes) are never dispatched on inference. They fire only when a concrete artifact is found (a key, a token, a reachable metadata endpoint) or when you authorize them explicitly, and are otherwise flagged in the report.

In other words, the AD / K8s / cloud / database agents do not fire “because the model feels like it.” A concrete credential or reachable metadata endpoint must be found first, or you must explicitly authorize it. Otherwise they are simply flagged in the report for you to review. This is a very pragmatic convergence — it stops the model from hallucinating a cloud environment out of thin air, and it stops the run from hammering cloud APIs the moment it starts.

Sub-Agent Dispatch Table (excerpt)

It will even attack your own AI — the LLM agent uses garak-backed probes to test AI/LLM inference endpoints against the OWASP LLM Top 10. That is uncommon among its peers.

5. Benchmark: 57 Vulnerabilities — but Read How It Was Run

The README reports a real, reproducible black-box run against OWASP Juice Shop:

One warning is mandatory here: the 57 in this table is a cloud frontier model result. The very next sentence in the README says:

DarkMoon also runs fully local (Ollama / llama.cpp) behind the Privacy Gateway — so nothing leaves your infrastructure; local-model coverage depends on the model you run.

Meaning: if you run local models for compliance reasons, do not expect to reproduce 57. How far a local run gets is data the README does not provide. This is the easiest trap to fall into when evaluating the project — the headline number and your actual deployment shape are not the same thing.

To reproduce and compare yourself, there is an official repo: ASCIT31/Darkmoon-Benchmarks. That attitude counts for something.

The project also publishes a comparison table (labeled “compiled from public repos/docs, 2026-08, PRs welcome”):

This table was compiled by the project itself, not by a third-party evaluation — read it with that premise in mind.

6. Deployment and Integration

Install

1
2
3

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

install.sh interactively configures the LLM provider (no hand-editing docker-compose.yml) and builds the entire stack:

1
2
3

./install.sh           # skips the form if .opencode.env is already configured
./install.sh --init    # force reconfiguration (cloud or local models)
./install.sh --help    # usage

Run a first assessment and watch the logs live:

1
2

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

Prerequisites: Docker & Docker Compose, plus an LLM API key (or a local model).

Scope and Flags

1
2
3
4
5
6
7
8
9
10
11

# quick pentest (zero configuration)
./darkmoon.sh "TARGET: http://172.19.0.3:3000"

# bug-bounty mode (flags activate automatically)
./darkmoon.sh "TARGET: http://172.19.0.3:3000 PROGRAM=\"Juice Shop\" FOCUS=sqli,xss,idor NOISE=moderate FORMAT=h1"

# tech-stack focus + exclusions
./darkmoon.sh "TARGET: https://app.example.com PROGRAM=\"Example BB\" FOCUS=sqli,rce,ssrf EXCLUDE=H1 FORMAT=h1"

# Active Directory
./darkmoon.sh "TARGET: 192.168.1.10"

Main flags: FOCUS, EXCLUDE, CREDS, TOKEN, NOISE, SEVERITY, FORMAT — all parsed by the AI from natural semantics.

The Toolbox (140+, Docker multi-stage build)

Integration Matrix

One excellent constraint: all integrations emit only safe metadata (severity, status, MITRE, id) — never evidence, keys, or tokens. That prevents the secondary incident class of “internal-network evidence leaked through CI logs.”

7. Boundaries and Risks (the part that must be said honestly)

1) GPL-3.0, not Apache/MIT. Milder than AGPL-3.0 (no network-service clause), but still strong copyleft. Be careful about embedding it in a proprietary product; using it as a standalone tool is fine.

2) The README’s Pro coverage is so heavy it is easy to misread. The big dashboard screenshots, the orbital attack-surface map, the scheduler, and the “finding → sandbox-validated fix → human-reviewed PR” auto-fix chain are all paid Darkmoon Pro features, not part of the open-source repo you clone. The OSS edition is the CLI. The README does mark them with 🔒, but visually Pro dominates OSS, and a first read easily leaves you thinking those are open-source capabilities.

3) The 57-vulnerability result has nothing to do with a local deployment. See Section 5 — it was produced by cloud Claude. If you want to evaluate what a local setup actually achieves, there is no public data; you have to run the benchmark repo yourself.

4) What local models can really do is an unknown. The docs only say “coverage depends on the model you run.” And degradation of small local models on long tool-calling chains is an industry-wide problem — dispatch decisions across 50 agents and MCP tool-argument construction are both unfriendly to small models. Do not assume “turning on Ollama equals a drop-in replacement.”

5) Only 2 open issues does not necessarily mean stable. 975 stars, 220 commits, 22 months of history — an issue count that low more likely reflects a still-small community. When you hit a wall, the external help you can count on is limited.

6) The comparison table is self-assessed. “Compiled from public repos/docs (2026-08), PRs welcome” — the disclaimer is honest, but it also means this is not an independent evaluation. Verify it yourself before using it for tool selection.

7) The dependency chain is heavy. OpenCode (AI Brain) + MCP + a full Docker Compose stack + a 92MB repo + an image with 140+ tools. Build times and troubleshooting costs are both nontrivial, and a failure in any one of those three layers brings the whole chain down.

8. Getting Started (in This Order)

1. Use ./install.sh, not hand-edited docker-compose.yml. It configures the provider interactively and builds the full stack. To switch between cloud and local models, use ./install.sh --init.
2. Pick the narrowest scope for your first run. The official example is a single target like TARGET: http://172.19.0.3:3000 — do not hand it a whole subnet right away.
3. Verify the Privacy Gateway’s sanitization first. This is the core selling point. While the run is going, watch the live logs with --log <session_id> and confirm the outbound text really contains no real IPs or credentials. Do not skip this step — it is the precondition for deciding whether you dare use cloud models at all.
4. Use FOCUS when you want to narrow in. For example, FOCUS=sqli,xss,idor significantly shortens run time and cuts irrelevant noise. For a first assessment, focus on a single category and watch how it reasons.
5. Get the cloud model working first, then switch to local for comparison. Reproduce the Juice Shop run with Claude (against Darkmoon-Benchmarks) to establish a baseline; then run the same target on Ollama and quantify the local degradation yourself. That delta is the real basis for your deployment decision.
6. Start CI/CD integration with GitHub Actions or GitLab CI — both are in the OSS edition and emit metadata only, never evidence, so they carry the least risk. Do not start with n8n / Grafana — those are Pro.
7. If you need AD / K8s / cloud coverage, be ready to authorize explicitly. Those planes are never dispatched on inference; you either find a concrete credential or reachable metadata endpoint, or you authorize them explicitly — otherwise they will only be flagged in the report.

9. The One-Line Verdict

If your constraint is “the pentest may be automated, but asset information must not leave the building,” Dark-Moon is currently the only open-source choice that builds local reversible sanitization into the main flow; but remember that its 57-vulnerability record belongs to cloud Claude, and those pretty dashboards and auto-fix PRs belong to the paid Pro edition.

First move for enterprise security teams: stand it up with ./install.sh, run the single-target Juice Shop assessment, and keep --log open the whole time to verify the sanitization actually works. Once you have confirmed that, then talk about whether to wire it into CI.