DarkMoon v1.4.0 is an open-source, self-hosted autonomous pentest platform, and its maintainers position the new LLM endpoint agent as a way for security and platform teams to test their own AI services. This is a source and documentation review, not a hands-on test. Consider it for internal, authorized AI/LLM endpoint assessment. Hold off on unattended production use until you validate deployment, provider compatibility, and the privacy gateway yourself.

what darkmoon v1.4.0 is and the decision it should help you make

The GitHub project ASCIT31/Dark-Moon describes DarkMoon as an open-source autonomous AI pentest platform. The maintainers state it runs a full assessment against an authorized target and returns proof for each finding, orchestrating 50 specialist agents over a controlled MCP layer and shipping 50+ offensive tools inside a Docker toolbox. Release v1.4.0, published 2026-09-07, adds a dedicated LLM/AI inference-endpoint pentest agent and NVIDIA’s garak scanner to the toolbox. It also closes privacy-gateway leaks the maintainers say they found during live engagements.

The question this evidence addresses is narrow. If your team has started shipping LLM or AI inference endpoints, are those endpoints security tested with the same discipline as the rest of your stack, or is that testing still ad hoc? DarkMoon is one candidate answer. The practical decision is whether to evaluate it, pilot it on an authorized internal target, and only then consider folding it into a recurring assessment workflow.

key facts

who should consider darkmoon

• Security and DevSecOps teams that own an internal AI or LLM service and need repeatable, evidence-backed testing of prompt injection, system-prompt leakage, and unsafe output handling.
• Platform or infrastructure engineers who can run a self-hosted Docker stack and want the option of a local model so infrastructure values do not leave the perimeter.
• Teams already running manual pentests that want to clear repetitive discovery and scanning work while keeping human judgment for validation and reporting.

DarkMoon fits teams that already have authorization over the target, a host to run the container stack on, and someone who can read raw command output. Without those three, the platform has nothing to attach to.

who should not use it

• Anyone without written authorization or a defined target scope. This is offensive tooling, and running it against systems you do not own or have explicit permission to test creates legal exposure.
• Teams that need a fully managed SaaS security product with a vendor support contract. This is a GPL-3.0 codebase that you build, run, and maintain yourself.
• Teams with no local model capacity and no appetite to tune model selection. The maintainers note that model quality influences whether the autonomous loop survives, so an undersized or unreliable model becomes a pilot risk you own.

what changed in v1.4.0 and the checks it implies

the new llm / ai endpoint agent

Per the release notes, the new llm specialist automatically probes for LLM/AI inference endpoints during discovery (OpenAI-compatible /v1/models, Ollama /api/tags, and vLLM/TGI/llama.cpp signatures) and dispatches on a positive artifact, the same pattern used for the GraphQL, Active Directory, and Kubernetes agents. The maintainers state the agent aligns with the OWASP LLM Top 10 and was validated against a deliberately vulnerable OpenAI-compatible target, producing eight findings with the exact request and raw response behind each. Treat that as the maintainers’ result. It does not guarantee coverage on your stack, so confirm detection and dispatch against your own endpoint types before relying on the agent.

privacy gateway hardening

The privacy gateway is the feature most buyers will weigh. The maintainers describe a reversible, per-session tokenization layer that replaces real IPs, hosts, URLs, paths, and credentials with deterministic placeholders, then rehydrates them locally only at execution and before report generation. In v1.4.0 the notes say the team closed several gaps: the prompt is now anonymized before it reaches the model (previously only tool inputs and outputs were tokenized), and it fixed output and report restitution leaks, decoupled exfiltration checks from structural safety checks, and slugified a target host that once broke the report file path. The maintainers report their own end-to-end validation, so that is a design claim rather than an independent result. Re-verify sanitization on your network and model configuration before treating the boundary as reliable.

garak in the toolbox

The release adds NVIDIA’s garak LLM vulnerability scanner, pinned to 0.16.0 for reproducible builds. It is installed CPU-only and the install is non-blocking: if it fails, the maintainers say the image still builds and the llm agent falls back to a manual methodology. That fallback is sensible, but it also means two pilots on different hosts may not have identical tool coverage, so check what actually installed in your build.

before you run it in production

