Encryption: at rest and in transit
TLS 1.2+ on every public endpoint with HSTS preload, AES-256 at rest across Postgres, Redis, and object storage. Virtual keys are SHA-256 hashed on creation; the plaintext is shown once and never stored.
Security
Security you can audit, not just take our word for
NemoRouter is the gateway for every prompt, every key, and every dollar of spend. This page is the engineering deep-dive: the request path, the RLS contract, and the credit-safety invariants auditors walk through.
security · architecture · contract
Architectural invariants
TLS1.3
RLS-protected tables100%
USING (true) policies0
Master-key surfaceisolated
Customer LLM authvirtual keys only
Reserve + settleenforced
CSPHSTSSOC 2 controlsGDPRHIPAA-eligible
- Uptime SLA
- 99.9%
- Encryption
- AES-256
- RLS-protected tables
- 100%
- Master-key surface
- 0 customer paths
Backed by managed Cloud Run + Supabase
At rest + TLS 1.2+ in transit
Every Nemo table, no exceptions
LLM traffic uses virtual keys only
Framework status (SOC 2, GDPR, HIPAA, PCI) lives on the compliance page; documents and posture on the trust center.
Architecture
Always-in-path, by design
Every request flows through Nemo Backend before it touches a provider. Auth checks, RLS scope, credit reservation, and guardrails all live on the same hop. There is no shortcut path for the frontend to call an LLM directly.
Request flow
Client / SDK
Bearer sk-nemo-…
Only virtual keys leave the client; master keys never ship.
Frontend (Next.js)
Cloud Run
Server actions add auth + RLS scope before forwarding.
Nemo Backend
NemoRouter
Auth, credit reserve, guardrails, observability — in path.
Nemo routing core
Routing engine
Cost & usage tracking, rate limits, provider fallback chains.
Provider
Vertex / Anthropic / OpenAI
Outbound traffic only; no inbound provider calls.
The Nemo routing core is fully managed. Every request is authed, scoped, and guardrailed before it reaches a provider, with nothing for you to harden.
Defenses
Six layers, all on by default
Every NemoRouter customer gets the full security posture from day one. No “Enterprise tier” for SSO, audit logs, or guardrails. These are not features we sell, they are guarantees we ship.
Tenant isolation by default
Row-Level Security on every Nemo table, every policy scoped by organization_id. No `USING (true)` anywhere. Cross-tenant reads are impossible at the database layer, and a continuous gap-hunter scanner verifies the contract holds.
Virtual keys for every LLM call
Customer LLM traffic only ever uses virtual keys (sk-nemo-…) with per-key spend tracking, RPM/TPM caps, and instant revocation. Master keys are reserved for internal management CRUD. Never the dashboard, playground, or your code.
Hardened request path
Every request passes through auth, RLS scoping, guardrails, and credit reserve+settle before it reaches a provider. CSP, X-Frame-Options, and Stripe webhook signature checks ride on every response and event.
Five guardrails on every request
PII redaction (Microsoft Presidio), prompt-injection detection, secret scanning, abuse blocking, and response scanning. Included on every plan, configurable at org > team > key scope.
Audit-grade observability
Every administrative action, key change, guardrail trigger, and budget event is logged with actor, source IP, payload diff, and timestamp. Append-only, exportable as CSV/JSON for SIEM ingestion. 90-day request log retention; longer on Enterprise.
Deep Dive
Postgres Row-Level Security, on everything
Multi-tenancy is enforced at the database, not the application layer. The application can have bugs; the database refuses to return rows from the wrong tenant.
Tenant isolation
One tenant boundary, enforced at the database
Every record is scoped to your organization, and Row-Level Security enforces that boundary at the database itself. A query against the wrong tenant returns zero rows. There is no mapping table to drift, no sync layer to compromise.
- Owner / Admin / Member / Viewer roles enforced via RLS policies
- Service role bypasses RLS only inside server-side API routes
- Continuous gap-hunter scanner verifies cross-tenant denial
- Org switch invalidates every TanStack Query cache key
psql · nemo schema
RLS policy spot-check
organization_billing4 / 4 policies
credit_balances4 / 4 policies
guardrails4 / 4 policies
audit_trailappend-only
USING (true) policies0
every tableorg-scopedno gaps
Money Safety
Credits never go negative — under load, under failure, under attack
Every LLM request reserves credits before forwarding and settles after the cost header arrives. Failures release the reservation. There is no path to a negative balance because the database refuses to write one.
Reserve + settle
Atomic credit mutations
The credit ledger applies every increment/decrement atomically, so concurrent writes never race. Webhooks are idempotent on Stripe event id. Reservations expire automatically if a request never settles.
- reserve → forward → settle with cost from x-nemo-request-cost
- Held credits released on every failure path (4xx/5xx/timeout)
- 402 returned cleanly when a key would breach budget — no partial debit
- Daily ledger parity check verifies total spend == balance
credit_ledger · architecture · contract
Money-safety invariants
Atomic mutationsevery write
Reserve → settleevery LLM request
Release on failure4xx / 5xx / timeout
Negative-balance writesblocked at DB
Webhook idempotencyon Stripe event id
Engineering principle
Built audit-ready from day one. Not retrofitted before a procurement call.
RLS, virtual keys, master-key isolation, reserve+settle credit safety, and the audit trail are non-negotiable invariants in our platform, enforced by tests that block merges, not by promises on sales calls.
Data residency
Pin where your data lives
Customer data lives in managed Postgres with at-rest encryption, replicated within a single region. United States is the default footprint. EU residency is generally available on Enterprise; the UK, Canada, Australia, Singapore, and India are available on request, covering GDPR data-locality requirements and the residency expectations of the EU AI Act.
United States (us-central1)GA
US East (Virginia)GA
European Union (europe-west4)On request
EU North (Stockholm)On request
United Kingdom (London)On request
Canada (Montréal)On request
Australia (Sydney)On request
SingaporeOn request
India (Mumbai)On request
Default US runs on us-central1; EU on europe-west4 with Supabase Postgres co-located and subprocessors signed under EU SCCs. Need a region pinned? sales@nemorouter.ai.
Session & tokens
Idle, refresh, revoke: predictable session policy
Sessions are managed by Supabase Auth. Idle timeout is enforced from the dashboard, refresh tokens rotate transparently, and users can revoke active devices from their account page.
Idle timeout: 30 minutes (default). Inactive dashboard sessions surface an idle warning at 25 minutes and force re-auth at 30. Configurable per-org for enterprise.
Refresh-token rotation. Refresh tokens rotate on every use (Supabase Auth). A leaked refresh token is invalidated the moment its successor is issued, and the user is force-signed-out across all devices.
Device management. Account → Security lists every active session by device, OS, and last-seen IP, with one-click revocation. Kill the session before an attacker reaches the dashboard.
Session vs API key. Dashboard sessions sign management calls only. Every LLM request uses a virtual API key with its own RPM/TPM/budget caps. A compromised session cannot run unbounded inference.
Disclosure
Reporting a vulnerability
If you discover a security issue, please report it responsibly. We acknowledge within 48 hours, target 7 days for critical fixes, and follow coordinated disclosure.
FAQ
Common security questions
Where is data stored, and can I pin a region?
All customer data lives in managed Postgres (Supabase) with at-rest encryption, replicated within a single region. United States is the default footprint. EU residency is generally available on Enterprise; the UK, Canada, Australia, Singapore, and India are available on request for residency-sensitive workloads. We do not move tenant data across regions without an explicit migration request.
Is NemoRouter SOC 2 certified?
Not yet — and we will not say "certified" until the report is signed. NemoRouter operates SOC 2-aligned controls today: encryption, access control, audit logging, change management, and tenant isolation, enforced from day one. A formal SOC 2 Type II observation period is currently underway, with the audited report targeted for Q3 2026. The underlying infrastructure (Google Cloud Run, Supabase) is independently SOC 2 Type II certified. Enterprise customers who need assurance before the report lands can request a controls walkthrough or a completed vendor security questionnaire from security@nemorouter.ai.
How does NemoRouter prevent cross-tenant data access?
Every Nemo table has Row-Level Security enabled with policies scoped by organization_id, so a query against the wrong tenant returns zero rows — there is no "leaky path" to fix because the database refuses to return them in the first place.
What if my virtual key is leaked?
Virtual keys are tenant-scoped, rate-limited, budget-capped, and observable. Revocation is immediate from the dashboard or API; the in-memory cache invalidation propagates within seconds. Keys are hashed in the database. The plaintext is shown exactly once at creation. The blast radius of a leak is the budget on that single key, not your account.
Are AI guardrails included on every plan?
Yes. PII redaction, prompt injection detection, secret scanning, abuse blocking, and response scanning all run on every request from day one — at zero additional cost. We do not gate safety features behind paid tiers.
How do I report a vulnerability?
Email security@nemorouter.ai with details. We acknowledge within 48 hours and aim to resolve critical issues within 7 days. We follow responsible disclosure practices and credit reporters in our changelog when permitted.
Security review · 30 minutes
We will walk your security team through the controls
No NDAs to start, no sales gate. Bring your auditor. They will get the same answers we give the engineering team.