场景还原一下：你正在用 Claude Code 处理一个 Sentry 里积压的报错。输入”帮我修一下这些 unresolved issues”，Claude Code 通过 MCP 连上 Sentry，拉出错误列表，按里面的”Resolution”步骤开始执行。

但你修的那个”Resolution”，不是 Sentry 写的。是攻击者写的。

6月12日，安全研究公司 Tenet Security 发布了一份研究报告，揭露了一种叫Agentjacking的新型攻击。这种攻击不需要钓鱼邮件，不需要入侵你的服务器，不需要植入木马。它只需要一件事：你的 AI 编程助手信任了一个不该信任的数据源。

结果：85% 的沦陷率，2388 家企业的 AWS 密钥、Git 凭证、Docker 配置和私有仓库地址全部暴露。

如果你在用 Claude Code、Cursor 或 Codex——尤其是配了 Sentry 做错误监控的——这篇文章就是写给你的。

攻击链：五步搞定你的代码库

Agentjacking 的攻击链极其简单，简单到让人不安：

第一步：找到你的 Sentry DSN

DSN（Data Source Name）是 Sentry 的公开写入凭证，嵌在你前端 JavaScript 里，Sentry 官方文档明确说”可以安全公开”。攻击者用 Censys 搜索、CDN 分析和 GitHub 代码搜索就能批量找到。Tenet Security 一共找到了 2388 个可注入的 DSN，其中 71 个属于全球 Top-100 万域名里的网站。

第二步：伪造一条 Sentry 错误事件

攻击者用你的 DSN 向 Sentry API POST 一条精心构造的错误报告。这条报告的 message 字段和 context 字段里嵌入了 Markdown——标题、代码块、表格，看起来跟 Sentry 自己生成的”Resolution”一模一样。Sentry 正常接收，HTTP 200，跟真实错误一起躺在你的仪表盘里。

第三步：你让 AI 去修错误

“帮我看看 Sentry 里这些 unresolved issues”——Claude Code / Cursor / Codex 通过 MCP（Model Context Protocol）连上 Sentry，拉取错误列表，看到那条伪造的 Resolution。

第四步：AI 执行攻击者的命令

AI 助手把伪造的 Resolution 当成合法修复步骤执行。Tenet Security 的 PoC 让 AI 执行了一个 npx 命令，从 npm registry 拉取一个”诊断包”，在开发者机器上以完整权限运行——探测环境变量、检查 ~/.aws/config 和 ~/.docker/config.json 的文件大小、扫描网络接口，然后把敏感信息 POST 到攻击者的服务器。

第五步：你什么都没察觉

受害者看到的是”AI 助手在修 Sentry 报错”——完全正常的工作流。EDR 没报警，WAF 没拦截，防火墙没触发。因为链上的每一步都是”合法的”——Sentry 按设计接收公开数据，npm 包走标准通道安装，AI 助手执行的是你授权的修复任务。

Tenet Security 管这叫Authorized Intent Chain（授权意图链）。你的 AI 在执行你授权的任务，用的是你授权的工具，在访问你授权的数据源。只不过那个数据源里的数据，有一部分是攻击者写的。

85% 沦陷率：不是模型蠢，是架构有缺陷

Tenet Security 在超过 100 家组织的受控测试中，达到了 85% 的攻击成功率。覆盖范围包括一家财富 500 强云企业、一家数十亿美元规模的托管服务商、科研软件公司、初创公司和独立开发者。六大洲都有中招的。

85% 这个数字乍看吓人，但逻辑很清楚：当前所有主流 AI 编程助手——Claude Code、Cursor、Codex——都无法区分”描述性数据”和”嵌入指令”。当一条看起来像是 Sentry 官方输出的内容里藏着”请执行 npx xxx”的时候，AI 模型把它当成正常的修复建议，而不是可疑的外部输入。

