Trust, proven and documented

DarkMoon is published by ASC (ASC-IT), in Toulouse, France. Trust is not decreed: it is proven, line by line. DarkMoon uses ISO/IEC 27001:2022 Annex A as its control framework and ISO/IEC 27005 as its risk framework. The product is not certified; each answer below points to a specific paragraph of the architecture dossier.

Security, proven by architecture

• AI isolation, with no free shell. The model has neither a shell nor a raw socket: an allow-listed MCP gateway is the only path to the tools. Even if compromised, it cannot reach a tool that was not granted. The barrier is the action, not the container.
• Encrypted at rest, hardware-bound. AES-256-GCM seals every sensitive state; the key is derived from the licence and a hardware fingerprint and is never persisted. TLS everywhere on egress, strict peer verification on critical calls.
• Hosted in Europe. Portal and database on OVH and IONOS (EU); findings stay on the client's host. The only US dependency is a public image registry (Docker Hub), which receives no client data.
• Data never exposed. The Privacy Gateway tokenises locally: the model only ever sees markers, never your real IPs, hosts or credentials.
• Honesty as a control. Our gaps are published, dated and followed by an action plan. A serious vendor also documents what remains to be done.

Twelve domains, answered in full transparency

Each domain is treated as an audit questionnaire: an answer backed by evidence, with an openly stated maturity level (Compliant, Partial, Via a third party, Planned, or Owned non-conformity).

1. Security governance and compliance

• ISO 27001 / SOC 2 certification: not certified. DarkMoon uses ISO/IEC 27001:2022 Annex A as its control framework and ISO/IEC 27005 as its risk framework, with an explicit control → implementation → evidence mapping (partial).
• Formal risk view: yes, an ISO 27005 risk table (asset → STRIDE threat → control → residual risk), 8 risks rated from Low to Medium (compliant).
• AI posture (EU AI Act / ISO 42001): documented, not certified — evidence-provenance discipline and formal bounding of the agent's autonomy (planned).

2. Accountability, sovereignty and data residency

• Allocation of responsibilities: the client is the controller of the findings, which run on its host; ASC-IT is only the controller of the portal's commercial data. Hosting on OVH (FR/EU) and IONOS (DE/FR, EU).
• EU residency: by design, findings, evidence, campaign graph and reports never leave the client's host. Local model / air-gap option: 100% on premises, zero telemetry.
• Extraterritorial laws (CLOUD Act): treated as a first-order risk; EU hosting; the only US dependency is Docker Hub (public images, no client data).

3. Access management (IAM) and authentication

• Portal authentication: passwordless, one-time email code (6 digits, bcrypt-hashed), anti-brute-force quota and lockout, opaque 256-bit session token, three separate areas (client / partner / admin).
• Anti-enumeration: the flows return a success whether or not the email exists.
• Least privilege for machine / AI identities: the child process runs non-root, with no new capabilities, empty effective capabilities, continuously verified by a watchdog.
• Runtime dashboard: time-limited JWT, local accounts, forced password change on first access; a default secret to rotate (owned gap, partial).

4. Encryption and key management

• At rest: AES-256-GCM seals every sensitive runtime state directory (data, config, agents, workflows).
• Key management: the key is derived from the licence and a hardware fingerprint, recomputed at each start-up and never persisted; a stolen image is undecryptable elsewhere.
• In transit: TLS everywhere on egress, strict peer verification on critical calls (payment, licence), HSTS and security headers on the portal.
• Portal encryption at rest: an honest and planned gap — the portal's personal data and back-ups are not yet encrypted at the application level (presented as to-do, planned).

5. AI isolation and confinement

• Free execution / shell: no. A non-negotiable founding principle — the AI must never be able to freely execute code; the model has neither a shell nor a raw socket.
• Security barrier: the barrier is the action. An MCP gateway is the model's only path to the tools, allow-listed and with timeouts.
• Isolation architecture: two containers, a sealed and hardened “brain” (read-only file system, capabilities dropped, sensitive state in volatile memory) and a “toolbox” (the only one with network access) holding no secret.
• Prompt injection: an injection does not allow code to be executed — auditable agents, mandatory gateway, no self-modification of the rules, an “unconfirmed signal until there is evidence” classification.

6. Privacy Gateway (reversible local tokenisation)

