一句话毒倒整个舰队，AI Agent学会 lateral movement

没有漏洞利用代码，没有凭据窃取，甚至没有一行恶意程序——攻击者只是在一次对话里发出一句 prompt，下一刻，一家企业的整个 AI Agent 集群就可能易主。AWS Bedrock AgentCore 上被披露并已修复的 AgentCorruption 漏洞，把安全研究者担忧多年的最坏叙事变成了工程事实。它改变的不是某个产品的问题清单，而是行业对 AI Agent 威胁模型的默认假设：攻击的单位，从一台系统降格为一次对话；影响的单位，从一次对话升级为整个舰队。

🕳️ 一句话、一支舰队：这不是又一个 Agent 漏洞

先把事实摆清楚。

漏洞位于 AWS 的 Agent 平台 Bedrock AgentCore——这是 AWS 面向企业构建、部署与运行 Agent 的托管基础设施，包含 Runtime、Memory、Code Interpreter、Identity 等组件。研究者给这个漏洞起了一个极具暗示性的名字：AgentCorruption。不是 Breach，不是 Escape，而是 Corruption，腐败、污染。

攻击场景按披露描述几乎极简：攻击者以一个 AI 聊天机器人为入口，发出一句精心构造的 prompt；若漏洞未被修复，爆炸半径将不止于这一次对话——整个组织的 Agent 舰队都可能被接管。

要理解这有多反常，不妨对照传统入侵的成本清单：侦察踩点、寻找入口、利用漏洞拿到立足点、提权、横向移动、抵达目标——每一步都是门槛，每一步都可能留下痕迹。而 AgentCorruption 把这条链压缩成一句话：不需要特权，不需要漏洞利用代码，输入内容是一段在任何内容审计系统看来都不异常的自然语言。

攻击成本与爆炸半径的极端不对称，才是这个漏洞的本质。过去我们说攻击者只需成功一次、防守方必须次次成功，现在这句话有了更残酷的版本：攻击者只需说一句话。

产业判断：这个漏洞的行业意义不在于 AWS 的问题有多深，而在于它标志着一类新攻击的成熟——Agent 舰队开始被攻击者当作一个整体来对待，而不是一堆互不相干的会话。所有基于单次会话假设的防御，都需要重新算一遍账。

🧬 Corruption 不是入侵，是污染

真正危险的漏洞，从来不是撬开门锁，而是污染水源。

🔍 从披露报告还原的攻击链看，这个漏洞的宿主是 AgentCore 的 Code Interpreter 组件。Code Interpreter 为 Agent 提供沙箱化的代码执行环境，本该是每次会话各自独立、用完即弃。但披露研究显示，攻击者可以通过一句构造好的 prompt，诱导当前会话中的 Agent 在执行环境里持久化恶意内容——恶意载荷留在了本应一次性的沙箱环境里，而后续会话会复用这份被污染的环境。

于是传播链条成立了：第一次会话被注入污染源 → 污染被写入共享的执行环境 → 此后任何调用同一环境的 Agent 会话，都会在不知不觉中执行攻击者的代码。单个 Agent 被劫持是行业反复演练过的老问题；而在这里，污染的载体不是某次对话的上下文，而是平台层面的共享执行环境——这正是它被命名为 Corruption 而非 Breach 的原因。

Corruption 这个词用得很准。攻击者拿到的不是传统意义上的 shell，而是把恶意状态写进了全舰队都会读取的地方。从此每个 Agent 既是受害者也是载体，Agent 之间为协作而设计的共享基础设施，成了攻击传播的高速公路。这更像生物感染模型，而不是入侵模型：沦陷的不是个体，而是种群共处的环境。

这正是 AI 原生架构的典型症候。为了开发效率与体验，平台方把记忆、工具、上下文、身份收敛成共享基础设施；而分布式系统史上每一次共享组件的收敛，都伴随同一课的重新学习：便利性上去，爆炸半径也跟着上去。从共享库到软件供应链事件，从容器逃逸到集群接管，剧本没变过，这次只是轮到 Agent 舰队。

产业判断：对平台方，隔离不能再是优化项，它必须是与功能同级的一等公民；对企业，评估任何 Agent 平台时，第一个问题不该是它能做什么，而是一台 Agent 被劫持后，损失止步于哪里。

🔄 提示注入是序章，舰队横向移动才是正片

回看过去两年行业对 AI 安全的讨论，大部分围绕提示词注入（prompt injection）展开：简历里藏一行小字、邮件里埋一句话，处理该任务的 Agent 就可能泄露数据、执行错误动作。OWASP 的 LLM 应用风险清单长期把 prompt injection 列在首位，各家红蓝队也年年演练这些场景。

