Trust

How RemKey is governed

This page is for the person doing the security review, not the person doing the demo. It says what RemKey actually guarantees, how routing changes are controlled, and where the limits are. Nothing here is aspirational: every claim maps to a mechanism in the gateway itself.

How we think about incidents

RemKey's dispatch path has a real fallback order, not a single point of failure. A transient upstream failure retries with backoff first; if that lane is still down, the request fails over once to your next lane, your own second provider key before RemKey's governed pool, and only if nothing responds does a request fall back to a clearly labeled mock response ("mock": true in the response body, never silently substituted). Every response reports which lane actually served it, so a failover is visible, not hidden. We classify incidents by how much of that chain is still standing, the same way we'd want a vendor to tell us what's actually happening to our traffic:

RemKey runs on Cloudflare's edge network, so the platform-level uptime is Cloudflare's, not a number we invent. What RemKey adds on top is the fallback chain above and the guardrail that a provider outage degrades to a labeled mock, never to a wrong or unlabeled answer.

How routing changes are governed

A router that changes its own routing behavior without telling you is the failure mode we built the whole product to avoid. Two mechanisms enforce that:

The audit trail is verifiable, not just logged

Every governed request appends one row to your tenant's hash chain: each row's hash covers the row before it, back to a fixed genesis value. Tampering with, deleting, or reordering a past row breaks every hash after it. That's structurally different from a log you're asked to trust, it's a chain you can check.

• Self-serve export. Generate a signed bundle for your own tenant from the dashboard whenever you want it, no ticket, no waiting on us.
• Ed25519-signed. When signing is configured, the bundle carries a signature over the chain plus the public key needed to check it.
• Independently verifiable offline. The verifier is a single dependency-free script that re-derives the whole chain and checks the signature using nothing but the bundle itself, no call back to RemKey, no reason to trust our servers while you're checking our work.
• Open format, open verifier. The verifier and the full chain-format specification are being prepared for open-source release under MIT, so your auditor can read the checking code line by line, or reimplement verification independently and get the same answer. Proof you can't inspect isn't proof.
• A join key on every response. Every response carries the id of the ledger row it wrote, so you can correlate a specific request to its chain entry without parsing the response body.

What we don't guarantee

Being direct about limits is part of the trust story, not a hedge against it.

• Model output quality. No gateway can guarantee what a model says. What RemKey does instead: on a sample of downrouted requests, it runs the premium model in the background and has a judge model score the two against each other, the quality-hold rate on your dashboard. That's evidence a plain router doesn't produce, not a promise the cheaper model is always right.
• Upstream provider availability. If every configured provider is down, RemKey isn't. The fallback chain reduces single-vendor exposure; it can't eliminate it.
• Content you ask us not to store. Prompt and response text is never written to the audit chain, only metadata (tokens, cost, routing decision, guardrail action). A sampled downroute does send content to a judge model in the background; set x-remkey-no-verify: true on a request to opt it out of that sampling entirely.

Your side of it

• Treat API keys and any provider key you connect as secrets, store them in a secrets manager, not in source control, and revoke a key immediately from the dashboard if you suspect it's exposed. Revocation takes effect on the next request.
• Set spend caps and rate limits for production workloads. RemKey enforces the limits you set, it doesn't guess what they should be.

Subprocessors

Every third party in a position to see in-scope data, published rather than left for a security questionnaire to surface. Sourced from our internal vendor-risk register; kept in sync with it as vendors change.

Which model providers see your traffic is your choice, not ours: BYOK routes to the providers you connect, and the pooled lane (if you opt in) only ever uses the providers in this table. Model origin is published in the catalog so you can apply your own vendor rules on top of ours. Cloudflare is a single point of infrastructure dependence by design, zero servers of our own to add a second one, acknowledged rather than hidden: your signed audit export verifies offline with no dependency on Cloudflare or on us.

Report a security issue

Found a vulnerability or something that looks wrong in the audit trail: email sales@remkey.ai with the details. We'll acknowledge it and follow up directly.