BYOK breach: the blast radius when an AI gateway is hacked

What happens if an AI gateway is breached? It depends on what the attacker reached. A gateway that holds many customers' provider keys can be breached in three different ways — its stored credentials copied, its running request path taken over, or its configuration changed — and each has a different blast radius and different limits. In every case, a provider key that leaves the gateway can be used directly against the provider, where none of the gateway's controls apply. The customer's provider-side settings decide how much that costs.

This guide models the three breaches, the controls that limit each, and what a customer can do before and after. It applies to any bring-your-own-key platform: AI gateways, coding agent consoles that share keys across a team, chat products that store keys server-side. INFRO is one of them, and its section near the end is written to the same standard.

Why a BYOK platform is a concentrated target

A bring-your-own-key platform exists to hold credentials to accounts it does not own. That concentration is its value — one place to scope, rotate, limit and audit — and its risk: one breach can expose keys from many organizations at once. The incident OpenCode disclosed in October 2026 is an example of the shape: according to Infosecurity Magazine, OpenCode's notification said third-party provider keys saved in a workspace may have been exposed, and the service it described holds each workspace's provider credentials and uses them to authenticate requests¹.

What an attacker can do with that concentration depends on which part of the platform they reach.

Three breaches, three blast radii

The rows are not exclusive. A real incident often starts in one row and moves to another: a stolen deploy credential (row two) can be used to read the encryption key (row one).

Breach one: stored credentials are copied

This is the breach encryption at rest is designed for, and the one where design choices matter most.

Where the encryption key lives

A gateway must recover your provider key in plaintext to call the provider, so it has to encrypt rather than hash it, and something must hold the key that decrypts. The common pattern is envelope encryption: AWS describes it as encrypting data with a data key and then encrypting that data key under another key, with one top-level key that must remain in plaintext somewhere so everything else can be opened². OWASP's guidance is the corollary: do not store keys next to the secrets they encrypt unless those keys are themselves encrypted³.

The blast radius follows directly:

• Database or backup only: the attacker has ciphertext. Without the encryption key it opens nothing.
• Database plus the encryption key: the attacker can open every credential sealed under that key. If one key protects every customer, that is every customer.

So the first question about any platform is where that top-level key lives and who and what can read it. A cloud key management service, or a platform secret such as a Cloudflare Worker secret — which Cloudflare describes as an encrypted value that is not visible in Wrangler or the dashboard after it is set⁴ — keeps it out of the database, its backups and its exports. It does not keep it away from the code that runs with it, which is breach two.

Binding each credential to its row

Authenticated encryption such as AES-GCM produces a tag that fails if the ciphertext or the additional authenticated data changed⁵. Supplying the tenant and connection as that additional data means a sealed value only opens in the row it was sealed for. That stops a specific attack — someone with write access moving tenant A's sealed key into tenant B's row so B's traffic runs on A's account — and it fails closed. It does not stop theft: an attacker who holds the encryption key also knows the labels. BYOK credential architecture shows the pattern in code.

No read path, and rotation

A platform that never returns a stored credential — no reveal button, no API field, no export — removes the cheapest way to steal one: a compromised admin session. Rotating the encryption key limits how long one key protects data; NIST lists limiting the exposure if a single key is compromised among the purposes of a cryptoperiod⁶. But rotating the platform's encryption key after a theft does not un-steal anything. Keys that were opened are in the attacker's hands in plaintext, and only revoking them at the provider ends their use.

Breach two: the request path is compromised

Encryption at rest protects data at rest. A gateway decrypts your provider key on every request it serves, so an attacker who controls the code running in the gateway sees keys in plaintext as they are used, and the prompts and responses that pass through with them. No storage design changes this; it is the price of a service that calls providers on your behalf.

The ways in are the ones every service has: a poisoned dependency, a compromised build or release pipeline, a stolen deploy credential, a vulnerability in the service itself. The March 2026 LiteLLM incident shows the first two. LiteLLM said two releases published to PyPI contained a credential stealer that harvested environment variables, cloud credentials and other secrets, that it believed the compromise came through a security scanner used in its CI/CD, and that the attacker bypassed the official release workflow to upload directly⁷. Any process running those versions with provider keys in reach exposed them. LiteLLM alternatives in 2026 and AI supply chain attacks in 2026 cover the lessons.

What limits this breach on the platform side is release discipline: dependencies pinned by hash, publishing with short-lived credentials, deploy credentials scoped and protected, and a separation between the services that hold keys and everything else. What limits it for the customer is entirely provider-side.

Breach three: the configuration is tampered with

An attacker who signs in as an administrator, or steals a management token, does not need your provider keys to cause damage. Depending on what the platform allows, they can:

