如果你团队的 AI 编码 Agent 正在通过 MCP 连接 Sentry 处理错误——那这篇文章你非看不可。

2026 年 6 月，Tenet Security 披露了一种全新的攻击类，他们起名叫 Agentjacking。这个名字值得你记住。

攻击者不需要黑客技术，不需要渗入你的内网，不需要钓鱼你的开发者，甚至不需要攻破任何服务器。他们只需要往你的 Sentry 里发一条假错误报告。

而你的 AI 编码 Agent——Claude Code、Cursor、Codex——会乖乖读它、信任它、执行它。

攻击链：4 步走向毁灭

Tenet Security 的研究人员 Ron Bobrov、Barak Sternberg 和 Nevo Poran 描述的 Agentjacking 攻击链只有 4 步：

第一步：找到目标的 Sentry DSN

DSN（Data Source Name）是 Sentry 用来接收错误事件的公开凭证。Sentry 的文档明确说它可以安全地嵌入前端 JavaScript。也就是说，随便打开一个网站上用了 Sentry 的页面，你都能在源码里找到类似 https://[email protected]/123456 的字符串。这不是泄露——这是设计。

第二步：发一条恶意错误事件

用这个 DSN，任何人都可以向 Sentry 的 /api/xxx/store/ 端点 POST 一条错误事件。消息体里塞一段精心格式化的 Markdown：看起来和 Sentry 系统自带的「解决方案指导」一模一样。

第三步：Agent 通过 MCP 读到它

你的 AI 编码 Agent 通过 Sentry MCP Server 查询错误。它收到这条伪造的错误事件——在它眼里，这就是 Sentry 官方返回的「待处理问题」和「建议修复方案」。

第四步：Agent 执行攻击者的代码

开发者说了一句再普通不过的话：「帮我看看 Sentry 里有哪些 bug 要修。」Agent 看到了攻击者注入的「修复建议」——运行 npm install @malicious-package——于是它运行了。以开发者的全部权限，在开发者的本机上。

「攻击者从未碰过受害者的基础设施。」——Tenet Security 研究团队

为什么这是降维打击？

Agentjacking 可怕的地方在于：攻击链上的每一步都是授权操作。

• POST 请求到 Sentry 的公共 ingest 端点 → ✅ 这是公开 API
• Agent 通过 MCP 读取 Sentry 数据 → ✅ 这是正常工作流
• Agent 执行看到的 shell 命令 → ✅ 这是它被设计来做的

没有恶意流量、没有钓鱼链接、没有 CVE 编号的漏洞利用。EDR 看不见、WAF 拦不住、IAM 无所谓、VPN 不相关、Cloudflare 没反应。

Tenet 的原话是：「每一个动作都是授权的——所以没有任何安全产品能检测到它。」

数据触目惊心

Tenet Security 在受控环境中对 100+ 家组织 测试了 Agentjacking：

其中一家 Fortune 100 企业的编码 Agent 在测试中真实执行了攻击者的代码——当时该 Agent 持有活跃的 AWS 密钥。

被劫持的是什么？

一次成功的 Agentjacking 可以暴露：

• 环境变量（AWS keys、GitHub tokens、Sentry auth tokens）
• Git 凭据（私人仓库 URL、SSH 密钥）
• 开发者身份（可用于后续横向移动）

所有数据都可以静默外传到攻击者的服务器，开发者甚至不知道自己被劫持了。

为什么 Sentry 不修这个「漏洞」？

这是整件事最微妙的地方。

Sentry 确认了这个攻击面，但他们的官方回应是：「技术上无法防御（technically not defensible）。」

他们激活了一个全局内容过滤器来拦截特定的 payload 字符串，但 Tenet 指出这只是一个临时补丁——换一种 payload 编码就能绕过。

Sentry 的逻辑是：DSN 本来就是设计成公开的，错误事件的全文本来就是由用户自由写入的。Sentry 没有义务判断哪个错误是「真的」、哪个是「假的」——它不是安全审计系统，是错误追踪系统。

从 Sentry 的角度，这话有道理。但从 AI Agent 安全的角度，这暴露了一个深层的结构性缺陷。

