TrafficLoopback
Sign in / Sign up

How we protect your API keys

BYOK means you trust us with credentials that have spending power on your accounts. Here's exactly how we store, retrieve, and use them — and what a worst-case attacker would have to compromise to get a plaintext key.

Encryption at rest

Every API key you register is encrypted with AES-256-GCM before it's written to our database. The database row only contains the ciphertext, a per-row initialization vector (IV), and the last 4 characters of the plaintext (for UI display).

AES-GCM is authenticated encryption — it includes a tag that detects tampering. If someone modified a ciphertext row in our database, decryption would fail rather than silently produce a wrong key.

Two trust domains

The encryption master key (used to decrypt the ciphertext) lives in Cloudflare Workers Secrets — a separate storage system from our D1 database. The master key is never written to D1, never returned by any API, and never appears in source code.

For an attacker to recover a plaintext API key, they would need to compromise both:

  1. Our D1 database (to obtain the ciphertext + IV)
  2. Our Cloudflare account's Workers Secrets (to obtain the master key)

These are protected by separate access controls. A breach of one without the other yields nothing usable.

Decryption only at the moment of use

We decrypt your API key just-in-time on each AI generation request inside the Cloudflare Worker isolate that handles that request. The plaintext exists in memory for the duration of the outbound API call only. It is never logged, never persisted, never returned to the client.

If our Cloudflare Worker logs are ever inspected (by us or by Cloudflare staff under support), they show only metadata — provider name, key id, response status — never the plaintext key.

UI display

After you save an API key, the full plaintext is never shown again, even to you, even after re-authentication. The UI displays only the last 4 characters (e.g. sk-...abcd) so you can identify which key is which. To replace a key, you delete the existing entry and add a new one.

Spend caps and revocation

Every key supports an optional daily spend cap in USD that we enforce server-side. If a key is compromised and used to burn through your credits, the cap halts further use the same day.

You can deactivate or delete a key one-click in the dashboard. Active=false keys are skipped by the failover dispatcher immediately, even mid-request.

What you should still do on your side

  • Set spending limits at the provider — every provider supports monthly spend caps in their console. Configure one on every key you register, even if you also set one in TrafficLoopback.
  • Use restricted/scoped keys when the provider supports them. OpenAI supports restricted keys with model-specific permissions — generate a key that can only call chat completions, not fine-tuning or assistants.
  • Rotate keys periodically. Even though our storage is encrypted, rotating quarterly is good hygiene and trivial in our UI.
  • Register multiple providers. If one provider has a security incident (theirs, not ours), our failover routes your generation to a different provider until you've rotated.

What we don't do

  • We don't share keys with third parties. Not Cloudflare, not Google, not anyone. Period.
  • We don't use your keys for our own internal usage. Even if it would save us money.
  • We don't log plaintext keys anywhere. Application logs, error tracking, support tickets — never.
  • We don't store keys in backups in a way that recovers them without the master key. Our D1 backups contain only ciphertext; the master key is backed up separately and only used to roll new isolates, never exported.

What still requires trust

Honest disclosure: nothing about "BYOK with at-rest encryption" eliminates trust entirely. You are still trusting that:

  • We've implemented the encryption correctly (the code is reviewable in our private repo on request)
  • We're actually doing what this page describes
  • Our Cloudflare account isn't compromised by an insider or social-engineering attack

If you can't accept any of those, the only fully-safe alternative is running a self-hosted solution. But for the vast majority of operators, the spend-cap + revocation + at-rest-encryption combination is more protection than most SaaS tools provide for the same kind of secrets.