# AI API key security with INFRO

> INFRO keeps AI provider keys out of your applications. Applications hold INFRO gateway keys instead, and every gateway key carries an off switch, a network allowlist, model and provider limits and a spend limit, each checked before your provider is called.

Page: https://infro.io/security · Facts checked against the product on 2026-10-23.

## Where provider keys live

Without a gateway, the same provider key is copied into production environment variables; ci and deploy secrets; developer laptops and .env files; coding agents' shells; third-party ai tools. Every copy reaches the whole provider account, and recovering from a leak means deleting the key at the provider and redeploying every copy.

With INFRO, the provider key is connected once, encrypted, and never shown again. Each place holds its own gateway key instead, so a leak exposes one key within its limits:

- Production environment variables: `checkout-api` ($50 a day, 203.0.113.0/24). If it leaks: one key, refused outside your servers' network and capped at $50 a day inside it.
- CI and deploy secrets: `ci-deploy` ($10 a day, 203.0.113.64/27). If it leaks: one key, refused outside your CI runners' range and capped at $10 a day.
- Developer laptops and .env files: `maya-laptop` ($5 a day, Expires in 30 days). If it leaks: one key, capped at $5 a day, that stops working on its own when it expires.
- Coding agents' shells: `claude-code` ($20 a day, Anthropic only). If it leaks: one key, capped at $20 a day and limited to your Anthropic connection.
- Third-party AI tools: `support-tool` ($15 a month, 1 model). If it leaks: one key, capped at $15 a month and allowed one model.

## Four checks before your provider is called

- **Off switch** (Is this key on?) — `403 key_disabled`. Turn a key off from the console or the API and every request with it is refused. Its secret, limits and history are kept; turning it on again restores the same key. Docs: https://infro.io/docs/authentication
- **Allowed networks** (Is it calling from your servers?) — `403 ip_not_allowed`. Up to 32 IPv4 or IPv6 addresses or CIDR ranges per key, matched against the client address Cloudflare's edge reports, never X-Forwarded-For. With no trusted address, the request is refused. Docs: https://infro.io/docs/authentication#ip-allowlist
- **Models and providers** (Is it allowed this model?) — `403 model_not_allowed`. Approve the models an organization, project or key may call, and the providers a key may reach. Each key belongs to one environment and never reaches a connection outside it. Docs: https://infro.io/docs/org/model-allowlists
- **Spend limit** (Can its limit cover this request?) — `402 key_budget`. A daily, weekly, monthly or lifetime limit per key, beside budgets per organization, project and member. A request the limit cannot cover is refused before the provider is called. Docs: https://infro.io/docs/org/spend-controls

- **Rotation with an overlap.** Rotate in one step: the new key takes every setting of the old one, and the old key keeps working for up to seven days while you deploy, or stops at once. The spend limit is shared, so rotating never buys fresh room.
- **Expiry.** Give a key a time after which it stops working, for a contractor, a demo or a migration.
- **Shown once, stored as a hash.** A gateway key is 32 random bytes, shown once and stored only as a SHA-256 digest. A database disclosure does not disclose a usable key.
- **Guessing is throttled.** An address that fails authentication 30 times in a minute is refused with a 429 until the minute passes, before any key is looked up.

## Spend caps at every level

A leaked key, an agent stuck in a loop or one customer scripting a free tier becomes a bounded number. Every applicable cap is checked before the provider is called, counting the worst case of requests already in flight.

- **Organization** (monthly target and hard cap): The target alerts; the hard cap alerts or blocks. Only the owner sets it. Refused with `402 organization_budget`. Every plan.
- **Project** (monthly): Alert or block, with alerts at your own thresholds. Refused with `402 project_budget`. Every plan.
- **Member** (monthly): Alert or block, for one person's activity. Refused with `402 member_budget`. Every plan.
- **Gateway key** (daily, weekly, monthly or lifetime): Always blocks. A lifetime limit never resets. Refused with `402 key_budget`. Every plan.
- **End customer** (daily, weekly or monthly): One rule for every customer, per organization or project, with overrides your backend sets. Refused with `402 end_user_budget`. Team and up.

- *A gateway key leaks:* The key stops at $50 for the day. Every other key keeps serving. (`402 key_budget`, resets at 00:00 utc)
- *An agent loops overnight:* It stops at $500 in total, however long it runs. (`402 key_lifetime_limit`, never resets)
- *One customer scripts your free tier:* That customer gets a 402 with the reset time. Every other customer is served. (`402 end_user_budget`, resets at 00:00 utc)
- *A release sends far more tokens:* That project stops at its budget. Other projects keep running. (`402 project_budget`, resets on your budget cycle day)
- *Spend climbs everywhere:* Alerts at 50% and 80% reach you first. The hard cap stops the rest. (`402 organization_budget`, resets on your budget cycle day)