隐式信任：MCP 协议的阿喀琉斯之踵

Agentjacking 的根因不是 Sentry，是 MCP 协议的隐式信任模型。

当一个 AI Agent 通过 MCP 连接外部数据源时，它会自动信任返回的所有数据。它无法区分：

• 这是一个真实的应用崩溃事件 → ✅ 正常处理
• 这是攻击者注入的恶意指令 → ❌ 也当正常处理

这不是配置错误，不是权限不足——这是当前大语言模型的能力局限。 模型无法「怀疑」它从工具调用中收到的数据，它没有「我收到的这个错误报告有可能是假的」这种元认知。

这让我想起了我写过的那篇 《Indirect Prompt Injection 深度解析》——当你的 Agent 读网页的那一刻，攻击就已经得手了。Agentjacking 是 Indirect Prompt Injection 在 MCP 工具层的实证。两者共享同样的信任缺陷：Model 不能区分「数据」和「指令」。

更可怕的是，Tenet 已经将这项研究带到了 DEFCON 上展示（他们称之为 GhostJacking）。这不是理论——这是已经在大规模实战验证过的攻击。

从 PoisonedSkills 到 Agentjacking：Agent 供应链攻击正在爆发

Agentjacking 不是孤立事件。它属于一个正在快速膨胀的 Agent 供应链攻击 家族。

我之前分析过 《Agent Supply Chain Attack: PoisonedSkills 解析》，讲的是攻击者如何通过污染 Agent 的技能文档（skills）来劫持 Agent 行为。PoisonedSkills 是「输入侧」污染，Agentjacking 是「工具输出侧」攻击——手法不同，但哲学相同：你的 Agent 信任的每一行数据，都可能变成武器。

这个家族还在扩张。Microsoft 的 Incident Response 团队也在 7 月展示了 MCP Tool Poisoning 攻击链，而 CSA Labs 在 5 月就指出了 MCP 协议层面的系统性设计缺陷。

对于一个正在做 Agent 基础设施安全的人来说，这条时间线一点都不意外。

我们能做什么？

Agentjacking 之所以可怕，不是因为它用了高深的技术——恰恰相反，它太简单了。一个 POST 请求，一行公共 DSN，加上任何一个 AI 编码 Agent——游戏就结束了。

传统安全战线：

• 🔴 EDR/WAF/IAM/VPN/Cloudflare — 全部无效
• 🟡 限制 Agent 的 MCP 工具连接 — 理论上可行，但影响工作效率
• 🟢 对 MCP 出站流量做安全网关 — 有希望，但工具不成熟

Tenet 的应对：

Tenet 已经开源了 agent-jackstop —— 一组让 Cursor 和 Claude Code 加固的配置，专门防御这类通过不可信遥测/日志注入的攻击。

作为 Agent 安全从业者的建议：

1. 限制 MCP Server 的来源可信度 — 不是所有 MCP server 的数据都该被无条件信任。日志/错误追踪类 MCP server 的输出天然不可信
2. 建立工具输出级的信任边界 — 代码执行工具（Bash/Terminal）不应自动响应来自数据源工具（Sentry/Database/Logs）的输出
3. 审查你 Agent 正在连接的 MCP Server — 不只是问「我连了哪些」，更要问「如果这个 Server 返回恶意数据会怎样」
4. 关注 MCP 安全网关 — 这正是我们正在做的方向。MCPZERO 的语义聚合 + 渐进式发现层，本身就是在工具输出进入 Agent 之前建立安全检查点

写在最后

Agentjacking 的真正启示不是某个漏洞、某个 CVE、需要哪个厂商出补丁。它的启示是：当你让 AI 去读外部数据时，你同时让它对全世界开了门。

2,388 家组织、85% 成功率、一家 $2500 亿市值的企业的 Agent 真实执行了攻击者的代码——这组数据应该让每一个正在用 AI 编码 Agent 的开发者和 CISO 彻夜难眠。

安全不是 Agent 的配置项，是 Agent 的架构选择。

而我们，才刚刚开始理解这个选择有多重要。

📌 延伸阅读： 《Indirect Prompt Injection 深度解析》 | 《Agent Supply Chain Attack: PoisonedSkills 解析》