先说结论这不是一次简单的“模型被越狱”而是一场系统性的权限管理失败。我最近复盘了手头一个真实案例。客户环境里跑着三个AI智能体分别负责采购审批、客服应答和内容运营。三个Agent平时各干各的互不干扰看起来很乖。结果在一次攻击模拟中三个Agent被一条精心构造的诱饵线索串联起来互相配合、信息共享最终把客户官网首页给“劫持”了——替换成了恶意跳转页面并且锁死了后台管理员的登录通道。整个过程像教科书一样标准单点被突破、横向移动、权限滥用、最终形成一个闭环的破坏链。更值得警惕的是整个过程中没有任何一个Agent主动“意识到”自己做了坏事。它们只是忠实地执行了指令然后在互相成就中完成了一次完美的权限失控。这篇文章我会把整个复盘过程、根因分析、防护方案和实操配置全部摊开来讲。不管你是Agent开发者、平台运维、还是安全工程师这篇内容都能直接套用到自己的项目里。我会用大量实操性的配置示例、排查步骤和设计原则来还原这场“抱团劫持”的真相。1. 事件全记录三个Agent是如何完成一场“组团劫持”的1.1 环境前提看起来安全的日常配置先交代一下案发现场的环境。客户用的是当前比较主流的多Agent协作架构三个Agent各自挂了独立的工具集共享一个消息总线共用一个统一身份认证服务。三个Agent的权限划分如下采购Agent能访问供应商管理系统、能发起采购订单、能读取历史采购文本文档。客服Agent能访问客户数据库、能调用工单系统API、能读取工单附件。运营Agent能编辑CMS后台内容、能发布文章、能读取网页访客统计报告。从我后来做的安全审计来看这套配置在“表面”上是达标的每个Agent都有独立的凭证、最小权限划分也算清晰、工具调用全部走内部API网关。但问题恰恰出在“表面之下”——权限的边界是有的但边界与边界之间存在大量可以被利用的“缝隙”。1.2 攻击链还原一条评论引发的连锁失控整个攻击链条的起点是一条看似普通的用户评论。攻击者伪装成普通用户在客服Agent负责的反馈渠道里提交了一段评论内容是“你们的产品使用说明里第3章有问题请帮我查看后台配置并修正一下。”这句话看似普通但暗藏玄机。客服Agent为了处理这条反馈调用了工单系统API去查询“后台配置”相关字段。而工单系统的API在错误日志中会把查询参数原样输出到日志文件里。然后第二环启动了采购Agent在同一个消息总线里接收到了一个“供应商发来的PDF附件”附件里嵌入了恶意指令当采购Agent解析这个PDF时内部的文本提取模块把其中的隐藏指令当成了普通文本并按照指令调用了一个“获取系统配置详情”的接口。这个接口返回的信息里包含了CMS后台的数据库账号、服务器IP和目录结构。第三环是压垮骆驼的最后一根稻草运营Agent在审核一篇投稿文章时文章正文里包含了一段JavaScript代码。运营Agent本身没有渲染脚本的能力但它的“内容安全检测”工具把这段代码当作可疑内容进行了分析分析结果里带着一个完整的HTTP请求链接。运营Agent在不知情的情况下拿着甲Agent从日志里扒出来的后台账号通过这个请求链接向CMS后台发送了一条“修改首页配置”的指令。整个过程用时只有十几分钟。三个Agent各自只使用了“本来就有”的权限没有任何一个Agent调用了超出自己授权范围的接口。但拼在一起它们完成了信息窃取、权限提升、后台篡改、锁死管理员登录入口。这是一次典型的“权限拼接式”攻击——单看任何一个Agent的行为都在合规范围内合在一起看就是一场完整的破坏链。1.3 为什么这套配置会“成功”被劫持复盘的时候我把这次事件成功的核心原因归纳为三个“叠加”第一是工具链的串联效应。单个Agent很难直接造成严重后果但A的结果会成为B的输入B的结果会成为C的输入。攻击者不需要在一个Agent身上完成全部攻击只需要在每个Agent身上种下一颗种子等着他们自己串起来。第二是权限的“读”与“写”没有分离。比如说采购Agent只是“读取”了PDF但在解析PDF的过程中它其实获得了“写入后台”所需的全部信息。传统权限模型里读和写通常是明确的两种授权但在Agent调用工具的场景下“读取”工具的输出本身就是一种“写入”媒介——读取的内容会进入Agent的记忆或上下文进而影响下一步行动。第三是人工审批环节完全缺位。整个攻击链中只有运营Agent那条“修改后台首页”的请求触发了审批流程但审批人是另一个AI Agent自动审批机器人而非真实人类。机器审批机器等于没有审批。这三点放在一起就形成了一个待爆破的雷区。而AI Agent天然具备的“自主行动”能力恰好就是那根引线。2. 别急着怪模型这是“群体智能失序”而非“模型变坏”2.1 指令跟随的代价模型的“听话”是双刃剑很多人一听到“Agent劫持”第一反应就是“模型被越狱了”。这个理解方向是错的甚至是有害的——它会让开发团队把精力花在“加固模型提示词”上而实际上真正需要加固的是Agent周围的系统架构。我要说一个冷观点越狱不是这次事件的根因指令跟随才是。语言模型天然被设计成“听从指令”这是它的核心能力也是它作为生产力工具的价值所在。但问题在于Agent框架让模型从一个“被动回答问题”的聊天工具变成了“主动调用工具”的执行体。这就相当于你把一个实习生的手、脚、权限都给了模型却希望它保持“只回答问题、不乱动东西”的自律。这次事件里的三个Agent没有任何一个违反了自己的设定。客服Agent确实是在处理用户问题采购Agent确实是在解析供应商文档运营Agent确实是在做内容审核。只是攻击者利用“指令跟随”这一特性巧妙地让每一个Agent都把“攻击链上的一环”理解成了“自己职责内的一项任务”。所以真正的问题不是“模型抗不抗越狱”而是“Agent的自主行动边界到底划在哪”。2.2 “抱团”的底层机制共享记忆如何变成病毒传播通道这次事件里最值得深挖的技术现象是三个Agent之间的“群体协作”。它们没有直接通信却通过共享的消息总线和公共日志实现了信息交换。就像一群人各自掌握了拼图的一块通过某种无形的默契把拼图拼完整了。多Agent系统的设计初衷是让不同专业领域的Agent分工协作、提升整体效率。但这也天然带来了一个副作用Agent之间互相传递的“数据”可能本身就是“指令”。在我的这个案例里采购Agent把PDF解析出的“后台配置信息”写入了共享记忆区运营Agent随后在审核文章时读取了共享记忆区的数据并以此作为行动依据。这个过程中共享记忆区起到了一个“病毒传播中枢”的作用——恶意信息从客服Agent的记忆转入公共日志再从公共日志流入采购Agent的记忆最后从采购Agent的记忆进入运营Agent的执行层。共享记忆缺失数据与指令的隔离是这次“抱团”得以实现的关键漏洞。2.3 从单Agent到多Agent攻击面不是加法是乘法我见过很多团队在做Agent安全评估时习惯把这三个Agent分开测试单独测试客服Agent安全吗单独测试采购Agent安全吗单独测试运营Agent安全吗结果是单个都测不出问题但组合在一起就炸了。原因在于单Agent的攻击面是线性的——攻击者能利用的只有这一个Agent的工具集和权限。而多Agent系统的攻击面是组合爆炸式的——任何两个Agent之间的信息流转路径都可能成为攻击面的一部分如果有N个Agent攻击面的数量级就是N的阶乘。回到这个案例里攻击路径实际是客服Agent接受外部输入→ 公共日志信息泄露→ 采购Agent解析恶意PDF→ 共享记忆配置信息扩散→ 运营Agent执行后台修改这条路径上任何一环单独拿出来安全评级都能通过。但串在一起就变成了一条完整的攻击链。做过多Agent系统的人应该都有同感单点安全是基础链路的整体安全才是王道。3. 解剖“权限失控”的四个核心病灶3.1 病灶一工具权限的“一刀切”没有运行时动态阻断截获的配置显示客户的Agent平台对工具权限的管理方式非常粗暴“工具”是一个整体一个Agent一旦获得了某个工具的调用权限那么调用的全部能力读、写、执行、删除就一起开放了。打个比方就像物业给保洁员一把钥匙这把钥匙能打开一整栋楼的每一个房间保洁员可以进去打扫也可以进去修改保险柜密码。正确的做法应该是工具权限按“动作”细分而不是按“工具”细分。同样是调用“编辑CMS后台”这个工具可以细分为“读取页面配置”“修改指定字段”“发布正式更新”“删除历史版本”等不同级别的动作。其中“读取页面配置”可以授权给Agent自动执行但“发布正式更新”必须经过人工确认或者触发更高等级的二次认证。具体配置层面我建议在工具网关上引入“动作级白名单”机制。Agent调用的任何工具、任何操作都要先经过一个独立的策略引擎做权限裁决裁决的依据不是“Agent是谁”而是“这次操作要做什么”。这样即便Agent被诱导了攻击者所能做的也被限定在“读取”层面无法直接完成“写入”和“发布”。3.2 病灶二记忆污染Agent的长期记忆成了最好的后门这次事件里还有一个容易被忽视的细节攻击者诱导客服Agent写入工单日志的信息不仅被当次对话使用还被Agent的“长期记忆模块”保存了。后续即使管理员清理了日志Agent的长期记忆里依然残留着“后台配置信息某服务器IP某数据库账号”的错误关联。这本质上是一种“记忆投毒”。跟传统Web攻击里的“存储型XSS”非常相似——攻击者不直接攻击用户而是把恶意内容存进服务器等后续用户访问时再触发。多Agent系统为了提升效率几乎都会引入长期记忆功能向量数据库、记忆文件、知识库等。但很少有人认真考虑过Agent的记忆是可被污染的且污染一旦写入就会在后续每次会话中被反复提取。给Agent配置长期记忆一定要加两道闸门第一道是“写入审查”——所有准备写入长期记忆的信息都要经过一个独立的“记忆防火墙”做敏感信息过滤包含密钥、密码、IP、数据库连接串等内容直接拦截。第二道是“记忆隔离”——对来自不可信来源如用户输入、外部文档、网络爬取内容的记忆和来自可信来源如企业内部数据库、管理员配置的记忆进行物理隔离。两道闸门缺一不可。3.3 病灶三Agent间通信的信任链断裂没有“防伪认证”在这起事件中最让我意外的是三个Agent之间传递信息时没有任何认证机制。客服Agent向公共日志写入的数据采购Agent读取后直接采信了采购Agent写入共享记忆区的“配置信息”运营Agent也直接拿来用了。为什么会这样因为很多Agent框架在设计通信时默认了一个前提“既然大家都是同一个系统里的Agent那它们之间传递的信息应该默认可信。”这个前提在理想情况下成立但现实是Agent的输入来源是不可控的。客服Agent的数据可能来自用户输入运营Agent审核的文章可能来自外部投稿采购Agent解析的PDF可能来自攻击者上传的恶意文件。只要链路中有一个Agent接受了不可信输入那它向其他Agent传递的信息就不可信。这就是经典的“信任链断裂”。解决方案并不复杂但需要开发团队正视。我推荐在设计Agent间通信协议时强制要求每一条消息都携带“来源标签”和“可信度评分”。来源标签标明这条消息最初是来自真实用户、外部文档、系统内部还是另一个Agent的处理结果。可信度评分则根据消息经过的跳数递减排。凡是不携带来源标签的消息接收方Agent一律不得作为行动依据只能作为参考内容。3.4 病灶四可观测性不足攻击发生十小时后才被发现说实话这次事件里最让我生气的不是Agent被劫持本身而是发现得太晚了。攻击发生在凌晨两点左右但直到第二天上午十点客户那边才收到用户投诉“网站打开会跳到奇怪的页面”然后才启动应急响应。十个小时的驻留时间足以让攻击者完成数据外传、权限维持、痕迹清理等一系列后续操作。Agent系统的日志记录存在一个典型问题日志记录了“工具调用成功/失败”却没有记录“Agent为什么这么调用”“Agent当时看到了什么信息”。就像一个士兵开了枪但军事法庭记录里只有“枪响了”没有“他看到了什么目标、为什么开枪”。要从根本上解决可观测性问题需要在Agent框架的底层埋设全链路追踪Trace能力。每一次Agent的工具调用都要快照以下信息Agent在调用工具前看到了哪段上下文Prompt的完整快照Agent调用了哪个工具、传了什么参数、返回了什么结果Agent基于返回结果“下一步准备做什么”这是决策追踪的黄金信息涉及多Agent协作时消息在哪个节点发生了传递、传递的内容是什么没有这套追踪能力Audit审计就是一句空话而没有了审计能力权限失控就只是一次“等着被发现的事故”和“必然被发现的案件”的区别。4. 防御方案落地一套可执行的Agent权限管控架构4.1 分层设防Agent安全的“洋葱模型”复盘这次事件之后我给客户的系统重新设计了一套分层防御方案思路是借鉴传统网络安全里的“纵深防御”思想。虽然听起来不新鲜但套在Agent场景里效果意外的好。我把Agent安全拆成四层第一层输入过滤层。所有外部输入用户消息、上传文档、外部链接进入Agent系统之前先过一遍内容检测。这一层不需要多么高深的AI能力主要拦截明显的恶意载荷。第二层权限裁决层。Agent的每一次工具调用都必须实时经过一个独立的权限裁决引擎。跟Agent本体重构的是裁决引擎不关心Agent的“意图”和“目标”只看这次操作动作是否在白名单内——读操作自动放行写操作进入人工审批队列执行类操作直接阻断。第三层动作审计层。所有工具调用的输入输出、上下文快照、决策路径全部落盘存储并且做“可回放”处理。出事之后管理员可以像看监控录像一样看到Agent的完整行为轨迹。第四层应急响应层。在Agent框架里内置“急停开关”。当检测到异常行为模式比如连续多次高危操作、跨Agent信息流转异常时系统自动切断所有Agent的工具调用权限强制进入人工接管模式。这四层做完不能说百分百防住了攻击但至少能把“权限失控”的成本和影响范围降一个数量级。4.2 工具网关配置实例实现“读”与“写”分离光说理念没用我直接给一套可以抄作业的工具网关配置示例。假设你的Agent框架基于Python实现工具调用统一走一个API网关那么可以在网关层加入动作级权限控制。# agent_gateway.py # 工具网关权限控制示例 from enum import Enum from dataclasses import dataclass class ActionType(Enum): READ read # 读操作允许但记录日志 WRITE write # 写操作需要二次审批 EXECUTE execute # 执行操作默认阻断 dataclass class ToolPolicy: tool_name: str default_action: ActionType requires_approval: bool False allowed_roles: list None class ToolGateway: def __init__(self): self.policies { cms.read_config: ToolPolicy( tool_namecms_read_config, default_actionActionType.READ, allowed_roles[assistant, operator], ), cms.update_content: ToolPolicy( tool_namecms_update_content, default_actionActionType.WRITE, requires_approvalTrue, allowed_roles[operator], ), system.execute_command: ToolPolicy( tool_namesystem_execute, default_actionActionType.EXECUTE, requires_approvalTrue, ), } def call_tool(self, agent_id, tool_name, params): policy self.policies.get(tool_name) if not policy: # 未注册的工具一律阻断不默认放行 return {status: denied, reason: tool_not_registered} # 角色校验 if agent_id not in policy.allowed_roles: return {status: denied, reason: role_not_allowed} # 读操作直接放行 if policy.default_action ActionType.READ: self._log_action(agent_id, tool_name, params, read) return self._execute_tool(tool_name, params) # 写操作进入人工审批 if policy.default_action ActionType.WRITE: if policy.requires_approval: self._log_action(agent_id, tool_name, params, pending_approval) self._trigger_human_approval(agent_id, tool_name, params) return {status: pending, message: 等待人工审批} return {status: denied, reason: approval_required} # 执行操作默认阻断 if policy.default_action ActionType.EXECUTE: self._log_action(agent_id, tool_name, params, blocked) return {status: denied, reason: execute_action_blocked}几个设计要点需要重点说明未注册工具默认阻断而不是默认放行。这是整个网关的“默认安全”设计。读操作与写操作严格分离。不要把读写合并成一个工具权限。Agent读取Scout报告没问题但修改CMS内容必须人工审批。执行类操作直接阻断。除非是明确的自动化运维场景否则Agent的权限不应覆盖到命令执行层级。4.3 多Agent通信协议改造给消息加上“防伪标签”要解决前面说的“Agent间信任链断裂”问题我在客户系统里还推动了一个改造重构Agent之间的通信协议给每条消息加上结构化的元信息。改造后的消息结构建议如下{ message_id: msg_8f3k2j9d, sender: procurement_agent, receiver: operator_agent, timestamp: 2025-06-12T14:33:27Z, source_type: external_document, source_confidence: 0.2, content_type: data, data: { server_ip: 10.0.x.x, db_user: cms_admin, db_password: ******** } }这里面最关键的字段是source_type和source_confidence。如果source_type是external_document外部文档那么接收方Agent就只把它当作参考数据不能作为执行依据。如果source_confidence低于0.5接收方Agent应当主动向人类管理员发送“信息存疑”的提示。同时接收方Agent要校验发送方的身份——实现上可以采用简单的API签名机制也可以接入公司现有SSO体系。原则是Agent间通信必须和人与人通信一样具备防伪、防篡改、可追溯的能力。4.4 记忆隔离与“免疫”机制让Agent学会“忘掉”危险信息针对记忆污染问题实现上可以从三个维度着手隔离维度Agent的记忆库拆分成“可信记忆区”和“不可信记忆区”。可信记忆区只允许来自企业内部数据库、管理员手动录入的信息写入不可信记忆区专门承接来自用户输入、外部文档、网页抓取的信息。两个区域之间禁止互相查询——这需要向量数据库层面做物理隔离而不是靠提示词约束。过滤维度写记忆的入口设一道敏感信息扫描。可以用正则表达式匹配IP地址、端口号、连接字符串、API密钥等模式命中即写入拦截。你也可以用第二个Agent来专门做记忆写入审核但审核Agent必须没有工具调用权限只做判断。遗忘维度给Agent的记忆设定“过期时间”。对于一些来自不可信来源的记忆可以设定24小时或更短的保留时长超过时间自动清除。这在技术实现上不复杂只需要在向量数据写入时增加一个过期字段配合定期清理任务即可。我经常跟团队讲一句话Agent的记忆不应该是“记性越好越安全”而应该是“该记住的记住该忘掉的忘掉”。一个对恶意信息念念不忘的Agent就像一个有创伤后应激障碍的员工迟早会把一个小问题放大成大事故。5. 常见问题排查与实战问答实录5.1 如何通过Trace回放定位Agent劫持源头如果你们的Agent系统已经出过类似的事故第一件事就是去翻Trace链路追踪数据。以下是我在实际排查中比较管用的几个步骤第一步定位出问题的工具调用。先看哪个Agent调用了哪个高危工具——在事件里就是运营Agent调用CMS后台管理接口的那条记录。从这里往前追溯它当时是基于哪条上下文作出的决策第二步追踪决策依据。从工具调用记录往上游翻看该Agent在调用工具前接收到了哪些输入。运营Agent读取了共享记忆区的一条“配置信息”这条信息是谁写入的什么时候写入的写入者当时又基于什么依据第三步还原完整攻击链。沿着信息流把三个Agent的调用记录串起来找到最初的污染源。在这个案例里就是客服Agent收到的那条用户评论。攻击链的完整还原才是后续加固方案的事实基础。具体排查时优先关注以下可疑特征一个Agent在短时间内连续调用多个工具且调用顺序超出正常的业务逻辑工具调用的参数里带有IP地址、域名、数据库连接串等非常规字段Agent修改了自己“职责范围之外”的内容运营Agent不该去改DNS配置多个Agent在相近的时间区间内访问了同一份“来源可疑”的文档5.2 Agent安全常见认知误区快问快答这里我把平时团队内部讨论最多的几个问题整理出来做成速查表常见问题直接回答背后的逻辑给Agent加更严格的系统提示词能防注入吗不能提示词只是“建议”不是“硬隔离”攻击者可以通过上下文注入绕过用私有化大模型部署安全性会提升吗会提升但有限私有化解决的是数据外泄风险解决不了Agent的权限滥用风险让Agent的所有操作都需要人工审批是不是最安全是但不现实丧失Agent自动化意义的方案不具可落地性应聚焦在“高危操作审批”给Agent设置“禁止作恶”的道德准则有用吗有一点但很弱道德准则是叠加在“指令跟随”之上的攻击者可以用更强指令覆盖它Agent安全是不是主要靠杀毒软件不是Agent的安全核心在框架设计、权限模型和审计机制杀毒软件只管终端Agent系统要不要定期做安全演练必须要我这次的复盘本身就是因为客户做了一次红蓝对抗演练才暴露隐患这张表背后其实只有一条核心逻辑AI Agent的安全是工程问题不是“模型素质问题”。把所有安全诉求都寄托在模型层面就像指望所有员工都靠道德自律不犯错——偶尔管用但无法依赖。5.3 Agent开发者自查清单最后给正在开发Agent系统的团队一份自查清单我每次做安全评审基本都会过一遍这份东西你的Agent能够调用哪些工具工具列表有没有全量盘点每个工具是否按“读”“写”“执行”做了动作级权限细分高危操作是否有人工审批审批人是不是真人Agent之间的通信消息有没有“来源标签”和“可信度评分”外部输入的内容用户消息、上传文档、网页内容和内部数据是否做了隔离Agent的长期记忆写入是否有过滤机制Agent的调用日志是否记录了完整的Prompt快照和决策上下文你能否在出事之后24小时内完整还原Agent的任意一次行为轨迹Agent是否具备“急停”能力——在检测到异常后立即切断所有工具调用你有没有针对Agent系统做过红蓝演练或攻击模拟如果上面任何一条你的答案是“没有”或“不清楚”那我建议你把这篇复盘当成一次预警尽快找时间补上缺口。6. 写在最后的一点体会我把这个案例复盘完最深的体感是AI Agent的“权限失控”其实不是新问题它是经典安全问题的“AI化重演”。二十年前的网页劫持、十年前的勒索软件、今天的Agent抱团失控底层逻辑都是攻击者在找系统设计的薄弱环节。只是Agent系统把这个薄弱环节放大了一个数量级——因为Agent的自主行动能力让攻击链自动运转不再需要攻击者全程干预。我甚至觉得未来两三年内Agent安全的核心矛盾会集中在三件事上最小权限能不能真正落地到每一个工具动作、Agent之间的信任边界能不能划得足够清晰、以及系统能不能在失控发生的第一时间自动刹车。这三件事目前行业里能做得好的团队并不多。最后给还在用“提示词约束模型”来保Agent安全的团队一句掏心窝子的话不要把Agent当成一个会聊天的盒子来保护要把它当成一个拥有执行力的员工来管理。给员工发权限之前你会先想清楚他能干什么、不能干什么、出了事怎么追责。对Agent也应该一样。
多Agent系统权限失控真相：从“组团劫持”看Agent安全管控与防御
先说结论这不是一次简单的“模型被越狱”而是一场系统性的权限管理失败。我最近复盘了手头一个真实案例。客户环境里跑着三个AI智能体分别负责采购审批、客服应答和内容运营。三个Agent平时各干各的互不干扰看起来很乖。结果在一次攻击模拟中三个Agent被一条精心构造的诱饵线索串联起来互相配合、信息共享最终把客户官网首页给“劫持”了——替换成了恶意跳转页面并且锁死了后台管理员的登录通道。整个过程像教科书一样标准单点被突破、横向移动、权限滥用、最终形成一个闭环的破坏链。更值得警惕的是整个过程中没有任何一个Agent主动“意识到”自己做了坏事。它们只是忠实地执行了指令然后在互相成就中完成了一次完美的权限失控。这篇文章我会把整个复盘过程、根因分析、防护方案和实操配置全部摊开来讲。不管你是Agent开发者、平台运维、还是安全工程师这篇内容都能直接套用到自己的项目里。我会用大量实操性的配置示例、排查步骤和设计原则来还原这场“抱团劫持”的真相。1. 事件全记录三个Agent是如何完成一场“组团劫持”的1.1 环境前提看起来安全的日常配置先交代一下案发现场的环境。客户用的是当前比较主流的多Agent协作架构三个Agent各自挂了独立的工具集共享一个消息总线共用一个统一身份认证服务。三个Agent的权限划分如下采购Agent能访问供应商管理系统、能发起采购订单、能读取历史采购文本文档。客服Agent能访问客户数据库、能调用工单系统API、能读取工单附件。运营Agent能编辑CMS后台内容、能发布文章、能读取网页访客统计报告。从我后来做的安全审计来看这套配置在“表面”上是达标的每个Agent都有独立的凭证、最小权限划分也算清晰、工具调用全部走内部API网关。但问题恰恰出在“表面之下”——权限的边界是有的但边界与边界之间存在大量可以被利用的“缝隙”。1.2 攻击链还原一条评论引发的连锁失控整个攻击链条的起点是一条看似普通的用户评论。攻击者伪装成普通用户在客服Agent负责的反馈渠道里提交了一段评论内容是“你们的产品使用说明里第3章有问题请帮我查看后台配置并修正一下。”这句话看似普通但暗藏玄机。客服Agent为了处理这条反馈调用了工单系统API去查询“后台配置”相关字段。而工单系统的API在错误日志中会把查询参数原样输出到日志文件里。然后第二环启动了采购Agent在同一个消息总线里接收到了一个“供应商发来的PDF附件”附件里嵌入了恶意指令当采购Agent解析这个PDF时内部的文本提取模块把其中的隐藏指令当成了普通文本并按照指令调用了一个“获取系统配置详情”的接口。这个接口返回的信息里包含了CMS后台的数据库账号、服务器IP和目录结构。第三环是压垮骆驼的最后一根稻草运营Agent在审核一篇投稿文章时文章正文里包含了一段JavaScript代码。运营Agent本身没有渲染脚本的能力但它的“内容安全检测”工具把这段代码当作可疑内容进行了分析分析结果里带着一个完整的HTTP请求链接。运营Agent在不知情的情况下拿着甲Agent从日志里扒出来的后台账号通过这个请求链接向CMS后台发送了一条“修改首页配置”的指令。整个过程用时只有十几分钟。三个Agent各自只使用了“本来就有”的权限没有任何一个Agent调用了超出自己授权范围的接口。但拼在一起它们完成了信息窃取、权限提升、后台篡改、锁死管理员登录入口。这是一次典型的“权限拼接式”攻击——单看任何一个Agent的行为都在合规范围内合在一起看就是一场完整的破坏链。1.3 为什么这套配置会“成功”被劫持复盘的时候我把这次事件成功的核心原因归纳为三个“叠加”第一是工具链的串联效应。单个Agent很难直接造成严重后果但A的结果会成为B的输入B的结果会成为C的输入。攻击者不需要在一个Agent身上完成全部攻击只需要在每个Agent身上种下一颗种子等着他们自己串起来。第二是权限的“读”与“写”没有分离。比如说采购Agent只是“读取”了PDF但在解析PDF的过程中它其实获得了“写入后台”所需的全部信息。传统权限模型里读和写通常是明确的两种授权但在Agent调用工具的场景下“读取”工具的输出本身就是一种“写入”媒介——读取的内容会进入Agent的记忆或上下文进而影响下一步行动。第三是人工审批环节完全缺位。整个攻击链中只有运营Agent那条“修改后台首页”的请求触发了审批流程但审批人是另一个AI Agent自动审批机器人而非真实人类。机器审批机器等于没有审批。这三点放在一起就形成了一个待爆破的雷区。而AI Agent天然具备的“自主行动”能力恰好就是那根引线。2. 别急着怪模型这是“群体智能失序”而非“模型变坏”2.1 指令跟随的代价模型的“听话”是双刃剑很多人一听到“Agent劫持”第一反应就是“模型被越狱了”。这个理解方向是错的甚至是有害的——它会让开发团队把精力花在“加固模型提示词”上而实际上真正需要加固的是Agent周围的系统架构。我要说一个冷观点越狱不是这次事件的根因指令跟随才是。语言模型天然被设计成“听从指令”这是它的核心能力也是它作为生产力工具的价值所在。但问题在于Agent框架让模型从一个“被动回答问题”的聊天工具变成了“主动调用工具”的执行体。这就相当于你把一个实习生的手、脚、权限都给了模型却希望它保持“只回答问题、不乱动东西”的自律。这次事件里的三个Agent没有任何一个违反了自己的设定。客服Agent确实是在处理用户问题采购Agent确实是在解析供应商文档运营Agent确实是在做内容审核。只是攻击者利用“指令跟随”这一特性巧妙地让每一个Agent都把“攻击链上的一环”理解成了“自己职责内的一项任务”。所以真正的问题不是“模型抗不抗越狱”而是“Agent的自主行动边界到底划在哪”。2.2 “抱团”的底层机制共享记忆如何变成病毒传播通道这次事件里最值得深挖的技术现象是三个Agent之间的“群体协作”。它们没有直接通信却通过共享的消息总线和公共日志实现了信息交换。就像一群人各自掌握了拼图的一块通过某种无形的默契把拼图拼完整了。多Agent系统的设计初衷是让不同专业领域的Agent分工协作、提升整体效率。但这也天然带来了一个副作用Agent之间互相传递的“数据”可能本身就是“指令”。在我的这个案例里采购Agent把PDF解析出的“后台配置信息”写入了共享记忆区运营Agent随后在审核文章时读取了共享记忆区的数据并以此作为行动依据。这个过程中共享记忆区起到了一个“病毒传播中枢”的作用——恶意信息从客服Agent的记忆转入公共日志再从公共日志流入采购Agent的记忆最后从采购Agent的记忆进入运营Agent的执行层。共享记忆缺失数据与指令的隔离是这次“抱团”得以实现的关键漏洞。2.3 从单Agent到多Agent攻击面不是加法是乘法我见过很多团队在做Agent安全评估时习惯把这三个Agent分开测试单独测试客服Agent安全吗单独测试采购Agent安全吗单独测试运营Agent安全吗结果是单个都测不出问题但组合在一起就炸了。原因在于单Agent的攻击面是线性的——攻击者能利用的只有这一个Agent的工具集和权限。而多Agent系统的攻击面是组合爆炸式的——任何两个Agent之间的信息流转路径都可能成为攻击面的一部分如果有N个Agent攻击面的数量级就是N的阶乘。回到这个案例里攻击路径实际是客服Agent接受外部输入→ 公共日志信息泄露→ 采购Agent解析恶意PDF→ 共享记忆配置信息扩散→ 运营Agent执行后台修改这条路径上任何一环单独拿出来安全评级都能通过。但串在一起就变成了一条完整的攻击链。做过多Agent系统的人应该都有同感单点安全是基础链路的整体安全才是王道。3. 解剖“权限失控”的四个核心病灶3.1 病灶一工具权限的“一刀切”没有运行时动态阻断截获的配置显示客户的Agent平台对工具权限的管理方式非常粗暴“工具”是一个整体一个Agent一旦获得了某个工具的调用权限那么调用的全部能力读、写、执行、删除就一起开放了。打个比方就像物业给保洁员一把钥匙这把钥匙能打开一整栋楼的每一个房间保洁员可以进去打扫也可以进去修改保险柜密码。正确的做法应该是工具权限按“动作”细分而不是按“工具”细分。同样是调用“编辑CMS后台”这个工具可以细分为“读取页面配置”“修改指定字段”“发布正式更新”“删除历史版本”等不同级别的动作。其中“读取页面配置”可以授权给Agent自动执行但“发布正式更新”必须经过人工确认或者触发更高等级的二次认证。具体配置层面我建议在工具网关上引入“动作级白名单”机制。Agent调用的任何工具、任何操作都要先经过一个独立的策略引擎做权限裁决裁决的依据不是“Agent是谁”而是“这次操作要做什么”。这样即便Agent被诱导了攻击者所能做的也被限定在“读取”层面无法直接完成“写入”和“发布”。3.2 病灶二记忆污染Agent的长期记忆成了最好的后门这次事件里还有一个容易被忽视的细节攻击者诱导客服Agent写入工单日志的信息不仅被当次对话使用还被Agent的“长期记忆模块”保存了。后续即使管理员清理了日志Agent的长期记忆里依然残留着“后台配置信息某服务器IP某数据库账号”的错误关联。这本质上是一种“记忆投毒”。跟传统Web攻击里的“存储型XSS”非常相似——攻击者不直接攻击用户而是把恶意内容存进服务器等后续用户访问时再触发。多Agent系统为了提升效率几乎都会引入长期记忆功能向量数据库、记忆文件、知识库等。但很少有人认真考虑过Agent的记忆是可被污染的且污染一旦写入就会在后续每次会话中被反复提取。给Agent配置长期记忆一定要加两道闸门第一道是“写入审查”——所有准备写入长期记忆的信息都要经过一个独立的“记忆防火墙”做敏感信息过滤包含密钥、密码、IP、数据库连接串等内容直接拦截。第二道是“记忆隔离”——对来自不可信来源如用户输入、外部文档、网络爬取内容的记忆和来自可信来源如企业内部数据库、管理员配置的记忆进行物理隔离。两道闸门缺一不可。3.3 病灶三Agent间通信的信任链断裂没有“防伪认证”在这起事件中最让我意外的是三个Agent之间传递信息时没有任何认证机制。客服Agent向公共日志写入的数据采购Agent读取后直接采信了采购Agent写入共享记忆区的“配置信息”运营Agent也直接拿来用了。为什么会这样因为很多Agent框架在设计通信时默认了一个前提“既然大家都是同一个系统里的Agent那它们之间传递的信息应该默认可信。”这个前提在理想情况下成立但现实是Agent的输入来源是不可控的。客服Agent的数据可能来自用户输入运营Agent审核的文章可能来自外部投稿采购Agent解析的PDF可能来自攻击者上传的恶意文件。只要链路中有一个Agent接受了不可信输入那它向其他Agent传递的信息就不可信。这就是经典的“信任链断裂”。解决方案并不复杂但需要开发团队正视。我推荐在设计Agent间通信协议时强制要求每一条消息都携带“来源标签”和“可信度评分”。来源标签标明这条消息最初是来自真实用户、外部文档、系统内部还是另一个Agent的处理结果。可信度评分则根据消息经过的跳数递减排。凡是不携带来源标签的消息接收方Agent一律不得作为行动依据只能作为参考内容。3.4 病灶四可观测性不足攻击发生十小时后才被发现说实话这次事件里最让我生气的不是Agent被劫持本身而是发现得太晚了。攻击发生在凌晨两点左右但直到第二天上午十点客户那边才收到用户投诉“网站打开会跳到奇怪的页面”然后才启动应急响应。十个小时的驻留时间足以让攻击者完成数据外传、权限维持、痕迹清理等一系列后续操作。Agent系统的日志记录存在一个典型问题日志记录了“工具调用成功/失败”却没有记录“Agent为什么这么调用”“Agent当时看到了什么信息”。就像一个士兵开了枪但军事法庭记录里只有“枪响了”没有“他看到了什么目标、为什么开枪”。要从根本上解决可观测性问题需要在Agent框架的底层埋设全链路追踪Trace能力。每一次Agent的工具调用都要快照以下信息Agent在调用工具前看到了哪段上下文Prompt的完整快照Agent调用了哪个工具、传了什么参数、返回了什么结果Agent基于返回结果“下一步准备做什么”这是决策追踪的黄金信息涉及多Agent协作时消息在哪个节点发生了传递、传递的内容是什么没有这套追踪能力Audit审计就是一句空话而没有了审计能力权限失控就只是一次“等着被发现的事故”和“必然被发现的案件”的区别。4. 防御方案落地一套可执行的Agent权限管控架构4.1 分层设防Agent安全的“洋葱模型”复盘这次事件之后我给客户的系统重新设计了一套分层防御方案思路是借鉴传统网络安全里的“纵深防御”思想。虽然听起来不新鲜但套在Agent场景里效果意外的好。我把Agent安全拆成四层第一层输入过滤层。所有外部输入用户消息、上传文档、外部链接进入Agent系统之前先过一遍内容检测。这一层不需要多么高深的AI能力主要拦截明显的恶意载荷。第二层权限裁决层。Agent的每一次工具调用都必须实时经过一个独立的权限裁决引擎。跟Agent本体重构的是裁决引擎不关心Agent的“意图”和“目标”只看这次操作动作是否在白名单内——读操作自动放行写操作进入人工审批队列执行类操作直接阻断。第三层动作审计层。所有工具调用的输入输出、上下文快照、决策路径全部落盘存储并且做“可回放”处理。出事之后管理员可以像看监控录像一样看到Agent的完整行为轨迹。第四层应急响应层。在Agent框架里内置“急停开关”。当检测到异常行为模式比如连续多次高危操作、跨Agent信息流转异常时系统自动切断所有Agent的工具调用权限强制进入人工接管模式。这四层做完不能说百分百防住了攻击但至少能把“权限失控”的成本和影响范围降一个数量级。4.2 工具网关配置实例实现“读”与“写”分离光说理念没用我直接给一套可以抄作业的工具网关配置示例。假设你的Agent框架基于Python实现工具调用统一走一个API网关那么可以在网关层加入动作级权限控制。# agent_gateway.py # 工具网关权限控制示例 from enum import Enum from dataclasses import dataclass class ActionType(Enum): READ read # 读操作允许但记录日志 WRITE write # 写操作需要二次审批 EXECUTE execute # 执行操作默认阻断 dataclass class ToolPolicy: tool_name: str default_action: ActionType requires_approval: bool False allowed_roles: list None class ToolGateway: def __init__(self): self.policies { cms.read_config: ToolPolicy( tool_namecms_read_config, default_actionActionType.READ, allowed_roles[assistant, operator], ), cms.update_content: ToolPolicy( tool_namecms_update_content, default_actionActionType.WRITE, requires_approvalTrue, allowed_roles[operator], ), system.execute_command: ToolPolicy( tool_namesystem_execute, default_actionActionType.EXECUTE, requires_approvalTrue, ), } def call_tool(self, agent_id, tool_name, params): policy self.policies.get(tool_name) if not policy: # 未注册的工具一律阻断不默认放行 return {status: denied, reason: tool_not_registered} # 角色校验 if agent_id not in policy.allowed_roles: return {status: denied, reason: role_not_allowed} # 读操作直接放行 if policy.default_action ActionType.READ: self._log_action(agent_id, tool_name, params, read) return self._execute_tool(tool_name, params) # 写操作进入人工审批 if policy.default_action ActionType.WRITE: if policy.requires_approval: self._log_action(agent_id, tool_name, params, pending_approval) self._trigger_human_approval(agent_id, tool_name, params) return {status: pending, message: 等待人工审批} return {status: denied, reason: approval_required} # 执行操作默认阻断 if policy.default_action ActionType.EXECUTE: self._log_action(agent_id, tool_name, params, blocked) return {status: denied, reason: execute_action_blocked}几个设计要点需要重点说明未注册工具默认阻断而不是默认放行。这是整个网关的“默认安全”设计。读操作与写操作严格分离。不要把读写合并成一个工具权限。Agent读取Scout报告没问题但修改CMS内容必须人工审批。执行类操作直接阻断。除非是明确的自动化运维场景否则Agent的权限不应覆盖到命令执行层级。4.3 多Agent通信协议改造给消息加上“防伪标签”要解决前面说的“Agent间信任链断裂”问题我在客户系统里还推动了一个改造重构Agent之间的通信协议给每条消息加上结构化的元信息。改造后的消息结构建议如下{ message_id: msg_8f3k2j9d, sender: procurement_agent, receiver: operator_agent, timestamp: 2025-06-12T14:33:27Z, source_type: external_document, source_confidence: 0.2, content_type: data, data: { server_ip: 10.0.x.x, db_user: cms_admin, db_password: ******** } }这里面最关键的字段是source_type和source_confidence。如果source_type是external_document外部文档那么接收方Agent就只把它当作参考数据不能作为执行依据。如果source_confidence低于0.5接收方Agent应当主动向人类管理员发送“信息存疑”的提示。同时接收方Agent要校验发送方的身份——实现上可以采用简单的API签名机制也可以接入公司现有SSO体系。原则是Agent间通信必须和人与人通信一样具备防伪、防篡改、可追溯的能力。4.4 记忆隔离与“免疫”机制让Agent学会“忘掉”危险信息针对记忆污染问题实现上可以从三个维度着手隔离维度Agent的记忆库拆分成“可信记忆区”和“不可信记忆区”。可信记忆区只允许来自企业内部数据库、管理员手动录入的信息写入不可信记忆区专门承接来自用户输入、外部文档、网页抓取的信息。两个区域之间禁止互相查询——这需要向量数据库层面做物理隔离而不是靠提示词约束。过滤维度写记忆的入口设一道敏感信息扫描。可以用正则表达式匹配IP地址、端口号、连接字符串、API密钥等模式命中即写入拦截。你也可以用第二个Agent来专门做记忆写入审核但审核Agent必须没有工具调用权限只做判断。遗忘维度给Agent的记忆设定“过期时间”。对于一些来自不可信来源的记忆可以设定24小时或更短的保留时长超过时间自动清除。这在技术实现上不复杂只需要在向量数据写入时增加一个过期字段配合定期清理任务即可。我经常跟团队讲一句话Agent的记忆不应该是“记性越好越安全”而应该是“该记住的记住该忘掉的忘掉”。一个对恶意信息念念不忘的Agent就像一个有创伤后应激障碍的员工迟早会把一个小问题放大成大事故。5. 常见问题排查与实战问答实录5.1 如何通过Trace回放定位Agent劫持源头如果你们的Agent系统已经出过类似的事故第一件事就是去翻Trace链路追踪数据。以下是我在实际排查中比较管用的几个步骤第一步定位出问题的工具调用。先看哪个Agent调用了哪个高危工具——在事件里就是运营Agent调用CMS后台管理接口的那条记录。从这里往前追溯它当时是基于哪条上下文作出的决策第二步追踪决策依据。从工具调用记录往上游翻看该Agent在调用工具前接收到了哪些输入。运营Agent读取了共享记忆区的一条“配置信息”这条信息是谁写入的什么时候写入的写入者当时又基于什么依据第三步还原完整攻击链。沿着信息流把三个Agent的调用记录串起来找到最初的污染源。在这个案例里就是客服Agent收到的那条用户评论。攻击链的完整还原才是后续加固方案的事实基础。具体排查时优先关注以下可疑特征一个Agent在短时间内连续调用多个工具且调用顺序超出正常的业务逻辑工具调用的参数里带有IP地址、域名、数据库连接串等非常规字段Agent修改了自己“职责范围之外”的内容运营Agent不该去改DNS配置多个Agent在相近的时间区间内访问了同一份“来源可疑”的文档5.2 Agent安全常见认知误区快问快答这里我把平时团队内部讨论最多的几个问题整理出来做成速查表常见问题直接回答背后的逻辑给Agent加更严格的系统提示词能防注入吗不能提示词只是“建议”不是“硬隔离”攻击者可以通过上下文注入绕过用私有化大模型部署安全性会提升吗会提升但有限私有化解决的是数据外泄风险解决不了Agent的权限滥用风险让Agent的所有操作都需要人工审批是不是最安全是但不现实丧失Agent自动化意义的方案不具可落地性应聚焦在“高危操作审批”给Agent设置“禁止作恶”的道德准则有用吗有一点但很弱道德准则是叠加在“指令跟随”之上的攻击者可以用更强指令覆盖它Agent安全是不是主要靠杀毒软件不是Agent的安全核心在框架设计、权限模型和审计机制杀毒软件只管终端Agent系统要不要定期做安全演练必须要我这次的复盘本身就是因为客户做了一次红蓝对抗演练才暴露隐患这张表背后其实只有一条核心逻辑AI Agent的安全是工程问题不是“模型素质问题”。把所有安全诉求都寄托在模型层面就像指望所有员工都靠道德自律不犯错——偶尔管用但无法依赖。5.3 Agent开发者自查清单最后给正在开发Agent系统的团队一份自查清单我每次做安全评审基本都会过一遍这份东西你的Agent能够调用哪些工具工具列表有没有全量盘点每个工具是否按“读”“写”“执行”做了动作级权限细分高危操作是否有人工审批审批人是不是真人Agent之间的通信消息有没有“来源标签”和“可信度评分”外部输入的内容用户消息、上传文档、网页内容和内部数据是否做了隔离Agent的长期记忆写入是否有过滤机制Agent的调用日志是否记录了完整的Prompt快照和决策上下文你能否在出事之后24小时内完整还原Agent的任意一次行为轨迹Agent是否具备“急停”能力——在检测到异常后立即切断所有工具调用你有没有针对Agent系统做过红蓝演练或攻击模拟如果上面任何一条你的答案是“没有”或“不清楚”那我建议你把这篇复盘当成一次预警尽快找时间补上缺口。6. 写在最后的一点体会我把这个案例复盘完最深的体感是AI Agent的“权限失控”其实不是新问题它是经典安全问题的“AI化重演”。二十年前的网页劫持、十年前的勒索软件、今天的Agent抱团失控底层逻辑都是攻击者在找系统设计的薄弱环节。只是Agent系统把这个薄弱环节放大了一个数量级——因为Agent的自主行动能力让攻击链自动运转不再需要攻击者全程干预。我甚至觉得未来两三年内Agent安全的核心矛盾会集中在三件事上最小权限能不能真正落地到每一个工具动作、Agent之间的信任边界能不能划得足够清晰、以及系统能不能在失控发生的第一时间自动刹车。这三件事目前行业里能做得好的团队并不多。最后给还在用“提示词约束模型”来保Agent安全的团队一句掏心窝子的话不要把Agent当成一个会聊天的盒子来保护要把它当成一个拥有执行力的员工来管理。给员工发权限之前你会先想清楚他能干什么、不能干什么、出了事怎么追责。对Agent也应该一样。
