Trust, proven and documented

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).

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).

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).

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).

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.

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.

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).

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).

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).

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).

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).

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).