• point a route or connection at an endpoint they control, so your prompts go there;
• raise or remove budgets and model allowlists, so your own traffic spends more;
• add a member or issue a gateway key for themselves, and spend through your connections;
• read request history and, if the platform records it, prompt and response content.

The limits here are ordinary account security, applied with care: two-factor authentication or SSO for everyone with admin rights, roles that separate who can change providers from who can read analytics, configuration credentials that cannot call models (and model keys that cannot change configuration), secrets that are never displayed to anyone, and an audit log that records every change with who made it. Recording prompts and responses only when an organization chooses to also shrinks what a console compromise can read; a prompt logging policy helps make that choice.

The part only the customer controls

All three breaches end the same way for an exposed key: it can be used directly against the provider. The gateway's budgets, allowlists and rate limits never see that traffic. What does apply:

• Scope. A key in its own OpenAI project, or its own Anthropic workspace — where keys are tied to the workspace they were created in⁸ — can reach only what that project or workspace can.
• Spend limits at the provider. OpenAI's project hard limit fails requests with a 429 once reached, with the caveat that recorded spend can slightly exceed it while the limit updates⁹. An Anthropic workspace can carry its own limit below the organization's⁸. Provider spend limits compared goes provider by provider.
• Revocation. Only the account owner can revoke a key at the provider. Replacing the key inside the gateway does not.
• Usage monitoring at the provider. Traffic that did not go through the gateway shows up only in the provider's own usage data. Detecting gateway bypass from provider usage explains how to compare the two.

What to do before a breach

1. Connect dedicated keys. One key per platform and environment, never the key your own services use.
2. Scope each one at the provider to a project, workspace or cloud project that serves only that platform's traffic.
3. Set a provider spend limit on each and an alert below it.
4. Record who holds what: platform, key, project, owner, creation date, rotation date. An AI credential inventory gives a format.
5. Ask the platform the storage questions in Is it safe to give your API key to a third-party AI tool?, including its breach-notification commitment.
6. Rehearse rotation once, end to end: new key at the provider, replace in the platform, revoke the old key, confirm it fails.

What to do after a breach is reported

1. Rotate at the provider first. Create replacements, update the platform and anything else that uses them, revoke the old keys, and confirm they return authentication errors.
2. Bound the usage review by the earliest possible exposure time the vendor gives, and review provider usage and billing from then: models you do not use, volume at hours you do not work, requests from regions you do not serve. Signs your AI API key is being abused lists the patterns.
3. Separate gateway traffic from direct traffic. Compare the gateway's request history with the provider's usage by key; the difference is what an attacker sent directly.
4. Read the platform's audit log for configuration changes during the window: new members, new keys, changed routes, raised limits.
5. Contact your provider about unexpected charges; AI API key theft and your bill covers what to prepare.
6. Write it down. An AI credential incident postmortem template keeps the record useful.

How INFRO limits its own blast radius

INFRO is a BYOK platform: customers connect their own provider keys, and INFRO uses them to route requests. These are the controls that apply to each breach today, as documented in Connect a provider, Authentication, Security and the audit log:

• Storage. Provider credentials are encrypted with AES-256-GCM under a key held as a Worker secret, not in the database, with the organization and connection bound in as additional authenticated data. No endpoint, console screen or export returns a stored credential; the console shows the last four characters. A copy of the database alone opens nothing. An attacker with both the database and that key could open the credentials sealed under it, which is why the provider-side controls above still matter.
• Applications never hold provider keys. They use INFRO gateway keys, stored only as a SHA-256 digest, each belonging to one environment, optionally limited to chosen providers or IP ranges, and revocable or rotatable with an overlap window.
• Configuration. Two-factor authentication, passkeys and an organization-wide 2FA requirement; SAML or OIDC SSO with SCIM on the Business plan; roles and project access; every change recorded in the audit log. Prompt and response logging is off by default.
• Bypass visibility. With reconciliation on the Business plan and usage access granted, INFRO compares OpenAI's and Anthropic's own usage data by provider key with the traffic it served, and reports usage on a connected key that did not go through INFRO; without that access it reports "not checked".
• Notification. INFRO's data processing agreement commits to notifying a breach without undue delay and within 48 hours of becoming aware.

None of this makes INFRO immune. A request-path compromise of INFRO would expose keys in use, as it would for any gateway, and INFRO's budgets and allowlists do not apply to a stolen key used directly at the provider. Connect it with keys you have scoped and limited at the provider.

Summary

A breach of a BYOK platform is three possible breaches. Copied storage is limited by where the encryption key lives and whether each credential is bound to its row; a compromised request path is limited by release discipline, not encryption; tampered configuration is limited by sign-in, roles and an audit log. Every exposed key ends up usable at the provider, so the customer's own scope, spend limits, revocation and usage monitoring decide the final cost.