Shopify 公开 Cyber Chaos Monkey：让带着内部知识的 AI Agent 在生产环境做受控攻击，再派第二个 Agent 当裁判

@ShopifyEng 发布的这篇「Cyber Chaos Monkey: Staying ahead of security threats with AI agents」介绍的是一套内部系统 Cyber Chaos Monkey（CCM）：把攻防模型、源码、基础设施知识和真实测试店铺的凭证交给 AI Agent，让它们在生产环境里寻找绕过防护的新办法。

名字致敬 Netflix 2011 年推出的 Chaos Monkey，思路是把混沌工程（主动制造故障来检验系统韧性）用到安全上。7 月 29 日 Zack Deveau 发过一篇文章，讲在代码和测试阶段发现并修复漏洞；CCM 则把找漏洞这件事搬到了线上。
https://shopify.engineering/cyber-chaos-monkey

为什么要在生产环境里测

Shopify 认为，前沿模型让发现漏洞的成本越来越低，全行业收到的漏洞报告都在猛增。Shopify 说，他们的漏洞赏金计划自 2024 年以来报告量增加了将近 300%。

他们的判断是，同样的模型也能帮防守方。Shopify 比外部研究者更了解自己的系统，应该抢先找到影响最大的问题，让外人再挖到漏洞的难度更高。攻击者瞄准的是生产环境，测试也就必须对着生产环境做，前提是不能影响服务可用性，也不能危及商家数据。

先定方向，再动手

CCM 的角色像一名漏洞赏金研究员，手里有源码、威胁情报、历史漏洞报告和部署记录，还能用真实的测试店铺调用线上接口。系统分成两部分：发现模块和沙箱。任务可以来自安全工程师、上游的其他安全 Agent，也可以来自发现模块自己的反馈。

一个想法先进入发现模块，由最新的攻防模型缩小范围，有价值的线索再交给沙箱。沙箱里的 Agent 尝试实际利用漏洞，Shopify 最看重的做法是向线上系统发真实请求，再对照生产日志和源码不断调整。测试结束后生成报告送回发现模块，可能由此引出新的任务。

光隔离不够，还要有人盯着

文章提到，近来已经出现过安全测试中的 AI Agent 触碰到本不该访问的系统，所以安全约束必须从一开始就设计进去。

隔离做了好几层：
· 每个任务对应一个独立的 Kubernetes Job。
· 进攻 Agent 运行在没有提权的容器里，只能读到编排器写入的临时凭证，比如会话 cookie 和 CSRF 令牌。
· 对外请求先经过凭证代理注入密钥，再经过出口白名单，只放行生产域名、内部知识服务、模型提供方和指定的软件包代理。

每个 Agent 还有一份行动准则：对目标可以尽力尝试攻击，但一旦得手，不能转去攻击其他系统，也不能保留访问权限。

Shopify 不单独信任执行攻击的 Agent，又加了一个“裁判” Agent，用不同的提示、不同的立场和不同的模型，实时读执行方的日志。一发现危险行为就立即终止任务；裁判超时、崩溃或给不出判断，任务也会结束。编排器和两个 Agent 之间保持心跳，任何一方退出，整个 Pod 都会被销毁。

据 Shopify 说，这些 Agent 已经执行了上万次进攻任务，发现并处理了几十个有实际影响的问题，没有造成停机或安全事故。