01
Local-only scan
Guard runs on your laptop, your build agent, or your dedicated security box. It connects to your code and your database, and reads samples in-place. No content uploaded. No samples leaked. No telemetry beyond what you opt into.
Product · Guard
Find what is leaking,
before it does.
Guard runs locally on your machine. It scans your code, samples your database, scores how much of your sensitive data is actually encrypted, and prints a SOC 1 / SOC 2-ready report. The file you audit never leaves your laptop.
One command. Forensic proof.
Drop into a terminal. Get a SOC report.
$ npx @nodatachat/guard@latest Database connection found Source: .env.local (Supabase) Connect to database? (y/n): y Scanning code... 1,472 files Scanning database... 6 evidence layers SOC readiness: 48% (51 controls) Code score: 40% DB score: 64% ──────────────────────────── Connection: TLSv1.3 AES-256-GCM Rows encrypted: 35,788 Rows plaintext: 1,551 RLS policies: 204 / 204 (100%) 12 issues found. 3 P1, 5 P2, 4 P3. Report written: ./guard-report-2026-05-01.html Your data never left your machine.
What Guard does
Six capabilities. Local-first.
02
Encryption coverage
For every sensitive field Guard finds, it answers one yes-or-no question: is this value encrypted? Across 14 database engines and 30+ cloud providers. The output is a per-field, per-table coverage map.
03
PII exposure map
A visual map of where personally identifiable data lives in your stack, ranked by risk: cleartext beats hashed beats encrypted, replicated beats single-region, internet-facing beats VPC-only.
04
SOC 1 / SOC 2 readiness
Guard scores 51 controls relevant to SOC 1 and SOC 2. The report is auditor-ready, with every control linked back to the evidence it found and the remediation it recommends.
05
Remediation recipes
For every gap, Guard proposes a one-line fix: which library to call, what migration to run, what RLS policy to add. You can copy-paste, or wire your CI to fail on regression.
06
Scheduled + alerted (Pro)
Guard Pro runs on a cron, stores history, and pings Slack or email when a regression appears. The new field someone added without encryption shows up the next morning, not the next audit.
For the audit
Auditor-ready reports, signed in a chain.
Guard prints two things on every run: a human-readable HTML report you can hand to an auditor, and a signed receipt in the same chain that powers Capsule and Continuum. The auditor sees the controls. The receipt proves the scan actually ran.
Two signatures: HMAC for ordering and integrity, Ed25519 for public verifiability. The receipt is verifiable with the same /api/chain/pubkey that powers every NoData product.
Controls covered
✓CC1 — Control environment
✓CC2 — Communication and information
✓CC3 — Risk assessment
✓CC4 — Monitoring activities
✓CC5 — Control activities
✓CC6 — Logical access
✓CC7 — System operations
✓CC8 — Change management
✓CC9 — Risk mitigation
✓A1 — Availability
✓C1 — Confidentiality
✓PI1 — Processing integrity
✓P1–P8 — Privacy controls
51 individual checks · mapped to your stack
Guard inside Continuum
A single Guard scan tells one story. An org-wide fleet tells the truth.
In Continuum, every team runs Guard on a schedule. The operator console aggregates the results across the org: which services are SOC-ready, which fields regressed this week, which teams need help. The dashboard fills with what to do next.
Standalone or bundled
Guard is a real product on its own. It is also one of the data feeds Continuum operators rely on to know where to act first.
Guard CLI · on every machine
Continuum console · aggregates org-wide
SOC 1 / SOC 2 evidence · for the auditor
Try it now
One command. Five minutes. Your data does not move.
npx @nodatachat/guard@latest, answer one consent prompt, get an HTML report you can mail to your auditor.