伪造一条报错，你的AI助手就帮黑客搬了家

你的AI编程助手弹出一条Sentry报错，看样子挺急的。你随口说了句"修一下"，它查了错误日志，按里面附带的"解决方案"装了个依赖、改了环境变量，还顺手更新了Git凭证。

你以为它在修Bug。它在帮你搬家，搬去攻击者的服务器。

这不是编的。Tenet Security的三位研究员Ron Bobrov、Barak Sternberg和Nevo Poran刚披露了一种叫Agentjacking的攻击手法，2388个组织已经暴露在攻击面之下，其中71个位列全球流量前百万域名。

没有钓鱼邮件，没有恶意软件，不需要攻入任何服务器。一条伪造的错误报告就够了。

◆攻击链：五步走完，干净利落

整个路径拆开来看，清晰得让人不舒服。

第一步，找你的Sentry DSN。这东西写在你前端的JavaScript里，搜索引擎大量索引，Censys一搜一大把。Tenet用被动侦察手段（JavaScript检查、Censys搜索、CDN加载器分析、代码检索）锁定了2388个组织的DSN。许多团队压根没意识到这是攻击面，"它只是个只写凭证嘛"。问题在于，只写不代表只被你写。

第二步，造一条假的错误事件。攻击者在message和context字段里塞进精心排版的Markdown，伪装成Sentry的"解决方案"板块。标题、代码块、表格一应俱全，和真正的修复指引肉眼看不出区别。

第三步，一条POST请求，伪造事件就混进了你的Sentry数据流。DSN是只写凭证，Sentry的数据入口不校验事件来源的真实性。来者不拒。

第四步，你的AI代理通过MCP查询错误列表，拉到了这条被污染的事件，把攻击者注入的Markdown当成Sentry官方诊断步骤。

第五步，AI执行"修复"。实际上在窃取Git凭证、读取环境变量、暴露私有仓库地址，甚至以当前用户权限执行任意代码。

Tenet在超过100个组织的受控测试中，攻击成功率85%。Claude Code中招，Cursor中招，凡是把Sentry通过MCP接入AI代理的工具，全部中招。

◆AI代理最大的漏洞，是它太听话了

Agentjacking这个名字取得精准。劫持的不是代码，不是服务器，是你和AI代理之间的信任约定。

想想AI编码助手的工作方式：你把Sentry、GitHub、数据库通过MCP协议接入后，它默认所有返回数据都是可信的系统诊断信息。它不会质疑这条错误事件是不是真的，那不在它的判断框架内。它只会按照内容做出响应，像一个特别听话但毫无判断力的实习生。

安全研究员说得直白：漏洞的根源在于，AI代理无法分辨真实的程序崩溃事件和攻击者投喂的虚假错误报告。

这不是某一家产品的缺陷，是架构层面的问题。Sentry的DSN设计上就是"来者不拒"的，MCP又把这条管道直接接入了AI代理的上下文。等于给攻击者开了一扇没锁的侧门，而系统设计者亲手装了这扇门。

Sentry事后承认，这个问题"从技术上讲无法防御"。目前能做的，只是针对已知payload模式激活全局内容过滤器。说白了，堵已知的窟窿，未知的？等着被发现再说。

◆不只是Sentry的事

更值得警惕的是，这种攻击逻辑可以迁移到更多场景。

任何将外部数据源通过MCP接入AI代理的架构，都面临类似的信任边界问题。GitHub Issues、Jira工单、Slack消息、Confluence文档，如果攻击者能在其中任何一处注入精心设计的内容，而AI代理又将其视为可信输入，Agentjacking的剧本就能重演。

北京邮电大学等机构的研究团队已经推出了针对MCP协议的安全基准MSB，论文被ICLR 2026接收。他们的核心发现是：MCP的每个阶段（任务规划、工具调用、响应处理）都存在攻击入口，性能越强的模型反而越容易被攻击。

OWASP也把"Agent Goal Hijack"（ASI01）列为2026年Agentic应用安全Top 10的首位。此前Microsoft 365 Copilot的EchoLeak漏洞（CVE-2025-32711），用的是同一套逻辑：给Copilot发一封含隐藏提示的邮件，它就在用户不知情的情况下泄露敏感信息。

Tenet揭示的不是一个产品的漏洞，是一种新攻击范式的诞生。当AI代理的权限越来越大，能调用的工具越来越多，它的"听话"本身就成了最危险的资产。

◆防御不是打补丁，是重新划线

怎么修？不是改两行代码的事。

短期，开发者能做几件实际的事：审查所有通过MCP接入的数据源，想想哪些外部输入可能被攻击者控制；对AI代理的执行权限收紧，尤其是涉及凭证、环境变量和远程执行的场景；在响应链路里加人工审批，至少高危操作做到"AI提议、人确认"。

中期，MCP协议本身需要引入数据溯源和可信度标记。AI代理应该能区分"系统生成的诊断信息"和"可能夹带私货的外部输入"，并据此调整信任等级。

长期看，这指向一个根本问题：AI代理不能只是"更听话的工具"，它得能质疑输入。当一条Sentry错误突然建议你跑一段Shell脚本，一个真正安全的AI代理应该能停下来想想，这合理吗？

工具不需要判断力，代理必须有。从工具到代理，不只是能力升级，更是安全范式的转换。你给AI多少权限，就等于给攻击者留了多大的门。权限越大的AI助手，越需要一个等量级的安全机制来管住它。

当AI替你写代码时，谁来替你检查代码？这个问题不回答，迟早会被现实替你回答。到那时候，代价可就不是一条伪造报错了。