The short version
FlowRail sits in the path of code that doesn't exist yet. That makes our security posture mostly one question: what happens to your source between the moment the agent decides to write it and the moment it lands on disk.
- Raw source is never written to FlowRail's database. It's processed in memory and reduced to a verdict plus a SHA-256 fingerprint.
- Secret detection runs locally. When a pinned pattern matches, the write is denied on your machine and the matched string stays there.
- Everything moves over HTTPS. Bearer tokens and dashboard tokens are stored as SHA-256 hashes.
- Every row is scoped to a workspace, and cross-tenant reads are covered by tests that run in CI.
- We're pre-v1 and not certified against SOC 2 or ISO 27001. This page is the honest posture rather than a badge.
The architecture
Three surfaces with different trust properties. Knowing which is which is most of a threat model.
| Surface | Where it runs | What it can see |
|---|---|---|
| The hook | On your machine, inside the coding agent | Everything the agent is about to write. It decides locally what to hard-deny and what to forward. |
| The server | api.flowrail.ai, one region | Content in flight for the length of a request, plus the event store, which holds no content. |
| The CI gate | Your pipeline. v1 roadmap, not shipped today | Planned: the same guardrails applied to a pull request, anchored to the same design review. Today the agent's hooks are the only enforcement surface. |
FlowRail doesn't install a git hook, doesn't touch your git configuration, and doesn't intercept traffic outside the agent's own tool calls.
How your code is handled
The flow: your machine, to api.flowrail.ai over HTTPS, to the configured LLM provider, and back as a structured verdict. The server holds the content only in that request's memory.
What persists is metadata: a SHA-256 fingerprint of the content, the file path, the pass/fail status, and a short reason per guardrail. The events table is not recoverable to original code.
One in-memory exception: a 60-second, FIFO-evicted cache holds recent verdicts (status and per-guardrail results, not content) so an identical re-verify skips the model round trip. It never touches disk and is gone on restart.
What never leaves the laptop
Before anything is forwarded, the hook runs a local regex net over the pending write. Three pinned patterns (Stripe live keys, AWS access key ids, and GitHub personal access tokens) hard-deny the write on your machine.
The agent gets the line number and the pattern id, so it can fix its own mistake and retry. What we receive is a detection record: an id, the file path, the pattern id, and the line number. The wire format rejects any attempt to attach the matched string: the field doesn't exist in the schema, so a buggy or malicious client can't add one.
Encryption and secrets
- In transit: HTTPS everywhere, with plain HTTP redirected at the edge. The MCP endpoint, the events endpoint, the dashboard, and this site are TLS-only.
- At rest: database and disk encryption provided by our infrastructure providers, Neon and Fly.io.
- Credentials at rest: workspace API keys and dashboard tokens are stored as SHA-256 hashes. Key material is shown once at creation, so we can't recover it for you, only replace it.
- Model provider keys live in the platform secret store. The deploy tooling can list the variable names but not read their values back out.
- Dashboard redemption links are single-use: once redeemed, the token id is consumed at the database layer and a replay returns 401.
Tenancy and isolation
One database, one container, one region. Every row carries a workspace id and every query is scoped to it. Integration tests in CI issue two workspaces' credentials and assert that one can't read the other's events through any MCP tool, dashboard endpoint, or direct read path.
Logging and monitoring
- Request and response bodies are not logged. Validation errors are scrubbed before they're serialized.
- A log filter rewrites every record (message, arguments, tracebacks, stack info), replacing three credential patterns (Stripe live keys, AWS access key ids, GitHub tokens) with a redaction marker.
- The same scrubber runs before anything reaches Sentry, which is only enabled when a deployment configures it.
- The honest limit: that scrubber is a floor, not a ceiling. It doesn't match FlowRail bearer tokens or arbitrary code snippets, so an unusual exception path could put a snippet into logs. Log retention is a few days.
What happens when we fail
The verifier is fail-open by default: if the model call errors or a quota is exhausted, the write proceeds and the agent is shown a visible warning rather than being silently blocked. Fail-closed is opt-in today via configuration, and becomes the default in v1.
We'd rather you read that here than discover it during an incident. The full list of known limits ships in the repo alongside the code.
Self-hosting
If your security team blocks the shared server, the same container image runs as a Docker Compose bundle: your Postgres, your volume, your model credentials, no shared quota and no shared event store.
What that guarantees: FlowRail's server never sees your code. What it doesn't: that your code stays inside your network. The model call still happens. Only the destination changes. Code stays in-network only if the endpoint you configure is itself local.
Responsible disclosure
If you've found a vulnerability in FlowRail, we want the report and we won't punish you for it. Email us with enough to reproduce: the affected endpoint or package, the steps, the impact, and any proof of concept.
We'll acknowledge within three business days, tell you what we found and when we expect to ship the fix, and credit you when it lands if you want the credit. We won't pursue legal action over good-faith research that stays inside the scope below. There's no paid bounty program yet.
| In scope | Out of scope |
|---|---|
| api.flowrail.ai and the dashboard it serves | Volumetric or denial-of-service testing |
| flowrail.ai and this web app | Social engineering of our team, our customers, or our vendors |
| The published FlowRail npm packages, hooks, and skills | Findings in Neon, Fly.io, Clerk, or an LLM provider. Report those to them |
| The MCP tool surface and its wire contracts | Scanner output with no demonstrated impact |
Test against your own workspace and your own data. Don't access, modify, or retain another workspace's data. If you find a path to it, stop and tell us. A proof of concept that demonstrates the path is enough.
Where this stands
FlowRail is pre-v1. We're not SOC 2 or ISO 27001 certified, we don't have a third-party penetration test report to hand you yet, and the isolation guarantee above is test-enforced rather than architectural. When that changes, this page changes.
The full data-flow write-up, covering every payload, every stored column, and every scrub rule, is maintained alongside the code and is the document to hand your security reviewer. Ask and we'll send it.