Security overview
Guardrail sits in the path of your AI traffic, which is a position that has to earn trust. This is what it does with that access, what an adversarial review of it found, and what it deliberately does not defend against.
The threat model
Guardrail is a single-user local tool. It binds to 127.0.0.1, holds no provider API keys of its own, and stores metadata in a file you own. The design goal is that compromising Guardrail should not give an attacker anything they could not already get by reading your home directory.
It is not a network service, not multi-tenant, and not a traffic interceptor: there is no certificate to install and no TLS to decrypt, because your tools are pointed at it explicitly.
What the review found
We ran an adversarial review across six attack surfaces — credential handling, authorization, the CLI, the installer, proxy behaviour including SSRF and denial of service, and the web and data layer — with every candidate finding independently re-checked against the code.
The result was no exploitable vulnerabilities for that threat model. Of 33 candidate findings, all were out of model, already mitigated, or accepted and documented tradeoffs. Two low-severity hardening items were fixed anyway: the connect command now preserves the permissions of config files it edits rather than widening them, and the installer verifies release checksums.
Verified safe
| Area | Finding |
|---|---|
| Prompt and credential leakage | Request and response bodies are forwarded and discarded, never logged or persisted. Headers are redacted before logging, and token comparisons are constant-time. |
| SQL injection | Every query is parameterized. The only dynamic SQL is an ORDER BY chosen from a closed set of values, never from user input. |
| SSRF | The upstream host is fixed by configuration. A client cannot redirect the proxy at an arbitrary target. |
| Denial of service | Proxy, hook and telemetry bodies are all size-limited, and the compressed telemetry path limits the decompressed stream, so a compression bomb cannot exhaust memory. |
| Path traversal | The dashboard is served from a read-only embedded filesystem. There is no host filesystem access from the web surface. |
| Install integrity | The installer downloads a checksum file with each release and verifies the archive’s SHA-256 before installing, refusing on mismatch. |
Tradeoffs we accept
Listing these is more useful than implying they do not exist.
- Any local process can read the dashboard. Inherent to a single-user tool bound to loopback. If something hostile is already running as you, the dashboard is not the weakest thing it can reach.
- Binaries are not yet notarized. Deliberate for an early distribution, with checksum verification in the installer as the interim control. Signing and notarization are on the roadmap.
- A token can ride in a query string. Only for the live-update stream, whose browser API cannot send headers, and only when you have deliberately exposed the dashboard beyond loopback.
What leaves your machine
By default, nothing. Cloud sync is opt-in on Free, Trial and Pro; Team machines sync by default so shared caps and the admin spend view work, and guardrail sync off overrides that at any time.
When sync is on, what travels is metadata — models, token counts, costs, timings — over HTTPS, stored encrypted at rest. Prompts, responses, code and credentials never do. The field-by-field list is in the privacy model, and machine identity and revocation are covered in machine security.
Reporting an issue. Email admin@neatproxy.com before disclosing publicly and we will work the issue with you. There is no paid bounty today, but we will credit you unless you would rather we did not.