In a sandbox test (https://infro.io/blog/ai-spend-cap-concurrency-test), a $1 blocking cap held in 12 of 12 runs at up to 500 concurrent requests. Caps count INFRO's estimate of provider cost, not the provider's invoice. Docs: https://infro.io/docs/org/spend-controls

## Leaked key: the first hour

1. **Contain it without a deploy.** Turn the gateway key off, or keep your application running by narrowing the key to your servers' networks and lowering its spend limit. None of it needs a deploy, and every check runs before any provider call.
2. **Replace it.** Rotate with no overlap when the key has leaked. The replacement keeps the label, project, limits, allowlists, environment and history access, and is shown once.
3. **Read what it did.** Every request record names the gateway key that made it, with its model, status and estimated provider cost; filter the request log and usage by that key. The console shows how many requests each key's allowlist refused today.
4. **Check for use outside INFRO.** On the Business plan, cost reconciliation with usage access switched on reports usage on a connected provider key that never went through INFRO. Without that access it says "not checked", never "no bypass": read the provider's own usage page.
5. **Keep the record.** Key changes, rotations and policy edits are in the audit log with who made them and when, in rows the database refuses to update or delete.

If a provider key leaked rather than a gateway key, delete it at the provider first: field guides for OpenAI and Anthropic keys are linked below.

## Secrets in prompts and responses

On the Business plan, guardrails match OpenAI, Anthropic, Google API key, AWS access key id, GitHub token, Slack token, Stripe live key, INFRO key, JWT and PEM private key formats in prompts and responses and block, redact (`[SECRET]`) or flag them. Detection is pattern-based and misses formats it does not know, such as AWS secret access keys and passwords. Docs: https://infro.io/docs/features/guardrails

## How INFRO protects the keys it holds

- **Provider credentials are sealed, and bound to one tenant.** The provider keys you connect are encrypted with AES-256-GCM under a key held as a Worker secret, never in the database. The organization and connection identifiers are bound in as additional authenticated data, so a sealed credential copied into another tenant's row — or another row of the same tenant — fails closed rather than decrypting. Credentials connected for cost reconciliation are sealed separately, under their own binding.
- **There is no reveal, anywhere.** Once a provider credential is saved, no interface returns it — not the console, not the API, not the internal operator console. What either side can see is the last four characters and the timestamps. If you lose the key, you rotate it at the provider; we cannot show it to you.
- **INFRO API keys are hashed at rest.** A gateway key is 32 bytes from a cryptographic random source. What we store is its SHA-256 digest, a display prefix and the last four characters, so a database disclosure does not disclose a usable credential. Revocation writes a tombstone rather than deleting the row, so it cannot be shadowed by a stale cache entry still propagating between locations.
- **The encryption key can be rotated without your involvement.** Rotating the key that seals customer credentials re-seals every stored credential in place. It does not ask customers to re-enter anything, and the stored algorithm carries a version string so a future scheme can coexist with the current one rather than needing a flag day.

What INFRO cannot do: a provider key taken from INFRO, or from anywhere else, can be used directly against the provider, outside every INFRO limit. Connect keys scoped to their own project or workspace, with a spending limit set at the provider. Controls, compliance status and known gaps: https://infro.io/trust

## October 2026 incidents

- **Railway, disclosed 2026-10-21.** An unauthorized party may have accessed encrypted customer environment variables and, for some of them, obtained the decrypted contents, in a series of attacks aimed at compromising AI inference providers. What to do: Roll every variable Railway held, AI provider keys first: replace, delete the old key at the provider, deploy, and review the old key's usage. Analysis: https://infro.io/blog/railway-breach-what-happened
- **OpenCode, disclosed 2026-10-17.** A breach related to a large-scale distillation attack affected 1.4% of OpenCode Console users, those with external AI providers linked, and provider keys saved in a workspace may have been exposed. What to do: Create a scoped replacement, revoke the old key at the provider, and review provider usage from 16 October onward. Analysis: https://infro.io/blog/opencode-console-breach-what-happened

## Questions

### What should I do if my OpenAI or Anthropic API key leaked?

Create a replacement key at the provider, delete the leaked key there, deploy the replacement, then review the old key's usage at the provider for the whole time it could have been used. Deleting the key at the provider is what stops it; nothing an application or a gateway does can call a stolen key back. Then give the replacement a spending limit at the provider and keep it out of code, client apps and shared environments.

### How does INFRO limit the damage from a leaked API key?

Your applications hold INFRO gateway keys instead of your provider keys. Each gateway key can be turned off (403 key_disabled), limited to up to 32 networks (403 ip_not_allowed), narrowed to approved models and providers, and given a daily, weekly, monthly or lifetime spend limit (402 key_budget). Every check runs before your provider is called, on every plan, and none needs a deploy. A leaked gateway key is a bounded problem you can switch off; a leaked provider key reaches the whole provider account.

### Can I cap AI spend per customer, per project or per time period?

Yes. Budgets apply per organization (a monthly target that alerts and a hard cap that alerts or blocks), per project and per member (monthly), and per gateway key (daily, weekly, monthly, or a lifetime limit that never resets). From the Team plan, end-customer caps limit each of your own customers daily, weekly or monthly, with overrides for specific customers. Every applicable cap is checked before your provider is called, counting the worst case of requests already in flight, and a refused request is a 402 that names the cap. Caps count INFRO's estimate of provider cost, not your provider's invoice, so keep a spending limit at the provider as well.

### Does INFRO store my provider API keys, and how are they protected?

Yes: you connect your own provider keys once and INFRO uses them to serve your requests. Each is encrypted with AES-256-GCM under a key held as a Worker secret outside the database, with the organization and connection bound in, so a copy of the database alone opens nothing. No console screen, endpoint or export returns a saved credential; the console shows its last four characters. Gateway keys are stored only as a SHA-256 digest.

### Can a stolen provider key bypass INFRO?

Yes. INFRO governs only the traffic that goes through it. A provider key taken from anywhere, including from INFRO, can be used directly against the provider, outside every INFRO limit. Connect keys scoped to their own project or workspace with a spending limit set at the provider: that limit holds even if we fail. On the Business plan, reconciliation with usage access switched on reports usage on a connected key that did not go through INFRO.

### What happened in the OpenCode and Railway breaches?

OpenCode said on 17 October 2026 that a breach related to a large-scale distillation attack affected 1.4% of its Console users, those with external AI providers linked, and that provider keys saved in a workspace may have been exposed. Railway said on 21 October 2026 that an unauthorized party may have accessed encrypted customer environment variables and decrypted some of them, in attacks aimed at compromising AI inference providers. In both cases the advice is the same: replace the key, delete the old one at the provider, and review its usage. INFRO has an analysis of each, written only from the companies' own statements.

### Can INFRO stop API keys from being pasted into prompts?

On the Business plan, guardrails check prompts and responses for OpenAI, Anthropic, Google API key, AWS access key id, GitHub token, Slack token, Stripe live key and INFRO key formats, JWTs and PEM private keys, and block the request, replace the match with [SECRET] or flag it before your provider sees it. Detection is pattern-based: it misses formats it does not know, such as AWS secret access keys and passwords.

### Do Claude Code and Codex need my Anthropic or OpenAI key?

Not through INFRO. They call INFRO's /v1/messages and /v1/responses with a gateway key, so each developer or agent can have its own key with a spend limit, an expiry and an optional network allowlist, and revoking it touches nobody else's access. An agent can still read any key left in the same shell, so remove raw provider keys from developer environments.

### What is LLMjacking?

LLMjacking is the use of stolen cloud or AI API credentials to call hosted language models at the victim's expense, either for the attacker's own use or to sell the access on. The defence is the one for any credential that can spend money: keep provider keys out of code and client apps, give every key a spend limit, watch usage per key, and be able to switch a key off without a deploy.

### Which INFRO plans include these controls?

Every plan includes turning a key off, allowed networks, model and provider limits, spend limits, rotation and expiry, two-factor sign-in and passkeys and the audit log. Spend alerts go to email on every plan, and to Slack and signed webhooks from the Startup plan. Guardrails, SSO and SCIM, cost reconciliation with bypass detection and the MCP gateway are on the Business plan.

## Field guides

- https://infro.io/blog/leaked-openai-api-key
- https://infro.io/blog/leaked-anthropic-api-key
- https://infro.io/blog/google-api-keys-gemini-exposure
- https://infro.io/blog/signs-ai-api-key-abused
- https://infro.io/blog/cap-stolen-ai-key-damage
- https://infro.io/blog/what-is-llmjacking
- https://infro.io/blog/ai-api-keys-github-secret-scanning
- https://infro.io/blog/byok-platform-breach-blast-radius
- https://infro.io/blog/ai-api-key-security-checklist