Privacy model
Guardrail is metadata-first, local-first, and explicit. It is a proxy you point your tools at on purpose: there is no traffic interception, no root certificate, and no HTTPS decryption.
What it sees versus what it keeps
Because Guardrail forwards your requests, it necessarily sees request and response bodies in memory while relaying them. It parses a handful of metadata fields and discards the bytes.
| Data | Stored | Notes |
|---|---|---|
| Model, provider, endpoint | Yes | |
| Token usage (input, output, cache) | Yes | As reported by the provider |
| Cost estimate and confidence | Yes | Computed from your price table |
| Latency, HTTP status, error type | Yes | |
| Session, agent and project ids | Yes | User ids are hashed unless already opaque |
| Upstream request id | Yes | So you can cross-reference a provider bill |
| Prompt text | No | Hooks store a length and a salted hash only |
| Response text | No | Never persisted |
| Source code and file contents | No | Never persisted |
| Tool input and output | No | Tool name and category only |
| Shell command text | No | Length and salted hash only |
| Raw request and response bodies | No | Never persisted, never logged |
| API keys, yours or upstream | No | Never in the database, logs, API or errors |
Enforced, not just promised
A privacy claim that lives only in documentation drifts. This one is checked by the build:
- One internal package is the single chokepoint for hashing and redaction, so there is one place to audit rather than many.
- Every structured log line built from request data is filtered through it, dropping content-bearing fields and masking credential-bearing ones.
- Hook payloads are reduced to fingerprints in memory; the raw payload is never written anywhere.
- The test suite sends a known secret prompt through both the proxy and the hook receiver, then scans every byte SQLite wrote to disk— database, WAL and shared-memory files — for that secret. If it ever appears, the build fails.
The local salt
On first run Guardrail generates a random 32-byte salt and keeps it in your local settings. Every fingerprint is a hash of that salt plus the value, so identical prompts on two machines produce different fingerprints and nothing can be correlated across installs. The salt never leaves your machine, including when cloud sync is on.
Cloud sync
Sync is opt-in and off by default on Free, Trial and Pro. Machines on a Team plan sync by default, because the admin spend view and shared caps run on synced usage; guardrail sync off opts a machine out at any time and always wins over that default.
What syncs is the same metadata described above — never prompts, responses, code, or the local salt. What it enables is the hosted dashboard, longer history and cross-machine views. See machine security for how a machine is identified and revoked.
Website analytics
This website measures itself with a small first-party pipe into our own database. No third-party analytics script, no ad-tech vendor, no cross-site tracking. What an event carries: the page path (never the query string), a random browser id and a random session id that you can clear at any time, the referring site’s hostname, campaign tags when you arrived through a tagged link, a coarse device size (desktop, phone, tablet), and a two-letter country code derived at the edge. What is never stored: your IP address, your email, full referrer URLs, or anything you type. Events are deleted after 180 days.
The site honors the Global Privacy Control signal, and you can opt out right here — opting out also deletes the ids this browser holds:
Checking your analytics preference…
The cookies this site sets
There are no advertising cookies and no third-party cookies of any kind: no external script runs on these pages at all. The site sets four first-party items in your browser, and nothing else.
| Name | What it is | Lifetime |
|---|---|---|
np_aid | A random id for this browser, so five page views read as one visit rather than five. Not your name, not your email. | 180 days |
np_sid | A random id for the current visit, replaced after 30 minutes of inactivity. | 180 days |
np_optout | Records that you opted out, so we can keep honouring it. Set only if you use the button above. | Until you clear it |
sb-*-auth-token | Your sign-in session for the hosted dashboard. Only set once you sign in, and required for the account to work. | Session |
The first two are the ones the opt-out removes. They are stored twice, as a cookie and in local storage, because a form you submit is handled on our server and the cookie is how that request knows it belongs to the same visit. Clearing site data in your browser removes all of them.
Who processes what
The data controller is NeatProxy (contact below). Infrastructure the site and service run on, each processing only what their role requires: Vercel (hosting), Supabase (database), Stripe (payments — card details go to Stripe directly and never touch our servers), and Resend (transactional email). You can ask us to export or delete the data we hold about you at any time via the address below.
Two collection points are worth naming because they are the only places this site asks for your email. The activation-code form sends your address to Resend so the code can reach you, and stores it so the same code can be resent. The product-updates form in the footer stores your address and adds it to our Resend mailing audience, together with the site that referred you; that one is marketing, and you can ask us to remove you at any time at the address below.
Questions, a data request, or a privacy issue to report: admin@neatproxy.com.