BOSSAI AI代理越权攻击：台北调度记录失窃

事件回顾：自主代理如何绕过传统安全边界

据Reddit社区讨论，一名台湾黑客利用BOSSAI的AI代理框架，从台北公共安全基础设施中窃取了紧急调度记录。这些代理在运行过程中能够自主操作，跨系统连续调用工具，且在整个链条中没有任何针对单次操作的授权检查。等到入侵行为被发现时，记录早已外泄。

这起事件的核心并不在于黑客使用了多么高深的技术，而在于AI代理在其接触的每一个下游系统中，都被识别为合法的服务进程。它们继承了编排环境中的有效凭证，每一次工具调用看起来都是被授权的，因为代理本身看起来就是被授权的。安全验证只发生在会话边界，而非操作层面。

AI代理框架（AI Agent Framework）是指为自主智能体提供规划、工具调用、记忆管理和执行编排的软件基础设施，典型代表包括LangChain Agents、AutoGPT、Microsoft AutoGen等。这类框架的核心机制是让大语言模型根据目标自主决定调用哪些工具（如API、数据库查询、文件操作），并通过工具调用链（tool chaining）将多个操作串联完成复杂任务。框架通常以服务账号或继承的会话凭证运行代理，以便代理能够无缝访问下游系统。这种设计极大提升了自动化能力，但也意味着代理一旦被恶意引导，其所有工具调用都会以合法身份执行，传统基于会话边界的认证机制难以察觉异常。

结构性缺陷：代理即“内鬼”

问题并非BOSSAI所独有。任何将凭证委托给自主进程、却未将身份与具体操作绑定的代理框架，都面临同样的暴露风险。代理在被实例化的那一刻，就变成了一个受信任的内部人员。

紧急调度系统是高价值目标的典型代表，但同样的模式适用于任何代理接触敏感API、数据库或通信渠道的场景——只要权限是继承来的，且运行时没有对每次调用进行校验。

据社区讨论，这种“会话级授权、操作级放行”的架构在多个代理框架中普遍存在。攻击者不需要破解凭证，只需要让代理“合法地”执行恶意操作即可。

凭证委托（credential delegation）是指系统将自身权限临时或永久授予另一个进程或服务，使其能够代表原系统执行操作。在AI代理场景中，编排环境通常将API密钥、OAuth令牌或服务账号凭证传递给代理实例，以便代理自主调用下游服务。问题在于，许多框架仅做会话级授权——即在代理启动时验证一次身份，之后便信任该会话内的所有操作。这与操作级授权（per-operation authorization）形成对比：后者要求每次工具调用都独立校验调用者身份、权限和上下文。缺乏操作级校验时，代理的任何链式调用都会被下游系统视为合法请求，攻击者无需窃取凭证即可借代理之手完成越权操作。

实践者的困境：如何实现操作级授权？

原帖作者向社区提出了一个尖锐问题：在生产环境中，大家究竟是如何处理自主代理的操作级授权？不是会话级认证，而是针对每次工具调用、在链条中途进行的授权检查。

讨论中反映出的共识是，传统安全模型假设“一次认证，持续信任”，而代理的自主性和链式调用打破了这一假设。部分实践者尝试在工具调用层引入策略引擎，对每个动作进行独立鉴权，但面临性能开销和策略复杂度的双重挑战。

也有观点指出，将代理视为“零信任”主体是更务实的方向：每次调用都需重新验证身份与权限，不依赖会话上下文。然而，在真实工作负载下，这种做法的可行性仍有待验证。

零信任架构（Zero Trust Architecture）的核心原则是“永不信任，始终验证”，即不因请求来自内部网络或已认证会话就自动授予信任，而是对每次访问请求都进行独立鉴权。将这一模型应用于AI代理，意味着代理不再被视为可信内部主体，每次工具调用都需要重新验证身份、权限和操作合法性。实现方式包括：为每个操作签发短期、细粒度的令牌；在工具调用层部署策略引擎（如Open Policy Agent）进行实时决策；以及记录完整的调用链审计日志。挑战在于，零信任代理模型会增加每次调用的延迟和策略管理复杂度，在高频自主调用场景下可能显著影响性能，因此需要在安全强度与运行效率之间寻找平衡。

对AI代理部署的启示

这起事件为所有部署自主代理的团队敲响了警钟。代理框架的安全设计不能止步于会话管理，必须下沉到操作粒度。身份绑定、最小权限、运行时策略执行，这些原则需要被重新审视并嵌入代理架构。

对于使用第三方代理框架的团队，审查其授权模型是否支持逐调用校验，应成为安全评估的必选项。紧急调度记录失窃只是冰山一角，真正的风险在于，无数生产环境中的代理正以同样的方式“合法”地访问着敏感资源。