AI API 密钥安全
让你的提供商密钥远离你的应用。改为给每个应用、智能体和工具分配一个 INFRO 网关密钥，带有开关、IP 允许列表、模型限制和支出限额，每一项都在调用你的提供商之前检查。
4 项检查
每次请求时，在调用你的提供商之前。
32 个网络
按密钥设置在其 IP 允许列表中，支持 IPv4 或 IPv6，所有套餐均可用。
无需部署
用于关闭泄露的密钥。使用它的每个请求都会被拒绝。
AES-256-GCM
适用于你连接的每个提供商密钥。密钥不会再次显示。
提供商密钥存放在哪里
同一个提供商密钥通常存放在五个地方，任何一份副本都能动用整个账号的额度。使用 INFRO 后，提供商密钥被密封在一个地方，每个应用、智能体和工具都持有自己的网关密钥。选择泄露发生的位置。
sk-proj-••••7Hc2已复制到 5 个位置sk-proj-••••7Hc2在此泄露sk-proj-••••7Hc2同一密钥sk-proj-••••7Hc2同一密钥sk-proj-••••7Hc2同一密钥sk-proj-••••7Hc2同一密钥sk-proj-••••7Hc2密封保存在 INFRO 中sk_infro_••••a91f每天 $50203.0.113.0/24已泄露，已控制sk_infro_••••3c7e每天 $10203.0.113.64/27不受影响sk_infro_••••5d20每天 $530 天后过期不受影响sk_infro_••••8b14每天 $20仅限 Anthropic不受影响sk_infro_••••e602每月 $151 个模型不受影响四项检查
每项检查都以各自有文档说明的代码拒绝请求，因此你的日志会准确说明原因，而且每一项都可以在控制台或通过 API 调整，无需部署。四项检查在每个套餐中都提供。
这个密钥是开启的吗？
在控制台或通过 API 关闭一个密钥后，使用它的每个请求都会被拒绝。它的密钥内容、限额和历史都会保留；重新开启即可恢复同一个密钥。
403 key_disabled文档
它是从你的服务器发起调用的吗？
每个密钥最多 32 个 IPv4 或 IPv6 地址或 CIDR 范围，与 Cloudflare 边缘报告的客户端地址进行匹配，绝不使用 X-Forwarded-For。没有可信地址时，请求会被拒绝。
403 ip_not_allowed文档
它被允许使用这个模型吗？
批准组织、项目或密钥可调用的模型，以及密钥可触达的提供商。每个密钥属于一个环境，永远不会触达该环境之外的连接。
403 model_not_allowed文档
它的限额能覆盖这个请求吗？
按密钥设置每日、每周、每月或终身限额，与组织、项目和成员的预算并存。限额无法覆盖的请求会在调用提供商之前被拒绝。
402 key_budget文档
支出上限
泄露的密钥、陷入循环的智能体、用脚本刷你免费额度的客户：每一种都会停在与其规模相当的上限处，而不会耗尽你的整个预算。每个适用的上限都会在调用你的提供商之前检查，并把在途请求的最坏情况计算在内。
上限可叠加
一条请求必须符合适用于它的每一个上限。最严格的那个起决定作用，所以在合适的位置设置一个小上限，能在问题触及组织上限之前很久就将其拦住。
该密钥当天在 $50 时停止。其他所有密钥继续服务。
| 上限 | 周期 | 行为方式 | 拒绝代码 | 套餐 |
|---|---|---|---|---|
| 组织 | 每月目标和硬上限 | 目标会告警；硬上限会告警或阻断。仅所有者可以设置。 | 402 organization_budget | 所有套餐 |
| 项目 | 按月 | 告警或阻断，告警阈值由你自己设定。 | 402 project_budget | 所有套餐 |
| 成员 | 按月 | 告警或阻断，针对某个人的活动。 | 402 member_budget | 所有套餐 |
| 网关密钥 | 每日、每周、每月或终身 | 始终阻断。终身限额永不重置。 | 402 key_budget | 所有套餐 |
| 终端客户 | 每日、每周或每月 | 对每位客户适用同一条规则，按组织或项目设置，并可由你的后端设置覆盖值。 | 402 end_user_budget | Team 及以上 |
密钥泄露
适用于 INFRO 网关密钥。如果泄露的是提供商密钥，请先在提供商处删除它：只有这样才能阻止它。
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.同样的三项更改也在控制台中该密钥的页面上。使用管理 API 时，更改需要附上你最后读取的版本（If-Match），因此两个人同时处理同一事件时不会互相覆盖。
提示词中的密钥
人们会把 .env 文件粘贴进聊天，智能体也会从 shell 中读出它们。在 Business 套餐中，护栏会检查提示词、工具调用和响应中的密钥格式，然后在调用你的提供商之前拦截请求、用 [SECRET] 替换匹配内容或进行标记。
检测基于模式：它只匹配这些格式，因此会漏掉 AWS 秘密访问密钥、密码以及它不认识的格式。每次匹配都会计入请求记录。 护栏文档
智能体、工具和人
Claude Code、Codex 和各种智能体 SDK 使用网关密钥调用 INFRO 的 /v1/messages 和 /v1/responses，而不是你的 Anthropic 或 OpenAI 密钥。为每位开发者或每个智能体各分配一个，带有支出限额、过期时间和网络允许列表；吊销它不会影响其他任何人。
每个 MCP 服务器只需连同其令牌注册一次。INFRO 在每次调用时附上令牌，因此任何智能体、提示词或配置文件都不持有它，每个网关密钥也只能使用授予它的工具。
支持身份验证器应用、通行密钥和硬件密钥的双因素认证，一份可以结束的会话列表，以及一项要求每位成员都启用双因素认证的组织设置。 Business 套餐起提供 SAML 或 OIDC 单点登录以及 SCIM。
我们持有的密钥
存储提供商密钥的平台正是十月那些攻击的目标，所以同样的问题也适用于我们。这些控制措施逐字引自 Trust Center 自己的陈述。
INFRO 做不到的事
从 INFRO 或其他任何地方窃取的提供商密钥，都可以直接用于调用提供商，绕过所有 INFRO 限制。请连接限定在各自项目或工作区内的密钥，并在提供商处设置支出限额：即使我们失守，这项控制依然有效。尚未到位的措施列在 Trust Center 上。
2026 年 10 月
两起事件中的建议都一样：替换密钥，在提供商处删除旧密钥，并查看它做了什么。提供商密钥存放的地方越少，一次泄露需要的轮换就越少；你确实分发出去的密钥，应带有无需部署即可调整的限制。
Railway 的说法
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.
该怎么做
轮换 Railway 持有的每一个变量，AI 提供商密钥优先：替换，在提供商处删除旧密钥，部署，并查看旧密钥的用量。
Railway breach: what happened and what to do复查于 2026年10月22日
OpenCode 的说法
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.
该怎么做
创建一个限定范围的替换密钥，在提供商处吊销旧密钥，并查看自 10 月 16 日起的提供商用量。
OpenCode Console breach: what happened and what to do复查于 2026年10月21日
每段摘要都来自该公司自己的披露，按我们的分析中的引用呈现。撰写时两起事件仍在进行中；这些分析每周复查，所有变更都记录在修订说明中。
实战指南
常见问题
在提供商处创建替换密钥，在那里删除泄露的密钥，部署替换密钥，然后在提供商处查看旧密钥在其可能被使用的整个期间的用量。让密钥失效的是在提供商处删除它；应用或网关做不到把被盗的密钥召回。然后在提供商处为替换密钥设置支出限额，并让它远离代码、客户端应用和共享环境。
你的应用持有 INFRO 网关密钥，而不是你的提供商密钥。每个网关密钥都可以关闭（403 key_disabled）、限制在最多 32 个网络内（403 ip_not_allowed）、收窄到已批准的模型和提供商，并设置每日、每周、每月或终身的支出限额（402 key_budget）。每项检查都在调用你的提供商之前、在每个套餐上执行，且无需部署。泄露的网关密钥是一个可以关闭的有限问题；泄露的提供商密钥则会触及整个提供商账号。
可以。预算适用于组织（有会告警的每月目标，以及会告警或阻断的硬上限）、项目和成员（每月），以及网关密钥（每日、每周、每月，或永不重置的终身限额）。 从 Team 套餐起，终端客户上限可按日、周或月限制你的每一位客户，并可为特定客户设置覆盖值。 在调用你的提供商之前，会检查每一个适用的上限，并按最坏情况计入仍在处理中的请求，被拒绝的请求会返回指明该上限的 402。上限计算的是 INFRO 对提供商费用的估算，而不是你的提供商的发票，因此请同时在提供商处保留一个支出限额。
会：你只需连接一次自己的提供商密钥，INFRO 用它们来处理你的请求。每个密钥都用 AES-256-GCM 加密，加密密钥作为 Worker 密钥存放在数据库之外，并绑定了组织和连接，因此仅有数据库副本无法打开任何内容。没有任何控制台页面、端点或导出会返回已保存的凭据；控制台只显示它的最后四个字符。网关密钥仅以 SHA-256 摘要存储。
可以。INFRO 只治理经过它的流量。从任何地方取得的提供商密钥，包括从 INFRO 取得的，都可以绕过所有 INFRO 限额直接对提供商使用。请连接限定在各自项目或工作区、并在提供商处设置了支出限额的密钥：即使我们出问题，该限额依然有效。 在 Business 套餐中，开启用量访问的对账，会报告某个已连接密钥上没有经过 INFRO 的用量。
OpenCode 于 2026 年 10 月 17 日表示，一起与大规模蒸馏攻击有关的泄露事件影响了 1.4% 的 Console 用户，即关联了外部 AI 提供商的用户，工作区中保存的提供商密钥可能已被暴露。Railway 于 2026 年 10 月 21 日表示，未经授权的一方可能访问了加密的客户环境变量并解密了其中一部分，这些攻击旨在入侵 AI 推理提供商。两起事件的建议相同：替换密钥，在提供商处删除旧密钥，并查看其用量。INFRO 对两起事件各有一篇分析，仅依据这些公司自己的声明撰写。
在 Business 套餐中，护栏会检查提示词和响应中的 OpenAI、Anthropic、Google API 密钥、AWS 访问密钥 id、GitHub 令牌、Slack 令牌、Stripe 生产密钥和INFRO 密钥 格式、JWT 和 PEM 私钥，并在你的提供商看到之前阻断请求、将匹配内容替换为 [SECRET] 或加以标记。检测基于模式：它会漏掉不认识的格式，例如 AWS 的秘密访问密钥和密码。
不需要经过 INFRO。它们用网关密钥调用 INFRO 的 /v1/messages 和 /v1/responses，因此每位开发者或每个智能体都可以拥有自己的密钥，带支出限额、有效期和可选的网络允许列表，吊销它不会影响其他任何人的访问。智能体仍然可以读取同一个 shell 中留下的任何密钥，因此请从开发者环境中移除原始的提供商密钥。
LLMjacking 是指盗用云或 AI API 凭据，以受害者为代价调用托管的语言模型，用于攻击者自己使用或转卖访问权限。防御办法与任何能花钱的凭据相同：让提供商密钥远离代码和客户端应用，为每个密钥设置支出限额，按密钥监控用量，并能在无需部署的情况下关闭一个密钥。
每个套餐都包含关闭密钥、允许的网络、模型和提供商限制、支出限制、轮换和过期、双因素登录和通行密钥和审计日志。 支出告警在每个套餐中都会发送到邮件，从 Startup 套餐起还会发送到 Slack 和带签名的 webhook。 护栏、SSO 和 SCIM、带绕过检测的成本对账和MCP 网关均包含在 Business 套餐中。
合规情况、完整的控制措施列表以及尚未到位的措施都在 Trust Center 上。发现了漏洞？请写信至 security@infro.io。