但那个阶段的行业默认假设，是会话级隔离：一次对话出问题，损失边界就是这次对话。输入过滤、输出审查、人工复核——防御武库的大部分弹药，都建立在单次会话这个假设上。

AgentCorruption 恰恰击穿了这个假设。

产业判断：从影响一次会话到接管一支舰队，这不是量变，而是质变——Agent 威胁从应用安全问题，升级为基础设施安全问题。防御基线必须整体上移：过去防的是一个 Agent 说了什么、做了什么，未来防的是 Agent 之间是否隔离、共享了什么状态、传播路径是否可控。就像终端时代从单机杀毒走到 EDR，Agent 时代需要舰队级的态势感知。

☁️ 平台把补丁打了，行业的功课才刚开始

好消息是漏洞已修复；微妙的是，修复过程中用户可能什么都没做。

这是云原生漏洞管理的现实：AgentCorruption 位于 AWS 托管平台之上，修复在服务端完成。对使用 Bedrock AgentCore 的客户来说，不需要重启，不需要升级——这种静默，和本地部署软件打补丁的体验完全不同。披露节奏上，研究团队选择了负责任的协调披露：先向 AWS 报告，待 AWS 完成服务端修复、确认不影响现网客户后，才公开技术细节。这也是为什么公开资料中看不到可直接复现的利用细节。

但硬币的另一面同样真实：从漏洞被发现到厂商修复的窗口期内，客户既无感知也无抓手。你甚至不知道自己的 Agent 舰队在那段时间处于可被攻击的状态，更谈不上评估是否已被利用。责任共担模型在这一层变得模糊——平台负责基础设施，但爆炸半径的后果，最终由把业务跑在上面的企业承担。

所以下一层竞争，会发生在 Agent 平台的安全能力上。AgentCorruption 已经证明：跨会话、跨 Agent 的隔离，必须从工程优化项升级为平台的设计目标。这个漏洞，只是把台面下的竞赛摆到了台面上。

产业判断：未来一到两年，Agent 安全态势会成为企业选云的标配问题，就像今天我们问可用性、问数据驻留一样。能把一台 Agent 被劫持后的爆炸半径讲清楚的平台，才拿得到下一轮企业订单。

🛡️ 重建爆炸半径：企业现在就该定的三条基线

对防守方来说，AgentCorruption 最好的读法，不是漏洞通告，而是一次免费的架构压力测试。

它测试的是你 Agent 体系的爆炸半径设计：如果一台 Agent 被恶意 prompt 劫持，损失能扩散到多远？如果答案是不知道，或者没有边界，那架构本身就有问题——与是否存在某个具体漏洞无关。因为下一个漏洞，不一定发生在 AWS 身上。

具体到建设，防御体系可以拆成五层，自下而上优先级递进：

三条基线值得优先写进设计文档。第一，把隔离做成硬约束：会话、记忆、工具状态默认严格分离，任何共享都要显式评审——像对待内网防火墙策略一样对待 Agent 间的数据流。第二，给 Agent 发身份、收权限：每个 Agent 独立身份，权限收缩到刚好完成本任务，拒绝任何一个握有全部权限的超级 Agent 设计。第三，为舰队造熔断开关：提前演练一分钟内停掉整支舰队的能力，如果止血手段是逐个提工单，这本身就是 P0 级风险。

⚠️ 顺带表明态度：没必要为此焦虑。漏洞已修复，AWS 的响应并不慢，整个行业该带走的是方法论而非恐慌——不是别用 Agent，而是像对待生产系统一样规模化地用，同时像对待关键基础设施一样设计隔离。

产业判断：真正的分界线，不在有漏洞与没漏洞之间，而在假设已被攻破与假设绝对安全之间。前者还在垒防御，后者已经在透支运气。

小结

AgentCorruption 会被写进 AI 安全的时间线，不是因为技术多精巧，而是因为它第一次让行业看清：Agent 的威胁模型，已经从一次会话迁移到一支舰队。

回看完整的攻击链，会发现它的每一环都不新鲜：prompt 注入是老问题，共享执行环境是老架构，持久化载荷是老手法。新鲜的只是三者在一个托管 Agent 平台上被串联起来，把单点污染放大为舰队级沦陷。这也意味着，防御同样不需要发明新武器——把隔离从优化项变成硬约束，把身份从可选项变成默认项，把熔断从预案变成演练，就足以让下一次同类攻击停在第零步。

漏洞补上了，但同样的架构模式——共享记忆、共享工具、互信协作——正在每一个 Agent 平台上被复制。对厂商，隔离是设计问题；对企业，爆炸半径是治理问题。谁先完成这轮重建，谁就握住 Agent 时代的主动权。