你让AI编程助手修个Bug，它却悄悄把你的AWS密钥、GitHub令牌、.env文件全部打包发给了黑客。

这不是科幻，这是上周刚被披露的真实攻击——名叫Agentjacking。

核心数据：85%的攻击成功率，2388家组织暴露，71家全球Top100万网站受影响——Claude Code、Cursor、Codex全部中招。

一、一个报错信息，怎么就劫持了AI？

攻击原理简单到令人发指，只需要4步：

第一步：找DSN。Sentry是全球最流行的错误监控工具，几乎每个有规模的开发团队都在用。它的DSN（数据源名称）天生就是公开的——写在浏览器前端JS里，谁都能看到。攻击者扫一眼源码，或者用Censys搜一下，就能拿到。

第二步：注入假报错。拿到DSN后，攻击者向Sentry的接口POST一条精心构造的错误事件。这条"报错"里藏了一个## Resolution章节，里面写着类似npx malicious-package的恶意命令。整个过程不需要任何认证。

第三步：AI主动"修Bug"。开发者像往常一样对AI编程助手说"帮我修一下这个Sentry报错"。AI通过MCP协议查询Sentry，读到了攻击者注入的假报错——然后老老实实执行了里面的恶意命令。

第四步：密钥泄露。恶意命令从npm下载攻击者控制的包，自动窃取本地的AWS密钥、GitHub OAuth令牌、Kubernetes服务账户令牌、.env环境变量，再通过HTTPS POST发给攻击者。

整个过程，攻击者不需要入侵任何系统，不需要钓鱼邮件，不需要0day漏洞——只需要往Sentry里扔一条假报错。

二、85%成功率意味着什么？

网络安全公司Tenet Security在受控环境下测试了三款主流AI编程助手——Claude Code、Cursor和Codex，结果显示85%的情况下AI都会乖乖执行恶意命令。

原因在于MCP协议的设计缺陷。MCP（模型上下文协议）默认认为工具返回的数据是"被动上下文"，无法区分合法的Sentry输出和攻击者注入的指令。换句话说，AI分不清"这是Bug修复建议"还是"这是黑客的命令"。

截至6月12日，已确认2388个组织的Sentry DSN可被注入，其中71家属于全球Tranco前100万网站。受影响者包括：估值近2500亿美元的财富500强企业、管理20亿美元资产的托管基础设施提供商、云安全厂商、以及EdTech、HealthTech、FinTech领域的初创公司。

不是第一次了。本月早些时候，一个自我复制蠕虫已通过AI编程工具入侵了微软自己的73个GitHub仓库。AI代理获得的自主权越大，攻击面就越宽。

三、Sentry说"技术上无法防御"

6月3日Tenet Security向Sentry披露了该漏洞，Sentry的回应令人震惊——"技术上无法在平台层面防御"。

理由是：DSN的设计初衷就是公开可写入的凭证，用于浏览器上报错误。Sentry目前只部署了一个针对特定npx payload字符串的内容过滤器——但攻击者只要换个包名、用pip替代npx、对命令做编码，或者换个Markdown注入格式，就能直接绕过。

这意味着结构性修复遥遥无期——Sentry既没有实现认证事件接收，也没有逐事件Shell命令模式校验，更没有对DSN写入操作做IP限速。

四、开发者现在该怎么办？

如果你或你的团队正在使用带Sentry集成的AI编程助手，以下措施请立即执行：

1. 禁用AI编程助手的Sentry MCP集成。这是目前唯一完整的缓解方案。在Sentry实现认证之前，没有其他选择。

2. 轮换所有公开可获取的Sentry DSN。搜一遍GitHub代码和Censys，凡是被搜到的DSN都算暴露，必须立即轮换。新DSN存环境变量，不要写进源码。

3. 所有AI建议的Shell命令，手动确认后再执行。尤其是npx和pip命令，确认包名属于项目已知依赖后再放行。

4. 监控AI助手子进程读取凭证文件的行为。配置EDR告警：一旦AI进程的子进程读取~/.aws/config、~/.npmrc、.env等文件，立即触发告警。

深层思考：Agentjacking揭示了一个更本质的问题——当AI代理被赋予了读取外部数据、执行Shell命令的能力，但无法验证数据来源的可信度时，每一个外部数据源都是一个潜在的攻击入口。这不是Sentry一个产品的问题，而是整个MCP生态的设计盲区。今天劫持的是Sentry的错误报告，明天可能就是GitHub的Issue评论、Jira的工单描述、Slack的消息通知。

AI编程助手正在从"工具"变成"代理"——但安全模型还停留在"工具"时代。这个差距，才是Agentjacking真正要命的。