如何防止 AI API 凭据成本失控

AI API 密钥不只是一个登录字符串。它是通向按量计费计算能力的通道，而复制的密钥即使在攻击者离开其暴露的应用后，仍可继续授权请求。因此，成本控制应当属于每个 AI 系统的安全设计，包括临时研究工具和内部原型。

METR 在 2026 年的披露为这种风险给出了具体形态。一个可通过互联网访问的代理仪表板存在故障开放式身份验证缺陷，这意味着访问控制失效时应用仍然可用。METR 报告称，攻击者进入该仪表板，诱导代理泄露模型提供商凭据，添加 SSH 密钥以获得持久主机访问，并在三周内使用被盗凭据。消耗的额度估值约为 60 万美元，不过 METR 没有支付该金额，因为提供商免费提供了这些额度。

有用的教训不在于头条中的数额，也不在于某个应用的开发方式。数项彼此独立的控制措施都未能阻止同一条路径。持久的预防计划假定接口、主机或密钥最终可能遭到入侵，并限制之后可能发生的事情。

在部署代理前界定爆炸半径

应按不受信任的用户能够通过 AI 应用触及什么来对其分类，而不是看团队是否称它为原型。当一项实验接收互联网流量、能够调用付费或稀缺模型、能够访问非公开数据，或能够调用对自身进程以外产生影响的工具时，它就具有运营意义。生命周期短并不会减少这些能力。

在对外暴露前创建一份简要部署记录。列出负责人、公共端点、云账户、模型、凭据、数据存储、工具权限、预期使用范围、到期日期和关闭流程。这份清单能让被遗忘的实验可被发现，也能为事件响应人员提供可靠地图。公共服务应在架构上与内部系统隔离的环境中运行，这样查看器或仪表板中的缺陷便不会形成通向敏感基础设施的路径。

METR 的披露还描述了公共转录查看器中的第二个缺陷：只读 SQL 机制可被操纵以暴露未发布的评估数据，而且一些敏感输出已进入原本预计只包含公开模型结果的数据库。METR 表示，现有证据并不表明攻击者发现了该漏洞利用方式或访问了非公开信息。这一事件仍显示，预期的数据分类并不足够。隔离必须涵盖记录存储位置、查询范围的限定方式，以及受限材料是否能够被放入面向公众的数据存储。

设定一条易于执行的规则：互联网暴露或访问在用凭据会自动触发基础安全审查。该审查可以较轻量，但应确认默认拒绝式身份验证、托管服务、明确负责人、日志记录、凭据边界和结束日期。

将原始机密置于代理触及范围之外

应用可能需要调用模型的权限，但模型不需要读取可重复使用的凭据。应将机密置于提示词、转录内容、环境检查工具、代理可打开的文件以及代理可返回的命令输出之外。诸如“绝不泄露此密钥”的指令并不是安全边界，因为语言模型会处理不受信任的指令，并可能被操纵而泄露可访问的信息。

在代理与提供商之间放置代理服务或边界严格定义的服务。代理请求获准操作；中介持有凭据、验证请求、应用策略、记录用量，并只返回必要结果。将中介限制为获准的模型和操作。在提供商功能允许时，为每个应用和环境签发独立凭据，缩小权限范围，并采用较短有效期。

分离身份会让遏制和调查都更容易。如果一个密钥服务多个实验，高使用量有许多合理解释，而撤销会干扰无关工作。专用于一个工作负载的密钥具有更小的行为范围、明确负责人和实用的终止开关。短期凭据也会缩短复制值仍有用的时间；范围狭窄的权限则限制攻击者在该期间能够做什么。

主机访问需要自己的边界。METR 攻击者进入暴露系统后添加了 SSH 密钥，因此仅轮换提供商凭据无法移除持久访问。监控远程访问配置的变更，限制谁可添加密钥，并将新的持久访问方式视为事件，即使 API 消耗看起来仍属正常。

将预算变为强制执行的安全限制

支出警报很有用，但警报只是要求某人开展调查。应优先采用硬性的提供商或中介限制，在批准预算耗尽后拒绝进一步使用。在可用时，于多个层级应用限制：组织、项目、应用凭据和时间窗口。单独的月度账户上限仍可能允许在周期初期发生破坏性突发使用。

某些提供商或账户安排可能不提供直接的支出上限。METR 表示当时无法在受影响密钥上设置上限，且捐赠额度消除了原本可能引起注意的不断上升的账单。在这种情况下，应在调用层重建该边界。凭据中介可以计数请求或令牌、执行每日和单次运行限额、限制并发，并在越过阈值时暂停访问。即使当前现金账单为零，获赠或预付的容量也应被视为具有重置价值的资产。

根据凭据声明的用途选择阈值。计划中的评估、交互式仪表板和批处理作业不应共享相同限制。定义单次运行的预期最大值、滚动小时或每日上限，以及失败或被拒绝请求的最大速率。记录谁可批准临时增加以及该例外何时到期。否则，紧急覆盖会悄然成为正常运行边界。

