Security & Privacy
Your traces stay yours.
Snapback is library-first: a known error returns a verified fix with no LLM call, and secret-shaped tokens are scrubbed before the engine sees them. We store the signal — which error, which family, whether the fix worked — not your trace contents. Here is exactly what happens to your data.
What we collect
What we never do
- —Store your full trace contents, request/response bodies, or the data your agents produced.
- —Store full IP addresses (only the coarse /24 network prefix).
- —Train models on your errors or traces.
- —Sell or share your data with third parties.
- —Call an LLM on a library hit — a known error returns a curated, verified fix with no model in the loop.
- —Auto-apply a state-changing fix (payments, auth, mutations) — those always escalate to a human, at any confidence.
Where the data lives
| Data | Handling |
|---|---|
| Metered verdicts + usage events | Retained per your plan for billing + your dashboard. |
| Reported outcomes (the moat) | Anonymized aggregate; the fix-worked signal, not your trace. |
| Free-tier telemetry (family + fingerprint) | Rolling window; anonymous, no PII. |
| The self-heal interceptor | Runs client-side in your process. It sends the error you pass it; the fix is applied by your code. MIT-licensed — read exactly what it does. |
The design, not just the promise
The privacy posture is enforced in code, not policy: redaction runs on the ingest path beforethe engine; the self-heal gate requires source == "library" to auto-apply, so an LLM-assisted fix never applies itself; the interceptor is MIT-licensed and client-side so you can read exactly what it does before you enable it; and a security self-test asserts these hold on every run. Independently audited — findings pre-mitigated. HSTS, secure cookies, and HTTPS-only throughout.
Report a vulnerability
Found a security issue? We run coordinated disclosure and credit researchers on request. Reach us via the contact page. Include steps to reproduce and any proof of concept.