Why Lucairn doesn't have
a credential-table breach to worry about.
In April 2026, LiteLLM CVE-2026-42208 — CVSS 9.3, pre-auth SQL injection — was exploited within 36 hours of disclosure. Attackers targeted the litellm_credentials table: workspace-admin keys for Anthropic, OpenAI, AWS Bedrock. The breach didn't happen because the LiteLLM team made one bad decision; it happened because the architectural class — AI gateway with a shared credentials backend — has a single point of failure that any pre-auth bug exposes. Lucairn ships a different class. This page explains the difference, in five bullets and one comparison table.
A pre-auth SQLi,
and one table to attack.
CVE-2026-42208 was an unauthenticated SQL injection in LiteLLM's authentication path. The injection point reached the litellm_credentials.credential_values column — the table holding workspace-admin keys for upstream LLM providers (Anthropic, OpenAI, AWS Bedrock). Attackers attempted to extract the column, decrypted what they could, and pivoted directly into customer Anthropic / OpenAI / Bedrock environments via the stolen keys. NVD published April 2026; in-the-wild exploitation followed within ~36 hours.
The load-bearing observation: this isn't a LiteLLM-specific bug pattern. Any AI gateway that holds a shared credentials backend has the same architectural exposure. The credentials-table-as-blast-radius is the issue, not the SQLi specifically. A pre-auth bug — SQLi, deserialisation, auth bypass, file traversal — in any gateway with this shape exposes every customer's upstream keys at once.
BYOK passthrough,
by construction.
The Lucairn gateway never persists upstream LLM keys. The architecture is straightforward:
- Per-request, never stored. Customers send their upstream key on each request via the X-Upstream-Key header (BYOK passthrough). The key is read once, used to authenticate to the upstream provider (Anthropic, OpenAI, Mistral), then discarded.
- No lucairn_credentials table. There is no shared backend store of customer LLM keys. Nothing for an attacker to attack.
- Verified in code. The constraint is asserted at the proxy boundary. From src/app/api/sandbox/run/route.ts:32 — `// - BYOK key NEVER persisted, NEVER logged.`
- Lucairn API keys are scoped differently. Lucairn does mint its own gateway-API keys (lcr_live_*) for rate-limiting and quota, but those are gateway-API keys, not upstream LLM keys. Compromising one is bounded to the customer's own gateway-call rate, not their cloud-LLM bill.
The architecture is the protection. Code that doesn't store a secret can't leak that secret.
Five properties
that move on the spec sheet.
Each bullet below is a real, procurement-relevant property a security or compliance reviewer can check in a vendor questionnaire. None require taking Lucairn's word for anything beyond what the gateway code shows.
Blast radius after a pre-auth bug.
Shared-cred gateway: every customer's upstream LLM keys leak in a single dump. BYOK passthrough: zero credential exposure — the gateway has nothing to leak.
Recovery time.
Shared-cred: rotate every customer's upstream keys at every cloud-LLM provider, retrain detection rules, apologise to N enterprise customers. BYOK passthrough: the bug gets patched. No upstream-key rotation needed.
Evidence trail.
Shared-cred: gateway logs are the only history of which customer used which upstream key when. BYOK passthrough: the customer's own provider console (Anthropic, OpenAI dashboards) shows the full picture; the gateway is incidental to the upstream-API audit trail.
Regulator's first question.
“Show me the data flow.” Shared-cred answer: a credentials table sits in scope, holding cross-customer secrets. BYOK passthrough answer: no such table exists; the upstream-key flow is per-request, in-memory, discarded after the call.
Insurance and DPA exposure.
A shared-cred gateway breach is a notifiable Article 33 GDPR incident for every affected customer (their upstream-LLM credentials are the leaked personal-data-adjacent secrets). BYOK passthrough: a Lucairn-side breach doesn't expose customer LLM keys at all, narrowing the notification surface to whatever else the gateway was holding.
Shared-cred gateway
vs Lucairn BYOK passthrough.
Same eight properties a procurement reviewer typically asks about. Read the column you'd rather defend in an audit.
| Property | Shared-cred AI gateway | Lucairn BYOK passthrough |
|---|---|---|
| Upstream LLM key storage | Persisted in a credentials table, referenced per request | Never persisted. Read from header, used once, discarded |
| Pre-auth bug blast radius | Every customer's upstream keys exposed in a single dump | No credentials-table to dump. Bug is patched in place |
| Key rotation after vendor breach | Customer must rotate every upstream-LLM key at every provider | No upstream-key rotation needed |
| Audit trail of upstream key use | Held by the gateway | Held by the customer at the upstream provider (Anthropic / OpenAI console) |
| GDPR Art 33 notification surface (vendor side) | Every affected customer (cross-customer secret leak) | No upstream-key leak; surface narrows to other gateway-held data |
| Regulator data-flow answer | A shared-credentials backend is in scope | Per-request passthrough, no shared backend |
| Lucairn API key (lcr_live_*) | — | Stored, used for rate-limiting and quota only. Compromise bounded to customer's own gateway-call rate |
| Code reference | Implementation-specific | src/app/api/sandbox/run/route.ts:32 — `// - BYOK key NEVER persisted, NEVER logged.` |
The honest scope
of this advantage.
- Lucairn does not claim immunity to all AI-gateway risks. The gateway has its own bugs to worry about — input parsing, sanitizer regressions, prompt-injection-via-header, dependency CVEs. Each of those has its own mitigation track and its own incident history.
- BYOK passthrough only protects what's in scope. Customer prompts still flow through Lucairn's pipeline, get sanitized, and get signed evidence cut. That pipeline has its own failure modes, documented elsewhere on this site (see /security and /compliance/eu-ai-act).
- The architectural advantage is specific. The CVE-2026-42208 class — credentials-table compromise — is structurally not possible in Lucairn's model because the table doesn't exist. That's a real reduction in blast radius. It is not a claim about every other vulnerability class, and it is not a claim about Lucairn being audit-certified for any standard.
Try the proxy
or audit a real cert.
The architectural claim is checkable. The sandbox shows the BYOK passthrough flow end-to-end; the verify page lets you audit a real signed certificate without contacting Lucairn.
REFERENCES
- NVD · CVE-2026-42208
- Sysdig · CVE writeup
- src/app/api/sandbox/run/route.ts:32 (in-repo)