执行必须故障关闭。若身份验证服务、策略检查、用量计数器或批准查询不可用，系统应拒绝或严格限制受保护的操作。降级的监控服务不应悄然将受限凭据变成无限制凭据。

检测账单无法显示的行为

在研究或评估工作中，高令牌量并不必然可疑。METR 解释说，合法实验也可能产生大量用量、限速响应和提供商错误。事件期间，其内部仪表板也没有显示每位用户所有被限速的请求。这一组合让未授权活动得以混入熟悉的运营噪声。

围绕身份和用途建立基线，而不是只观察账户总量。对于每个应用凭据，在这些信号可得时保留请求时间、模型、结果、令牌或用量数量、来源工作负载和负责所有者。包括失败和被限速的尝试，因为侦察和尝试性消耗可能永远不会出现在成功使用总数中。不要把原始机密放入日志。

有用的异常规则会将当前行为与部署记录比较。例子包括工作负载计划之外的活动、计划实验结束后的持续使用、陌生来源、应用未获准调用的模型、错误与成功的异常比例，或请求速率的突然变化。这些信号比笼统的“高用量”警报更可操作，因为它们说明违反了哪项预期。

在不删除重要证据的前提下调整警报。嘈杂的限速消息应被分组和汇总，而不应从仪表板省略。目标是由完整、可搜索事件支撑的可管理警报流。每个警报都需要指定响应人员、严重级别、调查期限和自动升级路径。没有归属的警告只是不被处理的遥测数据。

为决策设计代理仪表板

有用的运营仪表板应能迅速回答四个问题：哪个凭据改变了行为、它被允许做什么、当前有多少价值处于风险中，以及哪项行动能够遏制它。按凭据、应用、模型和时间窗口展示用量与失败情况，而不要只显示全组织总数。显示硬限制消耗、临时例外、凭据年龄、上次轮换、负责人，以及关联部署是否仍获批准。

将安全与成本信号放在一起。提供商错误突发、新 SSH 密钥、身份验证失败和持续的 API 使用在各自独立的工具中可能显得轻微，但关联后会形成清晰的事件链。保留足够历史，以便将当前行为与同一工作负载的正常模式比较，并在之后重建过程。

仪表板应提供或直接链接到经过测试的遏制操作：禁用应用凭据、停止工作负载、移除公共访问，以及联系提供商。破坏性控制需要适当授权，但不应依赖于在活跃事件中寻找未记录的命令。记录谁在何时采取了每项行动。

演练凭据响应流程

围绕复制的密钥开展桌面演练或受控演练。从可信信号开始，例如持续的计划外流量加上反复出现的限速错误。要求值班响应人员确定负责人、确认受影响的提供商账户、禁用凭据、停止或隔离工作负载，并检查主机是否存在持久访问。随后，团队应轮换相关凭据，在适当情况下保留日志和取证映像，通知提供商，并确定数据或其他系统是否可被访问。

撤销是首个遏制步骤，而不是调查终点。METR 的响应包括停止受损实例、创建取证映像、轮换凭据、检查并擦除研究人员的笔记本电脑、通知模型公司，以及使用外部安全协助。确切顺序会有所不同，但原则稳定：移除当前访问，同时保留足够证据以确定入侵如何发生以及还必须改变什么。

按经过的时间和缺失信息衡量演练。发现、所有权查询、撤销、主机隔离和联系提供商各花了多久？哪些日志不完整？响应人员能否区分获赠额度与计费用量？每次演练后更新部署模板、仪表板和运行手册。

实施清单

• 清查每个面向互联网的代理服务、其负责人、到期日期、云环境、凭据、数据和工具。
• 对公共暴露或在用凭据访问要求默认拒绝式身份验证和基础审查。
• 将提供商机密置于模型可读上下文、转录内容、工具和可检索文件之外。
• 为每个应用使用具有最窄可用范围和实用有效期的凭据。
• 当直接提供商控制无法执行所需策略时，通过中介路由调用。
• 设置单次运行和滚动用量上限；凡提供商或中介支持之处都加入硬停止。
• 按凭据和预期工作负载监控成功、失败和被限速的请求。
• 对行为不匹配发出警报，而不只是对总成本或令牌量发出警报。
• 在代理仪表板中关联模型用量与身份验证和主机持久化事件。
• 为每个警报指定响应人员、期限、升级路径和经过测试的遏制行动。
• 演练密钥撤销、工作负载隔离、证据保全、提供商通知和恢复。
• 实验结束时撤销凭据和公共端点，然后验证流量已经停止。

防止 API 成本失控的最佳方法是采用重叠限制。机密隔离阻止轻易提取，狭窄身份减少爆炸半径，强制预算限制消耗，行为监控缩短发现时间，响应演练让撤销成为常规。没有任何一项依赖于正确猜测下一位攻击者将如何进入。它们共同将被盗密钥从开放式资源变成可遏制、可观察的事件。