AI API key security
Keep your provider keys out of your applications. Give every app, agent and tool an INFRO gateway key instead, with an off switch, an IP allowlist, model limits and a spend limit, each checked before your provider is called.
Example: one gateway key, after it leaked.
4 checks
On every request, before your provider is called.
32 networks
Per key in its IP allowlist, IPv4 or IPv6, on every plan.
No deploy
To switch a leaked key off. Every request with it is refused.
AES-256-GCM
On every provider key you connect. It is never shown again.
Where provider keys live
The same provider key usually sits in five places, and any copy can spend from the whole account. With INFRO the provider key is sealed in one place and each app, agent and tool holds its own gateway key. Pick where the leak happens.
sk-proj-••••7Hc2Copied to 5 placessk-proj-••••7Hc2Leaked heresk-proj-••••7Hc2Same keysk-proj-••••7Hc2Same keysk-proj-••••7Hc2Same keysk-proj-••••7Hc2Same keysk-proj-••••7Hc2Sealed in INFROsk_infro_••••a91f$50 a day203.0.113.0/24Leaked, containedsk_infro_••••3c7e$10 a day203.0.113.64/27Unaffectedsk_infro_••••5d20$5 a dayExpires in 30 daysUnaffectedsk_infro_••••8b14$20 a dayAnthropic onlyUnaffectedsk_infro_••••e602$15 a month1 modelUnaffectedFour checks
Each check refuses with its own documented code, so your logs say exactly why, and each one moves from the console or the API without a deploy. All four are on every plan.
Is this key on?
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.
403 key_disabledDocs
Is it calling from your servers?
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.
403 ip_not_allowedDocs
Is it allowed this model?
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.
403 model_not_allowedDocs
Can its limit cover this request?
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.
402 key_budgetDocs
Spend caps
A leaked key, an agent stuck in a loop, one customer scripting your free tier: each stops at a cap its own size instead of reaching your whole budget. Every applicable cap is checked before your provider is called, counting the worst case of requests already in flight.
Caps stack
A request must fit every cap that applies to it. The tightest one decides, so a small cap in the right place stops a problem long before the organization’s.
The key stops at $50 for the day. Every other key keeps serving.
| Cap | Period | How it behaves | Refused with | Plan |
|---|---|---|---|---|
| Organization | Monthly target and hard cap | The target alerts; the hard cap alerts or blocks. Only the owner sets it. | 402 organization_budget | Every plan |
| Project | Monthly | Alert or block, with alerts at your own thresholds. | 402 project_budget | Every plan |
| Member | Monthly | Alert or block, for one person's activity. | 402 member_budget | Every plan |
| Gateway key | Daily, weekly, monthly or lifetime | Always blocks. A lifetime limit never resets. | 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. | 402 end_user_budget | Team and up |
Tested under loadIn a sandbox test, a $1 blocking cap held in 12 of 12 runs at up to 500 concurrent requests (the test and its method). Caps count INFRO’s estimate of provider cost, not your provider’s invoice, and a model with no known price is refused under a blocking cap unless you allow it, so keep a spending limit at the provider too. Spend controls docs
A key leaked
For an INFRO gateway key. If a provider key leaked, delete it at the provider first: that is the only thing that stops it.
curl -X PATCH https://api.infro.io/manage/v1/gateway_keys/$KEY_ID \
-H "Authorization: Bearer $INFRO_MANAGEMENT_TOKEN" \
-H 'If-Match: "7"' \
-H "Content-Type: application/json" \
-d '{"disabled": true}'
# Every request with the key: 403 key_disabled
# Its secret, limits and history are kept.The same three changes are on the key’s page in the console. With the management API, a change needs the version you last read (If-Match), so two people containing one incident cannot overwrite each other.
Secrets in prompts
People paste .env files into chats and agents read them out of shells. On the Business plan, guardrails check prompts, tool calls and responses for secret formats, then block the request, replace the match with [SECRET] or flag it, before your provider is called.
Detection is pattern-based: it matches these formats and nothing else, so it misses AWS secret access keys, passwords and formats it does not know. Every match is counted on the request record. Guardrails docs
Agents, tools and people
Claude Code, Codex and the agent SDKs call INFRO's /v1/messages and /v1/responses with a gateway key instead of your Anthropic or OpenAI key. Give each developer or agent one, with a spend limit, an expiry and a network allowlist; revoking it touches nobody else.
Register each MCP server once with its token. INFRO adds it on every call, so no agent, prompt or config file holds it, and each gateway key gets only the tools it was granted.
Two-factor with an authenticator app, passkeys and hardware keys, a list of sessions you can end, and an organization setting that requires two-factor for every member. SAML or OIDC single sign-on and SCIM from the Business plan.
The keys we hold
A platform that stores provider keys is exactly what the October attacks went after, so the same questions apply to us. These controls are the Trust Center's own statements, word for word.
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: it is the control that holds even if we fail. What is not in place yet is listed on the Trust Center.
October 2026
In both, the advice was the same: replace the key, delete the old one at the provider, and read what it did. The fewer places a provider key lives, the fewer rotations a breach costs; the keys you do hand out should carry limits you can move without a deploy.
What Railway said
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.
Railway breach: what happened and what to doReviewed October 22, 2026
What OpenCode said
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.
OpenCode Console breach: what happened and what to doReviewed October 21, 2026
Each summary is from the company’s own disclosure, as our analysis quotes it. Both incidents were open when written; the analyses are reviewed weekly and carry every change in their revision notes.
Field guides
FAQ
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Compliance, the full control list and what is not in place yet are on the Trust Center. Found a vulnerability? Write to security@infro.io.
Get started
Your providers, your contracts, your keys, sealed in one place. Every key you hand out, limited and switchable. 0% markup on model spend.