How FlowRail handles your code.

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.

• ·FlowRail does not store the original source files or specification bodies in its database. It stores review requirements, findings, verdicts, file paths and content fingerprints. These derived records describe your code and design; they are not a promise that no information from your submission is retained.
• ·Request and response bodies are not intentionally captured in application logs. Credential-pattern redaction and error scrubbing reduce exposure, but they do not remove every possible code or specification snippet. An unusual exception can include a snippet in hosting logs or, when enabled, error-monitoring traces.
• ·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 in beta 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.

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. The CI gate is a workflow file the installer writes into your repo, authenticated with a project token that can only verify. There is no GitHub App and no FlowRail-owned check run yet, so an edit to that workflow is diff-visible and audited rather than prevented.

How your code is handled

The flow: your machine, to api.flowrail.ai over HTTPS, to the configured model provider or providers, and back as structured results. Submitted content is held in server memory while the analysis runs. A background review or verification job can continue beyond the initial HTTP response.

FlowRail does not store the original source files or specification bodies in its database. It stores review requirements, findings, verdicts, file paths and content fingerprints. These derived records describe your code and design; they are not a promise that no information from your submission is retained.

Result caches can reuse a completed verdict for an identical check. They store derived analysis results rather than an archive of the original submitted files. The database storage promise is separate from the exceptional-log caveat below.

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 intentionally captured in application logs. Credential-pattern redaction and error scrubbing reduce exposure, but they do not remove every possible code or specification snippet. An unusual exception can include a snippet in hosting logs or, when enabled, error-monitoring traces.
• ·The log filter redacts recognized credential patterns in messages, arguments and traces, including supported FlowRail token formats. Validation errors are scrubbed before serialization. Pattern matching is not a guarantee that arbitrary sensitive text is removed.
• ·When Sentry is configured, its scrubber removes captured request bodies, selected sensitive headers, stack-frame local variables and breadcrumb data, and redacts recognized credential patterns. Exception text can still contain an unrecognized snippet.
• ·Hosting logs and optional error-monitoring traces have their own configured retention. Contact us for the current deployment settings; the database storage policy is not a guarantee of zero log retention.

What happens when we fail

With the default settings, a write tied to an active design review pauses if its security check cannot finish. A write without an active design review can proceed during an API error or timeout, without a completed security check. Explicit failure-mode settings can change this behavior.

In enforce mode, blocking findings and incomplete verification prevent a passing CI gate result. Operational failures need attention or a retry. Advisory mode is for calibration and does not establish merge protection; the project must be in enforce mode and the check required in branch protection.

An incomplete check is neither a security pass nor a reported vulnerability. Retrying unchanged content can collect a completed result. Local secret-pattern blocks do not depend on API availability. Under the default settings, supported new-dependency introductions also wait for a verdict rather than proceeding on a failed dependency check.

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.

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 in beta. 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.