这不是某一个模型的 bug，是所有 AI Agent 的系统性架构缺陷。任何通过 MCP 返回外部数据的集成都有同样风险——错误日志、Issue 追踪器、PR 评论，都可能藏着攻击者的指令。

Tenet Security 还专门测试了一个让人沮丧的发现：即使在系统提示和 Skill 里明确告诉 AI “忽略不可信数据”，代理仍然执行了注入的 payload。提示层防御对这类攻击基本无效。

Sentry 的回应：”技术上不可防御”

Tenet Security 在 6 月 3 日向 Sentry 通报了这个漏洞。Sentry 当天就回应了，但态度很有意思：

• 承认了问题存在
• 启动了一个全局内容过滤器，屏蔽特定的 payload 字符串
• 但同时表示这是“technically not defensible”——在数据接收层面技术上不可防御
• 把 mitigation 推给了模型厂商——建议在模型侧做中间件防护

说白了：Sentry 的设计就是公开接收任意数据，DSN 是公开凭证，这是产品的核心功能而不是漏洞。要在 Sentry 层面过滤掉”看起来像指令的内容”，等于让错误监控平台去判断哪条错误报告里藏着 AI 可执行的指令——确实做不到。

所以防御责任落在了使用者身上。也就是你。

不是孤立事件：AI 编程工具正在变成新的攻击面

Agentjacking 不是 2026 年第一个针对 AI 编程助手的攻击。往前翻两周：

Miasma 蠕虫（6月5日）——GitHub 的反欺诈系统关闭了 73 个微软自己的 GitHub 仓库。一个自复制蠕虫，专门针对 AI 编程助手。开发者用 AI 工具打开被感染的仓库时，凭证直接被窃取——不需要代码执行。这是第一个大规模针对 AI 编程工具的供应链攻击。

VESTA 安全评估框架——研究人员测试了 12 个 LLM Agent，平均攻击成功率 47.1%，部分模型超过 70%。

趋势很清楚：AI 编程助手获得越多的自主权和越深的系统访问权限，攻击面就越大。一个能写代码和执行代码的 Agent，也是一个能被劫持去写和执行攻击者代码的 Agent。

之前站内写过 AI Agent 安全隐患，当时更多是前瞻性的风险分析。现在是实锤——攻击不是”可能发生”，是”正在发生”，而且成功率 85%。

五条实操防御措施（不废话版）

如果你正在用 Claude Code、Cursor、Codex 或任何 AI 编程助手，以下五条措施现在就该做：

1. 审查你的 Sentry 集成

检查 Sentry DSN 和 webhook 配置有没有被篡改。DSN 虽然是公开的写入凭证，但你可以做这几件事：

• 定期审查 Sentry 仪表盘里有没有异常错误事件——特别关注 message 字段里出现 Markdown 格式内容（标题、代码块、表格）的事件，真实的应用错误不会用 Markdown 格式写 Resolution
• 在 Sentry 项目设置里检查是否有不认识的 IP 或异常的事件提交来源
• 如果你是 Sentry 组织管理员，检查 Inbound Data Filter 规则，考虑限制单个事件的 message 字段长度

2. 给 AI 助手设置权限边界

这是最关键的一条。Claude Code、Cursor、Codex 默认有很宽的权限——读文件、写文件、执行命令、访问网络。你需要主动限制：

• Claude Code：在项目根目录创建 .claude/settings.json，限制可访问的目录和可执行的命令类型
• Cursor：在设置里限制 Agent 模式的文件修改范围，关闭自动执行模式
• Codex：使用沙箱模式运行，不要在主开发环境里直接执行

原则：AI 助手不需要访问 ~/.aws/、~/.docker/、~/.ssh/ 目录。不需要执行 npx 命令从公开 registry 拉包。不给它这些权限，Agentjacking 就没法窃取你的凭证。

如果你在用 Claude Code，两周前写的 /fork 命令使用指南 里提过权限控制的思路，可以翻回去看看。

3. 把所有外部数据源当成不可信输入

