一个由GitHub Copilot参与"把关"并判定为安全的代码改动，5天后被一个完全自治的AI安全Agent发现并实际利用，攻进了Snowflake的内部Jira——AI写代码、AI审代码、AI攻代码，第一次在真实生产环境里完成了闭环。
事件回顾
8月17日，云安全公司 Wiz 披露了一起罕见的漏洞事件，主角不是人类黑客，而是两个AI：
一边是 GitHub Copilot Autofix（AI代码审查/自动修复工具），一边是 Wiz 自研的 Red Agent（一个完全自主、无需人工干预的AI安全研究工具）。
事件的完整链条是这样的：
-
Snowflake 的公开仓库
snowflakedb/snowflake-connector-net里有一个 GitHub Actions 工作流jira_issue.yml，它会在任何人提交 issue 时被触发，并把 issue 标题直接插进 shell 脚本执行。攻击者只需在标题里放一个单引号，就能逃逸出字符串、执行任意命令。 -
这个漏洞是 PR #1218 在 6月18日被合并时引入的。关键细节：Copilot Autofix 作为该PR的"共同作者"，检查了这个合并后的代码改动，并判定为"全部通过（all-clear）"，却没有发现这个致命注入点。 GitHub 自己的 Advanced Security 扫描也明确提取了这份工作流文件，同样没有标记任何问题。
-
6月23日，即漏洞上线仅5天后，Wiz 的 Red Agent 在 Snowflake 的 HackerOne 漏洞披露项目里，全自动地完成了发现→利用→评估全流程：它扫描出
jira_issue.yml的脚本注入点，构造了逃逸 payload，通过外带信道窃取了 Snowflake 内部 Jira 的凭证，并验证了该凭证（qa@snowflake.net）确实能读取内部工单系统。 -
最有意思的细节是：Red Agent 第一次尝试用
#注释符做逃逸时，触发了 bash 语法错误，因为注释把命令结尾的括号也吃掉了。它没有停下等人类，而是自主分析错误、把 payload 改成; echo '重新闭合 shell 块，随即成功收到回传。 这是"自治AI安全Agent会自我纠错"的第一次真实公开展示。
Snowflake 在收到披露当天就修复了漏洞、轮换了泄露凭证，并通过审计日志确认 Wiz 是暴露窗口期内唯一的访问者。
为什么重要
这件事同时戳中了AI编程赛道的两个核心命题，而且是一正一反。
反的一面：AI代码审查不是安全网。 Copilot Autofix 的定位就是"自动发现并修复代码漏洞"，但在这个案例里，它不仅没拦下漏洞，反而在"共同作者"的位置上给有漏洞的PR盖了"安全"的章。GitHub Advanced Security 这套成熟的自动化扫描也漏了。这说明：当前AI代码审查的漏检是系统性风险，不是个例——当团队默认"有Copilot把关所以可以放心合代码"时，等于把安全责任外包给了一个会出错、但不会负责的工具。对用AI编码Agent提速的团队，这是一个必须正视的盲区。
正的一面：自治AI安全Agent已经能实战。 Red Agent 从发现、利用、自我纠错到评估爆炸半径，全程无人工介入，且在真实的生产目标上跑通了。这意味着"AI红队"正在从概念变成产品，安全行业的攻防双方都在被AI重写。对安全创业者，这是一条全新的产品线；对普通AI创业者，这意味着"用AI给代码/系统做安全体检"的付费服务会越来越成熟、越来越便宜。
更深的一层：AI攻、AI防、AI审，闭环已经形成。 过去我们讨论AI安全，是"AI会不会被利用"；现在真实案例告诉我们，是"AI在互相攻防"。这个变化的速度，超过了大多数团队的组织准备。
社区反应
HN评论区（148条）的讨论集中在几个点：
一是对"Copilot是共同作者却判了安全"的震惊。不少人指出，Copilot Autofix 的营销话术长期是"帮你修复漏洞"，但这个案例证明它可能"假装检查了、其实没看懂"——"一个连 shell 注入都看不出来的审查工具，被当成安全网来用，比没有审查更危险，因为它制造了虚假的安全感。"
二是对"自治Agent自我纠错"的关注。Red Agent 那个从 # 改成 ; echo ' 的细节被反复引用，有安全研究员评论："这才是真正的Agent——遇到语法错误不是报错退出，而是理解错误、调整策略、继续进攻。"
三是务实的提醒：漏洞的根源是人类写的那个 ${{ github.event.issue.title }} 插值模式，AI只是"没拦住"。有人总结："AI不会消除安全漏洞，只会改变发现漏洞的速度——无论是对攻击者还是防御者。"
对AI创业者的影响
-
别把AI审查当合规护身符。 如果你的团队或产品用了Copilot Autofix、GitHub Advanced Security之类，它们能减少一部分低级错误，但绝不能替代人工安全评审。关键改动（尤其是涉及工作流、凭证、模板注入的部分）必须有真人过目。
-
AI红队是明确的新市场。 Wiz 这类公司已经在把"自治AI安全Agent"产品化。安全赛道会像编码赛道一样经历"AI化"洗牌，提前布局"用AI做安全体检/渗透测试"服务的小团队有机会吃到早期红利。
-
攻击面在扩大。 当"AI编码Agent"大量生产代码、而审查环节跟不上时，AI生成的代码会成为新的攻击面。做B端服务的AI创业者，客户会越来越频繁地问你："你的AI写过多少代码？这些代码谁审过？"提前准备好这个答案。
行动建议
-
立即盘点你项目里所有 GitHub Actions 工作流，重点排查
${{ github.event.* }}、${{ inputs.* }}直接拼进run:脚本的模式——这是本次漏洞的同款根因，改成env:变量传递即可消除。 -
对AI编码Agent产出的PR，执行"信任但验证"：自动审查可以跑，但涉及安全的合并必须人工确认，不要因为"Copilot说all-clear"就一键合入。
-
关注自治安全Agent的进展，把它纳入你的工具雷达——无论你是用它来做内部体检，还是评估把它做成付费服务的机会。