Security

Built so a mistake stays small

A gateway holds the keys to your AI spend, so it is designed around containment: separate data per organisation, secrets that never leave, and limits that fail closed.

Isolation between organisations

Each organisation's keys, usage and logs live in a database file of its own. No table holds more than one organisation's data, so no query can cross between them.
Each organisation signs in on its own subdomain, and an address that does not belong to an organisation answers exactly as one that never existed.

Secrets

Vendor keys are encrypted with AES-256-GCM under a master key held outside the database. They are decrypted in memory only for the upstream call.
No API ever returns a vendor key, a virtual key's secret or a two-factor seed, and none of them is written to logs. Our tests read the raw database files to prove a vendor key is never stored in plain text.
Virtual keys are shown once, at creation, and stored only as a hash.

Signing in

Passwords are hashed with argon2id. Two-factor authentication is mandatory for every role, with ten single-use recovery codes.
Sessions are bound to the browser that created them, sign-in attempts are rate limited, and a sign-in from a new device is reported by email.
The operator's console can be restricted to a list of IP ranges.

Where a key may be used from

Every virtual key carries an address list. A key that may be used from anywhere has to be set that way on purpose, and the console flags it in red.
An address nobody can name in advance is added by opening a ten-minute window that takes exactly one new address and closes itself — not by trusting whoever calls first.
Traffic is served over HTTPS only, and client addresses are taken from our own proxy, never from a header a caller can set.

What happens when a key leaks

Every refused request is recorded: which key, from which address, with which client, when and why. The secret that was presented never is.
A key refused from five different addresses it has never worked from within an hour is suspended automatically, and the owner is told. One address retrying, however often, is a broken client and is not treated as an attack.
Wrong secrets never suspend a key, however many are tried — otherwise anyone who learned a key's public id could switch it off. They are recorded, and five within an hour raise an alert.
A revoked, suspended or expired key that is still being called raises an alert at once, because it means a client somewhere still holds a secret that should be gone.
The money it can reach is bounded whatever happens: the key's own budgets, the monthly cap on the vendor key it routes through, and the organisation's ceiling are all checked before a vendor is called.

Failing safely

Rate limits, budgets and credit are checked before a request is sent to a vendor. If the service that enforces them is unreachable, requests are refused rather than allowed through without limits.
A vendor key that the vendor rejects is marked unhealthy and taken out of rotation.

Audit and data handling

Every change to keys, members, vendor keys, credit and settings is recorded with who made it and the values before and after.
Prompts and completions are not stored unless prompt logging is switched on for a key, and stored bodies are purged on the retention schedule.
Refused requests are kept for ninety days, with the address and the client but never any part of a secret.
Usage records are kept for thirteen months by default, then deleted.

Found something?

If you believe you have found a security issue, tell us through the contact form and choose Support. We will get back to you quickly and keep you informed while we fix it.

Report an issue