• The AI provider never sees the real values: the model only handles deterministic tokens (IPs, hosts, emails, credentials). The real values are re-injected locally just before the tool runs, then re-tokenised before anything returns to the model.
• Protected reversibility: a per-session vault, real values kept only encrypted, no cleartext at rest or in the logs, credentials are never re-injected into an executed command.
• Tested: 22 unit tests covering the 7 required properties, end-to-end validation on the OWASP Juice Shop environment, with no performance regression. Open-source core; the Pro edition adds a “no data left the perimeter” attestation in the signed report.

7. Logging and traceability

• Audit trail: log of engagement actions (actor + IP), payment webhook log (idempotent), watchdog logs (control A.12.4).
• Secrets in the logs: a redaction filter wipes provider keys from any output before transfer (control A.8.12).
• SIEM / central aggregation: no — an owned gap, no SIEM or centralised alerting (the product often runs on a client host invisible to the publisher).

8. Vulnerability management and red teaming

• SAST: yes, static analysis at each delivery, a profile restricted to security rules only (vulnerabilities and hotspots), the build blocked on any violation.
• Pentest / red teaming: DarkMoon is a pentest tool; the evidence-first classification and the execution safeguard are the compensating controls.
• SBOM: expected in a standard format (CycloneDX / SPDX) for the in-scope components (planned).

9. Secure development (SDLC) and supply chain

• Immutable / reproducible images: multi-stage build, read-only file system, content-addressed images, pinned continuous-integration actions, encrypted agent capsules and gateway logic compiled to native code.
• Secrets in the CI chain: runtime secrets via the forge's vault. An honest gap — live secrets exist in tracked files; a rotation plan, injection at deployment and history purge are documented (partial).

10. Continuity, back-up and recovery (DR)

• Back-ups: the portal is backed up every night in 3 copies (forge + IONOS SFTP vault + OVH SFTP vault), tolerant to the failure of one provider; the runtime with frequent state snapshots.
• Recovery objectives: portal, data loss ≤ 24 h and restoration ~1–2 h; runtime interface, loss on the order of a minute; reports/sessions continuously.
• Anti-ransomware resilience: a stateless and immutable runtime; on any integrity violation, the safeguard stops the process, wipes the state and refuses to restart (fail-closed). An honest gap: the portal and the runner are single points of failure (partial).

11. GDPR and personal data protection

• Data regimes: two strictly separated regimes — the portal's personal data (ASC-IT controller, contractual legal basis, minimisation, record of processing) and the findings (the client is the controller; they never leave the client's host).
• Controls in place: minimisation and anti-enumeration, back-up retention limitation, capture of the legal basis per engagement (authorisation + role + signature + time-stamp), verified encrypted transport.
• Erasure / DPA / sub-processors: honest gaps to scope — erasure still manual, DPA and sub-processor register not yet formalised. The 60-day deletion of the Pentest on Demand service is a contractual commitment (planned).

12. Provider and sub-processor security

• Sub-processors: OVH (continuous integration, FR/EU), IONOS (portal and database, DE/FR, EU), Stripe (payment, verified signature), Cryptolens (licensing authority, EU), Docker Hub (public image registry, US, no client data), GitHub (code and CI), Infomaniak kmeet (Pentest on Demand debrief call only).
• External calls: all encrypted (HTTPS), strict peer verification on critical calls, verified signature of the payment webhook, licence response signed and verified offline.
• Debrief call: the Pentest on Demand debrief is held on Infomaniak kmeet, an encrypted video conference (Switzerland/EU), strictly as a debrief channel and not as a product component (via a third party).

Our honesty is a control

We publish our gaps, dated and followed by an action plan:

• No centralised SIEM. No central aggregation of runtime logs — the product is often hosted at the client's premises.
• Portal encryption at rest. PII and back-ups: planned, not yet applied.
• DPA and ROPA register. Sub-processor register and DPA not yet formalised.
• Data erasure. Manual today, automation to come.
• Secrets in the repository. Rotation plan, injection at deployment and history purge in progress.
• Single-instance portal and runner. Single points of failure, without high availability.

Reference framework: ISO/IEC 27001:2022 Annex A · ISO/IEC 27005 · NIST SP 800-115 · MITRE ATT&CK · CVSS 3.1 · OWASP · EU AI Act (posture) · ISO/IEC 42001 (posture) · GDPR.

Need to go deeper in your security assessment? Our documentation — ISO 27001 mapping, risk analysis, threat model and DPA — is available on request, under NDA. See also our Privacy Policy.