A data‑handling & no‑training whitepaper. Version 0.1 · 27 July 2026.
You are trusting MILLENNIUMS.AI with the two most sensitive things you own — your source code and your vulnerabilities. That is exactly the material a breach of us would weaponize, so we hold as little of it as possible, for as short a time as possible, and never use it to train a model. This document explains precisely how, and — honestly — which controls are enforced today versus being formalized.
The two commitments that matter most
- We do not train on your data. Your code, prompts, findings, and scan artifacts are never used to train or fine‑tune any model — ours or a provider's.
- Your code is processed ephemerally and in isolation. Each scan runs in its own sandbox that is torn down when the scan ends; nothing is shared across tenants.
Everything below is how the architecture delivers those two commitments.
The data lifecycle
Stage by stage
1. Ingest. You point a scan at a target (a repo, a URL/API, or an IP). Code and requests travel over TLS. Access requires a per‑tenant bearer token.
2. Ephemeral sandbox. The scan engine runs inside an isolated, per‑scan container. Your code is materialized only there, only for the duration of the scan. Nothing is shared between scans or between tenants.
3. Model call. The engine reasons about your code by calling a language model — today, Anthropic's commercial API. Under Anthropic's Commercial Terms, commercial API data is not used to train models. Standard API requests are retained briefly for abuse monitoring, then deleted. Zero‑data‑retention (ZDR) — no retention at all — is available on enterprise agreement and is required for our on‑prem / BYO‑key deployments (ZDR agreement: in progress). The model is a reasoning engine over your code for the length of the scan — not a store of it.
4. Findings. Validated findings (with their proof‑of‑concept and remediation) are written to per‑tenant storage, encrypted at rest. A finding is scoped to the tenant that produced it; cross‑tenant access returns not found, never a data leak.
5. Deletion. The sandbox — and the copy of your source in it — is torn down when the scan completes. Findings persist only for your retention window, then are deleted.
What leaves, and what never does
| Item | Sent to the model provider? | Used to train a model? | Retained by us |
|---|---|---|---|
| Source code / app content | Sent to the model provider (Anthropic) for the scan | No (Anthropic terms) | Provider retains briefly for abuse monitoring, then deletes; ZDR removes this on enterprise agreement |
| Prompts & model responses | Transient, per scan | No (Anthropic terms) | Same as above |
| Findings (PoC, remediation) | No | No | Encrypted, per‑tenant, until your retention window ends |
| Your model API key (self‑host) | Stays in your environment | — | We never see it |
Sub‑processors. Hosted deployments use: your configured model provider (currently Anthropic's commercial API — not trained on; ZDR on enterprise agreement), a container runtime (the sandbox), and a cloud host (encrypted per‑tenant storage). The current list — and a change‑notification subscription — lives on our Trust Center. Self‑hosted deployments have no MILLENNIUMS‑operated sub‑processors.
The strongest control: self‑hosted / BYO‑key
For teams with strict data‑residency or air‑gap requirements, MILLENNIUMS.AI runs entirely inside your VPC or on‑prem environment, using your own model key. In that mode the whole lifecycle above happens within your boundary — your source code and findings never reach us at all, and there are no third‑party sub‑processors we operate. This is the recommended deployment for banks and regulated product teams.
Access control & isolation
- Per‑tenant tokens, compared in constant time; every scan, finding, target, and chat is scoped to the owning tenant.
- No existence leak — a request for another tenant's resource returns not found, not forbidden.
- Secrets discipline — the model API key is never returned by any API; credentials and tenant state are never committed to source control.
- Wallet safety — a hard per‑scan token cap terminates any runaway scan, so autonomous analysis can't exhaust your budget.
Honest status — enforced today vs. being formalized
We publish what's done and what's in progress, because a trust document you can't verify isn't trustworthy.
| Control | Status |
|---|---|
| Per‑tenant isolation (no cross‑tenant access / existence leak) | Enforced |
| Per‑scan sandbox execution | Enforced (engine architecture) |
| Hard per‑scan token cap | Enforced |
| Secrets never returned by the API / never committed | Enforced |
| No‑training on model calls | In place — Anthropic's Commercial Terms exclude commercial API data from training |
| Zero‑data‑retention (ZDR) with the model provider | In progress — available on enterprise agreement; required for on‑prem / BYO‑key |
| Data Processing Addendum (provider flow‑down) | In progress — executing the provider DPA |
| Sandbox teardown verified post‑scan | In progress — automated verification being added |
| Formal retention/deletion policy + audit log | In progress |
| Self‑hosted / BYO‑key deployment | Available (hardening for a packaged SKU in progress) |
| SOC 2 Type II, encryption‑at‑rest attestation | In progress — see the Trust Center roadmap |
This is architecture and commitment, not a substitute for our forthcoming SOC 2 report and our own third‑party penetration test — both tracked publicly on the Trust Center.
Verify & contact
- Live methodology & coverage, sub‑processors, and compliance roadmap: /trust
- Report a security issue: security@millenniums.ai · security.txt
- Data Processing Addendum (with SCCs): available on request
If any statement here does not match what you can verify, tell us — we'll fix the document, not the framing.