1. Provider compatibility. Open issue #28 reports that running ./darkmoon.sh "TARGET: url.tld" with a custom Anthropic base URL returned no output, no error, no logs, and no progress. The issue was open at review time. If you plan to route through a cloud gateway, budget time to reproduce this and confirm that logging surfaces failures.
2. Local model sizing and selection. The privacy story assumes a capable local model. The maintainers acknowledge model quality affects whether the autonomous loop continues, so validate model choice and hardware on a throwaway target first.
3. License obligations. GPL-3.0 has real consequences if you embed or distribute derivatives. Have counsel review how you intend to use and redistribute the code before it reaches a shipped product.
4. Scope and credential gating. Confirm that EXCLUDE, FOCUS, and the credential-gated planes behave as documented for your environment, so agents do not touch systems outside the agreed boundary.
5. Evidence retention. Decide where reports and logs live and how long you keep them. Raw command output and proof-of-exploitation artifacts are sensitive by nature.
6. No vendor SLA. There is no support contract behind the open-source core; plan for internal ownership of upgrades, debugging, and incident response.

maintenance signals worth reading honestly

The repository shows active, recent development: v1.2.0 in July 2026, a 50-agent roster in v1.3.0 and workflow parity in v1.3.1 in August, and v1.4.0 in September 2026. That cadence and a low open-issue count of 2 suggest a maintained project. Read those numbers for what they are, though: 955 stars and 159 forks measure attention rather than production reliability, and a small open-issue count is only a snapshot that can reflect fast triage, limited reporting, or both. None of it substitutes for running the stack in your own environment.

limitations and material unknowns

• This review has no local installation or runtime evidence behind it. Nothing here was installed, deployed, or benchmarked.
• All performance and coverage figures (the 57-finding Juice Shop run, the Pro remediation claim of 42 of 57 fixed end-to-end, and the zero-leakage validation) are the maintainers’ own benchmarks, not reproduced for this article.
• The Pro remediation tier that returns human-reviewed fix pull requests is paid and separate from the open-source core.
• Issue #43, proposing an optional OpenAI-compatible provider, is an unimplemented suggestion at review time, not a shipped feature.

alternatives and evaluation questions

DarkMoon is not the only option in this space, and the release notes themselves compare it against projects such as strix, shannon, and PentAGI on a few axes. Use those comparisons as a starting point rather than a verdict, and test them against your own requirements. Questions worth asking of any candidate:

• Does it detect and meaningfully test the specific endpoint types you run, not just generic web targets?
• Can it run fully on a local model, and what does that require in hardware and tuning?
• How does it handle false positives and require human confirmation before a finding is reported?
• What evidence does each finding carry, and is it reproducible by your team?
• What is the license, and how does it interact with your distribution plans?

verdict

DarkMoon v1.4.0 is a credible project to evaluate if you own an internal AI or LLM service and want self-hosted, evidence-backed security testing with an optional local model. It is a poor fit for teams that need a managed product, lack authorization or scope, or cannot operate and support a Docker-based offensive stack themselves. The recommendation is a scoped pilot: pick one authorized endpoint, confirm the LLM agent detects it and the privacy gateway holds up under your provider and model, then work through the provider-compatibility and licensing questions above before any recurring deployment. Everything beyond that is the maintainers’ claim until your environment reproduces it.

If you are weighing DarkMoon or a similar autonomous pentest stack for your own AI endpoints, I work on AI agent development, deployment, and system integration at XP812. Before recommending anything, I would need the authorized target scope, the endpoint types and model providers in play, and your deployment constraints such as local versus cloud models, the Docker host, and network boundaries. From there I can help stand up a controlled pilot, wire the privacy and logging boundaries, and document what the tool actually covers versus what still needs human review. I do not promise a specific finding count or a clean result; those depend on your environment and the model you run. See software development services for the wider scope of existing-system and integration work, or contact XP812 to describe the setup.

sources

• ASCIT31/Dark-Moon repository (GitHub): repository metadata, README claims, and license.
• Darkmoon v1.4.0 release notes: LLM endpoint agent, privacy gateway hardening, and garak toolbox changes.
• Darkmoon v1.3.1 release notes: earlier privacy gateway workflow parity.
• Issue #28: custom Anthropic base URL returns nothing: open provider-compatibility report.
• Issue #43: optional OpenAI-compatible provider proposal: unimplemented suggestion at review time.