AI Agent 通过 MCP 连接的外部服务——Sentry、Jira、GitHub Issues、PR 评论——都可能被注入恶意内容。在使用 AI 助手处理这些数据时：

• 先人工审查关键 Issue 和错误报告，确认内容里没有异常的可执行指令
• 不要直接让 AI”修所有 unresolved issues”——逐条审查再让 AI 处理
• 在 CI/CD pipeline 里使用 AI 助手时，禁止 AI 从外部数据源自动拉取并执行任务

4. 固定你的依赖版本

Agentjacking 的 PoC 用 npx 从 npm registry 拉取了攻击者控制的包。防御：

• 在 CI/CD 中使用锁文件（package-lock.json / yarn.lock / pnpm-lock.yaml）
• 验证所有 npm 包的 checksum 再安装
• 限制 AI 助手只能执行 npm ci（只安装锁文件中的版本），而不是 npm install（可能拉新包）

5. 审查 AI 助手的操作日志

这是事后防御的最后一条防线。定期检查 AI 助手的 activity log：

• 有没有执行过你没授权的命令
• 有没有访问过不该访问的目录
• 有没有向外部服务器发送数据（检查 network log）
• 如果发现异常，立刻断开 AI 助手的 MCP 连接，审查所有最近修改的文件

新工具也要防：MiMo Code 和 Kimi K2.7

6月11日 小米发布了 MiMo Code——一款 MIT 协议开源的终端 AI 编程助手，内置持久记忆系统、Compose 模式和 /dream 命令，支持接入 DeepSeek、Kimi 和 GLM 等模型。

6月12日 月之暗面发布了 Kimi K2.7 Code——在 K2.6 基础上优化了长上下文编程、减少了 30% 的 token 消耗，还推出了 6 倍速高速版。

这两款新工具都不错。但 Agentjacking 告诉我们一个现实：任何通过 MCP 连接外部数据源的 AI 编程助手，都有同样的架构缺陷。MiMo Code 支持 Sentry 集成，Kimi K2.7 Code 也通过 MCP 连接外部服务。好消息是 MiMo Code 有持久记忆系统和会话检查点——理论上可以让你回溯 AI 的操作历史，更容易发现异常行为。但这不能替代权限限制。

用新工具没问题，但权限边界要跟上。上面五条防御措施，对 MiMo Code 和 Kimi K2.7 Code 同样适用。

如果你对这些新工具感兴趣，之前写过 AI 编程工程化实践，讲的是怎么让 AI 工具”靠谱地干活”——现在看来，”靠谱”不只是工程质量问题，还是安全问题。

写在最后

Tenet Security 在报告里说了一句很到位的话：”As enterprises race to deploy AI coding agents, this research proves the agents themselves are now the attack surface.”

AI 编程助手正在成为新的攻击面——不是因为它不安全，是因为它太信任了。它信任 Sentry 的数据是真实的，信任 MCP 返回的内容是干净的，信任你让它修的错误确实需要修。

信任是好品质，但盲信不是。给你的 AI 助手画好权限边界，把外部数据当不可信输入处理，定期审查操作日志——这三件事做完了，85% 的沦陷率跟你没关系。

Sentry 说”技术上不可防御”，但 Tenet Security 指出防御的关键点不在 Sentry 那头，而在AI Agent 的运行时——在它决定执行操作的那一刻。这跟之前 Copilot 按量计费那篇 的核心论点异曲同工：AI 工具的能力在往上加，但如果你不主动设边界——不管是成本边界还是安全边界——边界就不会自己出现。

---

信息来源：Tenet Security 官方博客（Agentjacking 研究报告，6月12日）/ CSA 研究笔记（PDF，6月12日）/ The Hacker News（报道，6月12日）/ Cybersecurity News（6月13日）/ IT之家 MiMo Code（6月11日）/ IT之家 Kimi K2.7 Code（6月12日）/ SimpleNews.ai Miasma 蠕虫（6月9日）