Shopify 详解 Cyber Chaos Monkey：如何利用 AI 智能体主动探测生产环境安全漏洞

保护商家与买家的数据，是我们始终放在首位的事。为此，我们不断重构自身的安全体系，果断淘汰跟不上威胁演进的旧机制，并借助 AI 成倍提升安全防护的深度与覆盖面。

2026 年初，我们曾介绍过利用智能体发现并修复软件漏洞的方法。此后，我们又开发了一款基于智能体的漏洞挖掘系统，直接在生产环境中实时运行。我们为它提供真实的访问凭证，以及关于系统的所有已知信息（如历史漏洞、基础设施架构和源代码），并借助当前能力最强的网络安全模型来引导它，寻找绕过现有防护的全新路径。

截至目前，这些智能体已经执行了数万次实战攻防演练，发现并处理了数十个高价值风险隐患，且未引发任何停机或安全事故。我们将这套系统命名为 Cyber Chaos Monkey（简称 CCM）。以下是它的构建过程。

赶在攻击者之前发现漏洞

放眼整个行业，随着前沿模型将漏洞挖掘成本降至趋近于零，漏洞报告呈现爆发式增长。

这一趋势在 Shopify 的漏洞赏金计划中表现得尤为明显：自 2024 年以来，收到的报告数量激增了近 300%。面对如此海量的报告，团队在审核、验证和跟进处理上的运营压力陡增。

我们的核心判断是：前沿模型虽然赋予了攻击者前所未有的能力，但“水涨船高”，防御方同样可以借力。我们对自己内部软件系统拥有巨大的信息优势，借助这种信息不对称与前沿模型，我们能够：(1) 先于外界发现系统中绝大多数危害最严重的安全隐患；(2) 极大拉高攻击者挖掘残留漏洞的成本门槛。既然攻击者的目标是生产系统，我们的测试就必须同样针对生产环境。而构建 CCM 的初衷，正是为了在测试的同时，完全不影响系统可用性，也不让商家数据承担风险。

什么是 CCM？

从概念上看，CCM 相当于一个基于知识图谱工程构建的智能体漏洞研究员，拥有访问源代码、威胁情报、历史报告以及基础设施与部署记录的权限。就像人类白帽黑客一样，CCM 能够利用真实的测试店铺和测试组织，直接调用 Shopify 的生产环境基础设施。

这一名称是在向 Chaos Monkey（混沌猴）致敬——Netflix 曾于 2011 年推出该工具，通过在生产环境中随机关闭实例，确保其服务在迁移至 AWS 期间能够承受真实故障而不影响客户体验。这一实践后来发展成为混沌工程学科，专门通过在生产系统上进行实验，来提升系统在恶劣条件下的韧性信心。Tobi 也经常在 Shopify 内部释放各种“混沌猴”，比如每年定期清空团队日历上的所有周期性会议。

CCM 则将混沌工程的思想延伸到了安全领域：通过主动、有意识地攻击自己的生产系统，赶在漏洞波及商家和买家之前将其找出。

在架构上，我们将该系统划分为两大基础组件：发现模块（Discovery）与沙箱模块（Sandbox）。

每次 CCM 任务都是对潜在漏洞的深入排查，或是为了达成某个具体的安全目标。触发任务的起点多种多样：可以来自人类安全工程师的构想、假设或报告，也能来自其他上游安全智能体，或是 Discovery 工具自身反馈循环的产物。这些目标有的很具体（比如“在其他模块排查与某份漏洞赏金报告类似的风险”），有的则较为宽泛（比如“在 Shopify 管理后台实现远程代码执行 RCE”）。整个流程分为六个步骤：

• 步骤 1：将这些构想作为输入提交给 Discovery。
• 步骤 2：利用最新的网络安全模型进一步细化构想，并找出代码或配置中可能引发漏洞的位置。
• 步骤 3：Discovery 一旦锁定有价值的线索，就会将描述潜在问题的结构化数据发送到沙箱，由我们的智能体尝试利用该漏洞。
• 步骤 4：开展实操测试，例如安装依赖包和构建模糊测试工具（fuzzer）。任何攻防安全工程师都不会对此感到意外：我们发现，智能体在沙箱中最强大的基础操作之一，就是直接向 Shopify 发起实时请求，随后查阅生产日志查看请求的处理过程，再对照源代码进行比对，如此反复迭代。
• 步骤 5：沙箱智能体完成测试后，会将所有发现整理成报告，反向同步给 Discovery 并向上汇报。
• 步骤 6：Discovery 分析测试结果，并执行反馈循环，这可能会进一步触发新的任务。

