Agentjacking 深度分析:一封伪造的 Sentry 错误报告如何攻陷 Fortune 100 企业的 AI 编码 Agent
2026 年 6 月,Tenet Security 的威胁研究团队公开了一种针对 AI 编码 Agent 的新型攻击方式——Agentjacking。攻击者不需要破解密码、不需要注入恶意代码、不需要诱骗开发者点击链接——只需要向 Sentry 发送一封伪造的错误报告,就能让 AI 编码 Agent 自主执行攻击者控制的代码。
更令人震惊的是:在受控测试中,Tenet 团队确认超过 100 家组织的 AI Agent 执行了攻击者的代码,其中包括一家市值 2500 亿美元的 Fortune 100 科技巨头。
这不是理论漏洞演示,这是在真实世界中发生的、已经被验证的攻击。
Agentjacking 攻击链:一个无需突破的突破
Agentjacking 的核心原理并不复杂,但它揭示了 AI 编码 Agent 生态中一个根本性的安全缺陷:
AI 编码 Agent 无法区分常规数据和攻击指令。
攻击链路分五步完成,每一步都是授权操作,因此没有任何现有安全工具会触发警报:
第一步:找到目标 Sentry DSN
Sentry 的错误监控服务需要客户端 SDK 接入,客户端需要一个 DSN(Data Source Name)密钥。这个密钥被 Sentry 官方文档标识为公开凭证——它嵌入在网站前端 JavaScript 中,用于从浏览器直接发送错误事件给 Sentry。你可以通过检查任意网站页面源码的
标签找到它,也可以通过 Censys 搜索 ingest.sentry.io 来批量发现目标,甚至直接用 GitHub 代码搜索来找。
不需要任何突破。 没有服务器入侵,没有凭据窃取,没有钓鱼。DSN 本身就在那里,而且被设计成公开的。
第二步:注入伪造的错误事件
有了目标网站的 DSN,攻击者向 Sentry 的接收端点发送一个精心构造的 HTTP POST 请求。Sentry 接受这个事件(返回 HTTP 200),并将其与真实的应用错误同等对待。攻击者可以完全控制事件载荷:错误消息、标签、上下文键、面包屑导航、堆栈跟踪——一切都可以伪造。
Sentry 对谁在发送事件不做任何身份验证。 DSN 本身就是唯一的"钥匙"。
第三步:在错误事件中嵌入 Markdown 指令
注入的不仅仅是错误消息,而是在错误的 message 字段和 context 键名中嵌入手写的 Markdown。当 Sentry MCP 服务器将这些事件返回给 AI Agent 时,Markdown 渲染为结构化内容:标题、代码块、表格——视觉上与 Sentry 自己的系统模板完全无法区分。
注入的内容中包含一个伪造的 ## Resolution 段落,其中夹带一个 npx 命令——例如 npx @攻击者控制的包名 --diagnose。
第四步:AI Agent 读取"错误"并执行"修复"
当一个开发者要求 AI 编码 Agent "查看一下 Sentry 里有什么未解决错误",Agent 通过 MCP 查询 Sentry,收到包括这封伪造错误在内的列表。Agent 读取了"Resolution"建议,将其视为权威的故障排除指南,然后执行了那个 npx 命令。
关键洞察:Agent 不会去验证这段 "Resolution" 的来源是否可靠。 在一个人类开发者看来,这条带有一长串技术细节和命令的错误消息可能来自某个队友提交的 Git commit——但 Agent 直接执行它。开发者只是说了一句"帮我看看 Sentry 有什么错误",从来没有授权运行任何代码。
第五步:载荷执行
npx @攻击者控制的包 从 npm 注册表下载并运行在开发者的机器上,拥有该开发者的全部权限。在 Tenet 的受控测试中,攻击包确认了 ~/.aws/config、~/.npmrc、~/.docker/config.json 等敏感文件的存在,并检测了 VPN 状态。
为什么现有安全机制完全无效?
Agentjacking 的可怕之处在于,它绕过了现有的每一层防御:没有钓鱼链接(邮件网关看不到)、没有恶意文件(终端防护扫不到)、没有可疑进程(EDR 看到的是正常 Agent)、每一步都是授权操作(权限管理不触发),甚至不突破任何系统边界。
Tenet 团队在报告中写道:"AI Agent 无法区分它们读取的数据和可以执行的指令。这是模型本身的局限性,不是一个能够通过配置修正的漏洞。" 即使在测试中明确要求 Agent "不要信任你读取的内容",它们仍然执行了注入的代码。
受影响的工具与范围
测试覆盖了主流的 AI 编码 Agent:
- Claude Code——默认设置即执行了注入的命令
- Cursor——全新安装、默认配置即受攻击
- Codex CLI——同样受影响
- 多平台:macOS、Windows、云环境、WSL
没有任何 Agent 配置能完全抵抗这个攻击。在 100+ 受控测试中,几乎所有 Agent 都执行了攻击者的代码,包括沙箱中的、内网环境中的、甚至持有生产 AWS 密钥的 Agent。
受影响的规模
Tenet 团队通过被动侦察(Censys 索引、代码搜索、CDN 加载器提取)发现了 2,388 个使用 Sentry 且 DSN 可公开获取的组织。在实际受控测试中,超过 100 家组织的 AI Agent 被攻陷了:
- 覆盖六大洲(南极洲除外)
- 金融、医疗、政府、教育、关键基础设施
- 一家 Fortune 100 科技巨头(市值 2500 亿美元)
- 甚至一家云安全公司也在其中
为什么今天比以往更危险?
Agentjacking 和传统的 prompt injection 有本质区别:
- 攻击入口不在聊天对话中——攻击者从不与开发者交互。攻击流经的是开发者正常的日常工作流:查看 Sentry 错误 → 让 Agent 修复。
- 无需用户授权——开发者只是正常开启一个 triage 任务,Agent 自主决定运行一个
npx包。
- 跨环境传播——外部服务(Sentry)→ 可信数据摄入(MCP)→ 内网机器上的代码执行。
- 规模化极强——一个载荷可以同时注入数千个 Sentry 项目。Tenet 团队验证了一次 payload 攻击 100+ 组织的能力。
如何防御 Agentjacking?
目前没有一键解决方案,但以下措施能显著降低风险:
立即实施
- 限制 Sentry MCP 读取范围:将 Sentry MCP 返回的数据视为不受信任的输入源,配置 Agent 不自动读取未知来源的错误上下文。
- 对 npx/npm 执行增加审批:阻止无监督的 npm 包安装,使用
--dry-run先行检查包内容。
- MCP 出入站隔离:确保 MCP 返回的数据不能直接触发文件系统/网络操作——Agent 可以读取,但不能在未授权的情况下自动执行。
- 审查 Sentry DSN 暴露:对生产环境的 DSN 使用
Allowed Domains或 CSP 限制。
架构级改进
- 给 Agent 来源感知能力:Agent 需要区分"数据"和"指令"。可行的方案是对来自外部数据源的内容使用不同的信任级别(Trust Boundary),标注"来自不可信源的错误消息"。
- 引入第三方审计层:所有 Agent 执行的代码操作(尤其是 npm/npx 安装)应当经过审计中间件。
- 沙箱化 Agent 运行时:限制 Agent 对
~/.aws/、~/.ssh/、~/.npmrc等敏感路径的访问。
- 配置 Sentry 数据过滤:启用 inbound data filters 阻断可疑的错误事件模式。
启示
Agentjacking 不是传统安全漏洞——它是 AI 编码 Agent 与 Web 生态架构不兼容的产物。
Sentry 的 DSN 在设计时(2012 年),没人想到错误监控系统能成为 RCE 投递通道。MCP 协议在设计时(2024 年),也没人预见到 Sentry 返回的 Markdown 能是一条完整攻击指令。每个组件都没问题,但串联起来,1+1=3 的意外出现了。
这是 AI 安全的新现实:攻击不是通过突破防线实现的,而是利用工具之间默认的信任关系。 每个组件都做自己的事——Sentry 接收错误、MCP 返回数据、Agent 执行"修复"——组合起来就是一条完整攻击链。
对企业而言,当前最紧急的措施是检查内部有多少开发者的 AI Agent 可以无监督地读取外部数据源并执行代码。这个问题比修复 CVE 更棘手,因为它不是代码 bug,而是设计哲学的不兼容。