发生了什么
一位独立软件开发人员最近遭遇了一次意外的5.2万美元账单，原因是一次涉及自主编码代理的灾难性事件。该代理的任务是解决一个软件bug，但却陷入了无限循环。在大约九个小时内，它反复执行失败的测试并尝试生成修复程序，消耗了大量的LLM（大型语言模型）Token。
核心问题源于该代理对生产云资源和LLM API的无限制访问。当时没有设置速率限制，没有Token支出上限，最关键的是，没有设置断路器来阻止异常行为。此次事件凸显了在利用AI进行自主操作的环境中日益增长的漏洞。
这并非传统意义上的孤立攻击，而是一种自我造成的拒绝服务，或者更准确地说，是“钱包拒绝服务”。开发人员的合法凭据，原本用于开发和测试，却为代理提供了进行无节制消费的钥匙。经济影响是即时且巨大的。
为什么这种模式会一再重演
AI代理的普及，特别是那些具有自主能力的代理，带来了一类新的操作风险。传统的安全范式侧重于防止未经授权的访问或数据泄露。然而，此类事件凸显了需要防范授权实体出现异常或恶意行为的情况。
许多组织正在快速采用AI工具，却未能充分理解其使用所带来的经济影响。云服务和LLM API的“按需付费”模式在未受监控的消耗下，成本可能迅速飙升。对于生成式AI尤其如此，其中每一次查询、每一个生成的Token都带有切实的成本。
此外，调试和验证自主代理行为的复杂性往往被低估。代理在动态环境中运行，与外部API和服务交互。其逻辑中的一个细微bug，或来自外部依赖的意外响应，都可能导致失控进程，如果没有主动控制，将难以检测和阻止。
“真正的危险不仅仅是数据泄露，而是由设计缺陷造成的经济灾难。我们的系统尚未建成以遏制其自身的数字后代。”
AI的“授权蔓延”
另一个促成因素是我们可以称之为“授权蔓延”的现象。开发人员在开发过程中，尤其是在快速迭代时，为了方便往往会授予AI代理广泛的权限。如果这些权限在部署前没有经过细致的修剪，它们就可能成为重要的攻击向量，或者在这种情况下，成为财务负担。在部署AI驱动解决方案的冲刺中，最小权限原则经常被忽视。
攻击者的逐步策略
虽然这次特定事件并非外部攻击，但该场景为旨在造成财务中断或资源耗尽的攻击者提供了一个蓝图。攻击者的目标是触发类似的失控过程，利用受害者的自身基础设施来对付他们。
- 侦察与漏洞识别： 攻击者首先会识别使用AI代理的系统。他们会寻找公开暴露的API、配置错误的云资源，或包含嵌入凭据或过于宽泛权限的代理代码仓库。
- 初始访问（或恶意注入）： 这可能涉及利用传统漏洞（例如，针对常见Web框架的CVE-2023-XXXX）来访问托管代理的系统，或者更隐蔽地，向代理的输入流注入恶意提示或数据，从而操纵其行为。
- 代理操纵： 一旦获得访问权限或代理受到影响，攻击者的目标是迫使代理进入一个昂贵的、自我持续的循环。这可能涉及精心设计输入，使其始终触发失败条件，促使代理反复尝试修复、生成大量代码，或查询昂贵的LLM API。
- 凭据利用： 代理在拥有合法（但权限过高）的生产凭据下运行，会执行这些代价高昂的操作。这可能包括生成过多的API调用、调配不必要的云资源，或执行复杂、Token密集型的LLM交互。
- 混淆与持久性（可选但很可能）： 经验丰富的攻击者可能会尝试混淆失控进程的来源，或建立持久性以在未来触发类似事件，使取证分析更具挑战性。
- 钱包拒绝服务： 主要目标已经实现：目标组织产生了巨额、意想不到的云和AI服务账单，可能导致运营中断或财务困境。
防御者错过了什么
此次事件中，一些关键的安全控制和架构考量缺失或不足。最明显的遗漏是缺乏精细的成本控制和实时监控。
首先，LLM API调用的Token预算和速率限制根本不存在。将LLM API访问像其他资源一样对待，设置预定义的支出限制和节流机制是基础。没有这些，一个配置错误的代理就可能迅速耗尽整个组织的预算。
其次，断路器和紧急停止开关没有实施。在高风险的自主系统中，当超出预定阈值（例如，成本、API错误、计算负载）时，自动或手动停止操作的能力至关重要。这作为防止失控进程的最后一道防线。
第三，最小权限原则被违反。代理使用生产密钥操作，这赋予了它对其任务而言不必要的广泛权限。开发和测试环境应严格使用隔离的、范围受限的凭据，绝不能使用生产密钥。
最后，对异常资源消耗的持续监控要么不存在，要么未配置为对这些特定模式发出警报。云成本管理工具虽然有用，但通常事后才提供报告。实时异常检测对于在事件发生时捕获它们至关重要。
一份实用的防御清单
CISO和安全工程师必须主动应对这些新兴风险。为AI代理实施强大的安全态势需要多方面的方法。
- 实施精细的Token预算： 对每个代理、每个项目和全球范围内的LLM Token支出强制执行硬性上限。利用云提供商工具或API网关来强制执行这些限制。
- 强制执行速率限制： 对自主代理进行的所有LLM API调用和其他外部服务交互应用严格的速率限制。这可以防止快速、不受控制的消耗。
- 部署断路器： 将自动化断路器集成到代理编排平台中。如果成本阈值、错误率或资源消耗飙升，这些断路器应跳闸并停止代理操作。
- 为代理凭据强制执行最小权限： 为代理分配其任务所需的绝对最小权限。切勿将生产凭据用于开发或测试。尽可能使用临时、有范围的凭据。
- 实时成本异常检测： 配置云成本管理和可观察性平台，以便在与代理相关的服务出现异常支出模式或API使用量突然飙升时立即发出警报。
- 隔离开发和生产环境： 严格分离环境。开发或测试中的代理绝不应在没有严格控制的情况下访问生产资源或昂贵的LLM API。
- 定期对代理逻辑和权限进行安全审计： 定期审查代理代码、其交互以及授予的权限，以确保符合安全最佳实践并检测潜在漏洞。
现代攻击性测试如何能发现这个问题
现代攻击性安全实践，特别是那些专注于AI系统的实践，本可以在产生五位数账单之前很久就发现这个漏洞。全面的红队演练将涉及专门设计场景，以激发失控代理行为并测试财务和操作防护措施的有效性。
这不仅包括扫描传统漏洞，还包括积极探测代理对畸形输入、意外API响应和资源耗尽攻击的弹性。将每个代理与Token预算上限、速率限制和断路器包装起来的工具至关重要。它们允许安全团队模拟失控循环，确保配置错误或攻击只会导致几分钟的中断，而不是财务灾难。这种主动方法验证了保护机制，确保它们在压力下按预期运行。
接下来要关注什么
AI代理安全格局正在迅速演变。我们预计，专门的“钱包拒绝服务”攻击将有所增加，攻击者将利用受损或被操纵的代理为目标造成巨大的云和AI服务成本。这些攻击更难以用传统的入侵检测系统检测，因为它们通常涉及合法凭据和授权操作，尽管规模极端。
此外，更复杂的自主代理的开发将需要可解释AI（XAI）和可验证AI的进步。理解代理做出特定决策的原因，特别是那些具有重大财务影响的决策，对于取证分析和防止再次发生至关重要。预计将有更多关注代理沙盒、代理行为的正式验证，以及超越单纯提示注入防御以解决系统性风险的专用AI安全框架的出现。