我们如何确保 CCM 的安全性？

近期发生的多起事件中，用于安全测试的 AI 智能体触碰了绝不该涉足的系统，这充分表明风险隔离必须从一开始就融入架构设计。我们设计了一套分层的安全控制机制，既能防范技术层面的风险（如凭证泄露、网络逃逸），也能应对根本性的对齐风险（例如智能体未遵守既定交战规则）。

技术控制机制

CCM 属于标准的容器化工作负载，我们在整个架构中贯彻了最佳实践级别的安全控制措施。每个 CCM 任务都会对应启动一个 Kubernetes Job。该 Job 的 Pod 中运行着若干容器，应用控制器则是一个基于状态机的编排器。其余任务均交由 Sidecar 容器处理（例如维护任务和负责攻击测试的智能体本身）。

• 容器化与最小特权原则：负责攻击测试的智能体运行在未赋予任何提权权限的容器中。注入给智能体的唯一数据，是一组临时的 Shopify 凭据（如会话 Cookie 和 CSRF 令牌）；编排器会在该智能体启动前，将这组凭据写入共享卷。智能体只能读取、无法修改这些凭据。容器基于 Debian 构建，预装了大量开发软件包和安全测试工具。
• 凭证代理：智能体在调用我们的“知识”服务或模型供应商接口时，会在发往凭证代理的请求中附带一个占位符请求头。凭证代理会将占位符替换为真实的凭证，并通过出站代理将请求发送出去。系统严格限制了哪些请求头可以注入到哪些域名，且凭据本身会定期轮换。
• 出站流量管控：我们的出站代理本质上是基于 nginx 构建的白名单系统，也是唯一能够访问 VPC 外部的 pod。我们仅放行 Shopify 生产环境域名、内部知识服务、模型提供商，以及少数指定的包管理器（例如我们自己的包代理服务）。

管控对齐风险

我们主要通过两种方式来管控对齐风险。首先，我们为每个智能体都设定了一套严格的交战规则（Rules of Engagement，简称 RoE）。这些规则允许智能体随意尝试攻击目标，但在漏洞利用成功后能做什么则设置了硬性限制，例如禁止横向移动至其他系统，或禁止留存后门权限。

其次，我们并不认为执行智能体在整个任务期间都能始终保持对齐。因此，我们引入了“双人确认制”（Two-Person Integrity，简称 TPI）——即必须由第三方审查执行者的操作，确认其不会带来安全风险。TPI 常见于政府机构保护绝密信息，或用于高风险红队实战对抗中。在 CCM 中，我们创新性地将这一机制落地：引入第二个智能体，使用与执行攻击的智能体截然不同的提示词和对齐策略。

具体实践中，我们会把攻击智能体的会话日志实时推流给另一个独立对齐的智能体（即采用不同的模型）。一旦该智能体发现不符合 RoE 规范的高危行为，就会通过工具调用立刻终止进攻智能体的运行。“裁判”智能体能读取“执行者”会话中的全部事件 ，包括回复内容、思考过程、工具调用及其返回结果。

正如上图所示，我们的系统设计遵循强制的显式正向控制原则：只要“裁判”超时、崩溃或无法裁定“执行者”发出的消息，任务便会立刻终止。实现这一 TPI 机制的编排器是 pod 的主应用容器，“执行者”和“裁判”则作为原生 sidecar 容器在同一 pod 内运行。编排器会与“执行者”和“裁判”同时维持心跳信号。一旦其中任何一个容器宕机，编排器容器就会退出。而 pod 的重启策略禁止编排器重启，因此 Kubernetes 会销毁两个 sidecar 容器，整个作业随即结束。 

将所有组件放在同一个 pod 内（同时保持相互隔离），可以降低网络分区打断“编排器”、“执行者”与“裁判”之间通信的风险。同样，Kubernetes 触发的任何驱逐操作都会终止 pod 内的所有容器，因此驱逐绝不可能导致“执行”容器在没有配套“裁判”的情况下独自运行，从而确保了 TPI 机制万无一失。

发挥自身优势

CCM 本质上是对非对称优势的一次押注。前沿模型确实降低了所有人挖掘漏洞的门槛，但我们对自己系统的了解，永远是任何外部攻击者无法企及的。

在拥有这种信息优势的前提下，使用同等级别的模型能让我们抢先发现影响最严重的问题。这也大幅推高了外部人员达成同样目标的成本——因为攻击者必须与这些全天候待命、且一开始就掌握全局信息的智能体展开竞争。