三家大厂沉默45天：一个GitHub评论框如何劫持AI代理

2026年4月15日，安全研究员管奥楠（Aonan Guan）公开了一件事：他用同一套攻击手法，先后拿下了Anthropic、Google、GitHub三家的AI代理工具。三家公司都付了漏洞赏金，但没有任何一家申请CVE编号、发布安全公告，或通知仍在使用旧版本的用户。

攻击名称叫"comment and control"——故意戏仿军事术语"command and control"（指挥与控制）。这个名字本身就在说：攻击者不需要服务器，不需要入侵基础设施，只需要在GitHub的评论框里写几句话，就能让AI代理变成远程控制的傀儡。

攻击是怎么发生的

管奥楠的攻击路径极其干净。他找到一个AI代理被设计去读取的GitHub内容表面——PR标题、issue描述、代码评论——然后把恶意指令塞进去。

不需要特殊权限，不需要攻破目标系统，不需要外部命令服务器。整个攻击运行在GitHub的正常工作流里。

三家的代理反应不同，但全部中招：

【Anthropic的Claude Code安全审查Action】管奥楠提交了一个PR，直接在标题里注入指令——比如让Claude用Bash工具执行whoami命令，并把输出包装成"安全发现"。Claude执行了注入的命令，把shell输出嵌进JSON响应，然后作为PR评论发布。代理的任务是代码安全审查，结果被变成了远程执行表面。

【Google的Gemini CLI Action】管奥楠在Gemini的合法附加内容后面插入了一个伪造的"可信内容区块"，用它覆盖Gemini的安全指令。Gemini按照它解析为可信的内容执行了。

【GitHub的Copilot Agent】攻击手法类似，同样通过GitHub原生内容表面完成注入。

关键事实：攻击同时影响了Claude Code、Gemini CLI和Copilot Agent，全部通过GitHub原生基础设施，无需外部攻击服务器。这是AI代理安全模型问题最干净的例证之一——这个问题存在多年，至今基本未解决。

什么是"间接提示注入"

这个攻击类别叫间接提示注入（indirect prompt injection）。恶意指令被嵌入AI代理被设计去读取和信任的内容里——不是用户直接交付，而是藏在文档、issue描述、PR标题、代码评论或代理在任务中解析的任何其他表面。

与直接提示注入（需要访问系统提示）不同，间接注入利用的是代理的读取表面：代理摄入并视为指令上下文的任何数据。

在GitHub Actions的语境下，攻击表面是整个仓库事件流——PR标题、issue正文、审查评论。这些是代理被构建来消费的内容，也是开发者很少视为安全边界的东西。

代理治理在内容层意味着在代理行动之前拦截和评估内容，而不是在注入指令已经执行之后。

为什么三家公司选择沉默

管奥楠从三家都拿到了漏洞赏金，但没有CVE，没有公告，没有用户通知。这种处理方式在AI安全领域正在成为模式。

传统软件漏洞有成熟的披露流程：申请CVE、发布补丁、通知用户、给升级窗口期。但AI代理的漏洞边界模糊——这是"功能"还是"漏洞"？提示注入利用的是语言模型的核心能力（遵循指令），而非实现缺陷。

更现实的考量：公开披露等于告诉所有攻击者"这里可用"。而AI代理的攻击面每天都在扩张——今天能读PR标题，明天可能读Slack消息、邮件、Jira工单。每新增一个读取表面，就是新的注入通道。

三家的沉默或许还有另一层：Claude Code、Gemini CLI、Copilot Agent都在抢占企业开发者市场。安全公告是竞争劣势。

未解决的结构性问题

这个案例暴露的是代理架构的深层张力。AI代理被设计成自主读取环境、解析意图、执行动作——这正是它们的价值所在，也是它们的脆弱之处。

核心矛盾：代理必须信任某些内容才能完成工作，但任何被信任的内容表面都可能被污染。GitHub的PR标题对代码审查代理是合法输入，对攻击者就是命令注入通道。

现有的缓解方案都不彻底。输入过滤容易被绕过（自然语言的变体无限）。输出验证只能事后发现，无法阻止执行。权限最小化减少损害范围，但不阻止注入本身。

代理治理在内容层的真正挑战是：如何在代理"理解"内容和"执行"动作之间插入可审计的决策点，而不破坏代理的自主性——这本身就是卖点。

这件事为什么重要

管奥楠的攻击不是技术突破，而是概念验证：AI代理的安全模型问题从理论变成了可复现、可量产攻击的现实。

三家公司同时中招，说明这不是某家实现的问题，是代理架构的类别特征。GitHub作为基础设施，其内容表面正在成为AI时代的通用攻击通道——就像十年前的SQL注入，或二十年前的缓冲区溢出。

更深远的影响在企业采用层面。当开发者把Claude Code、Copilot Agent接入私有仓库、内部系统时，他们实际上在把GitHub的评论框变成潜在的远程执行入口。而三家的沉默处理意味着用户无法评估风险——不知道自己用的版本是否脆弱，不知道攻击是否已被利用。

代理AI的安全模型需要重新设计。不是修补提示注入，而是在架构层面区分"信息读取"和"动作执行"，建立可验证的信任边界。但在那之前，每个接入AI代理的GitHub仓库都是未标注的实验场。