Don't trust our privacy claim. Verify it.
MoorAI inspects AI prompts, files, and outputs for risk on the device — by default, none of that content leaves it. That's not a policy we promise — it's how the agent is built, and the agent is open source, so you can confirm it line by line. The exceptions are named on this page, not buried: an admin-enabled capture tier, and image OCR on platforms whose operating system can't do it locally.
Content-free by construction — and you can verify it
Most “privacy-first” AI security tools ask you to trust a data-handling policy. MoorAI removes the need for trust by removing the data from the equation. Every detection runs locally, on the endpoint — the plaintext is never transmitted anywhere to be evaluated. What leaves the device in its place is a fingerprint: a keyed HMAC-SHA-256, truncated to 64 bits and tagged h2:, whose key is derived from your own tenant's enrollment token and never sent to the console.
Why there is a key — and why we lead with it. An unkeyed digest of a small-space value isn't one-way in practice; it's an encoding. There are only about 1010 US phone numbers and 109 Social Security numbers — enumerate the space, hash every candidate, and read the plaintext straight back out of your own table. That was true of the 32-bit djb2 fingerprint MoorAI used to emit (measured reversible in 0–2 ms on a laptop), and it is equally true of a plain SHA-256, which adds no entropy the input never had. Only a secret mixed into the hash input defeats the enumeration. So there is a key. It is derived on your device, it is scoped to your tenant, and it is the thing that makes “one-way” an honest word rather than a marketing one.
A sample fingerprint as the agent emits it: h2:9f3c07a1b26d84e5. It defends exactly the places the plaintext is not and the key isn't either — the console's alert store, the SIEM stream, a log copied off the box. It does not defend against an attacker who already owns the endpoint: that attacker reads the plaintext off disk, and no on-device hash changes that. We'd rather say so than overclaim.
The console receives verdicts and metadata — what class of risk fired, when, on which device, mapped to which framework. It never receives the text that produced the verdict. And because the on-device agent is licensed MIT, you don't take our word for it: read the source, run the agent under a network monitor, and confirm no content egresses. The license makes independent verification a right, not a favor.
Scroll sideways →
| Leaves the device — verdicts + metadata | Stays on the device |
|---|---|
| Risk classification (e.g. OWASP LLM01 match) | Prompt text |
Keyed one-way fingerprints (h2:) used for matching | File contents |
| Detection timestamp | Model output / responses |
| Device & policy identifiers | Any reconstructable plaintext |
| Severity & rule id | The fingerprint key (derived locally, never transmitted) |
The right-hand column describes the default configuration — the two ways that changes are named below, not buried. The mechanism is the guarantee: you cannot leak what you never transmit. Verify it in the source, then confirm it on the wire.
Capture tiers — the honest exception
Content is never stored by default. There is one way it can be retained, it is a choice an administrator makes, and we state it plainly rather than bury it: an administrator can enable a capture tier — for incident investigation or compliance evidence — and a capture tier does store the matched prompt or tool-call text it was turned on to collect. The choice is yours, per tenant, and visible. It is fenced accordingly:
- Off by default. Out of the box no content is captured or stored — you have to turn it on.
- Admin-gated. Only an administrator can enable it — not the agent, not a policy push you didn't author, not an end user.
- Logged. Enabling capture is itself an audited event: who turned it on, when, for which scope.
- Tier-limited. Scoped by tier, not all-or-nothing — enable the minimum needed, not a firehose.
If you never enable a capture tier, MoorAI never stores content. Full stop.
Image OCR — the second exception, and it depends on your platform
A pasted screenshot has to become text before any policy can be run on it. Where the operating system can do that itself, it does: on macOS, MoorAI uses the system's built-in Vision text recognition, so the image is read locally — no network call, no bundled model. Where the OS provides no text recognition, MoorAI sends the image to your own AI provider, using the credential already on the device, and the extracted text is then checked against the same policy as typed text.
We will not dress that fallback up as content-free — on that path the image does reach a third party. What we will say precisely is which third party: it goes device → your provider, the same provider your coding agent is already talking to, so no new party enters the picture — and it never reaches MoorAI. We don't see the image, and we don't relay it.
Detection efficacy — measured, and reproducible
A privacy guarantee is worthless if the tool can't catch anything. MoorAI ships an on-device benchmark that exercises the detection engine against a labeled corpus — including an adversarial red-team set — and reports precision and recall per threat class, mapped to the OWASP LLM Top 10 and MITRE ATLAS. Run it yourself:
npm run benchmark
Results are written to docs/BENCHMARK.md. Because it runs locally against the shipped detection logic, the numbers you produce are the numbers we publish — no hidden test set, no vendor-tuned demo. Current adversarial red-team coverage: 102 / 102 cases caught.
Trust roadmap — what we're committing to next
We won't claim assurances we don't have. Two independent validations are planned; here's exactly what each will prove, and its honest status.
- Third-party zero-egress audit — planned. An external firm will independently verify that the on-device agent transmits no prompt, file, or output content. Because the agent is MIT, the auditor works from the same source you can read. Status: planned, not yet started — we'll publish the report and scope when it completes.
- SOC 2 Type II (console) — in progress. The proprietary console is pursuing SOC 2 Type II covering security, availability, and confidentiality of the backend that receives verdicts and metadata. Status: in progress; report not yet issued. We won't call MoorAI “SOC 2 certified” until an auditor issues the report.
Honest status matters more than a badge. The content-free mechanism and the reproducible benchmark are available today; the audit and SOC 2 are commitments in flight.
Verifiable beats trustworthy.
Read the code, watch the wire, run the numbers — then decide.