Security
Your provider keys are the crown jewels. We treat them that way.
A gateway holds two things worth stealing: the credentials that let you spend money at 8 providers, and the prompts your users type. This page describes exactly what we do about both, in enough detail that you can check us against it.
Provider keys, envelope encrypted
Keys you add are encrypted with AES-256-GCM under a master key held in the runtime environment, never in the database. A database dump on its own decrypts nothing. Once saved, a key is never returned to a browser - the dashboard shows the last four characters and nothing more.
Gateway keys stored as hashes
Your Final Router key exists in plaintext exactly once, in the dialog that created it. We store a hash and a short display prefix, so we can identify a key in your usage table without ever being able to reproduce it.
Row-level security on every table
Tenant isolation is enforced by Postgres policies, not by a WHERE clause someone might forget. A session can read its own rows and no others, even if application code has a bug.
Prompts are never persisted
Request and response bodies stay in memory for the life of the request. What lands in the database is metadata: model, provider, token counts, latency, status and cost. We cannot leak content we never wrote down.
Hardened edge
TLS 1.2 or better everywhere, HSTS with preload, a strict frame and referrer policy, a locked-down permissions policy, plus WAF and bot mitigation in front of the application. Gateway responses are marked no-store.
Rate limiting and spend caps
Per-key rate limits absorb runaway loops, and a monthly budget is checked before a request is forwarded rather than after it is billed. A leaked key costs you a rotation, not a month of revenue.
How we operate
The practices behind the controls
Controls are only as good as the habits around them. We are a small team, so these are deliberately the kind of practices a small team can actually sustain.
Access control
- Least privilege by default; production access is granted per task, not standing.
- Multi-factor authentication mandatory on every internal system.
- Access reviewed quarterly and revoked the same day someone leaves.
- No engineer reads customer prompt content in the ordinary course of work - there is nothing stored to read.
Building and shipping
- Every change is reviewed before it merges; nothing reaches production directly.
- Dependency and secret scanning run on each change, and a scan failure blocks the merge.
- Infrastructure and configuration are declared in the repository, so a change is auditable.
- Security fixes bypass the release calendar, not the review.
Data and recovery
- Database and application run in the EU (Frankfurt).
- Backups are encrypted, held in the EU, and restore-tested.
- Request metadata is deleted after 24 months; security logs after 90 days.
- Account deletion removes keys, profile and metadata within 30 days.
Incident response
- A named owner takes every report and is on the hook until it closes.
- Customers affected by a personal data breach are told within 48 hours of us becoming aware.
- Post-incident notes describe what happened and what changed, without marketing language.
- Suspected key compromise is rotated immediately, at no cost to you.
Responsible disclosure
Found something? We want to hear it.
Report it to security@finalrouter.com before you publish, and we will acknowledge within 24 hours, agree a fix timeline with you, and credit you when it ships if you want the credit. We will not take legal action against research that follows this policy and stays within the scope below.
In scope
- The gateway API and the application at our production domain
- Authentication, session handling and account takeover paths
- Tenant isolation - reaching another account's keys, usage or billing
- Credential handling, encryption at rest, and key exposure in responses
- Billing logic that lets a request be served without being metered
Out of scope
- Denial of service, volumetric testing, or anything that degrades service for other users
- Social engineering of our team, our customers or our vendors
- Findings from automated scanners with no demonstrated impact
- Missing headers or best-practice warnings with no exploitable consequence
- Vulnerabilities in a model provider's own API - report those to the provider
Test against your own account only. If you happen to reach data that is not yours, stop, tell us what you saw, and delete your copy - that is the report we most want to receive, and handling it that way is what keeps you inside the policy.