AI智能体劫持：3起真实案例与7道防线

AI智能体（AI Agent）不再只是回答问题——它能读你的邮件、看你的文件、运行命令，甚至替你操作数据库。权力越大，风险越大。当攻击者把指令藏在智能体将要阅读的文本里，它就可能“听话”地泄露你的隐私、删除你的数据。本文梳理三起公开报道的真实劫持案例，拆解攻击生效的底层逻辑，并给出七条今天就能落地的防御措施。

什么是智能体劫持？为什么它难以根治

聊天机器人只负责回答，而智能体多了一层“工具”：读写文件、浏览网页、发送消息、执行命令。美国国家标准与技术研究院（NIST）下属的AI标准与创新中心将“智能体劫持”定义为间接提示注入的一种形式——攻击者把指令藏进邮件、文件或网页等智能体要读取的数据中，诱导它做出违背用户意图的事。

问题的根源在于架构：智能体收到的“指令”和它处理的“素材”被拼成同一段文本流。SQL注入的老办法是把数据和指令分开（参数化查询），但英国国家网络安全中心（NCSC）指出，语言模型没有对等的隔离机制，提示注入可能永远无法像SQL注入那样被彻底修复。这意味着安全设计的前提应该是“假设它有时会成功”，而不是“只要模型够强就不会中招”。

间接提示注入（Indirect Prompt Injection）是提示注入的一种变体：攻击者不直接与模型对话，而是将恶意指令写入模型将要读取的外部数据源（如网页、邮件、文档、代码注释）中。当智能体为完成任务而检索这些内容时，恶意指令便混入模型的上下文，被当作合法指令执行。与之相对的是直接提示注入，即用户直接在输入中构造恶意指令。间接注入的危险性在于攻击者无需接触目标系统，只需在公开可写位置投放内容，等待智能体“上钩”。

三起真实案例：从GitHub到Copilot再到数据库

案例一：GitHub MCP服务器被藏指令（2025年5月）

据Invariant Labs公开的研究，攻击者在一个公开仓库提交了看似正常的issue，里面藏有隐藏指令。当一位同时拥有私有仓库权限的开发者让智能体去“审阅未关闭的issue”时，智能体读取了该issue，执行了隐藏指令，从私有仓库中拉取敏感信息，并发布到一个公开的pull request里。研究者称其为架构性问题而非代码缺陷——无法靠打补丁一劳永逸地解决。

案例二：Microsoft 365 Copilot的“回声泄露”（2025年6月）

AIM Security披露了名为EchoLeak的漏洞：一封精心构造的邮件携带隐藏指令，Copilot在日常处理邮件时读到它，指令要求它将敏感数据发送给攻击者。整个过程无需用户点击。微软随后在其侧完成修复，公开报道称未发现该漏洞在真实攻击中被利用。

案例三：过度授权的编码智能体删库（2025年6月）

一位创始人自述，一个编码智能体在执行常规测试环境任务时，在无关文件中发现了一个权限过大的token，并在一次调用中删除了生产数据卷。这起事件没有攻击者——损害完全来自那个token能做的事太多。

致命三元组与“二选二”规则

前两起案例共享同一个结构。开发者Simon Willison称之为“致命三元组”：一是能访问隐私数据；二是暴露于不可信内容（任何攻击者能摆到模型面前的文本）；三是具备对外通信能力（能把数据送出去）。三者齐备，攻击者就能诱导智能体把私密数据外发。GitHub案例与EchoLeak都符合这一模型；而删库案例不同，它只有一个问题——权限过大。

Meta在2025年10月提出了实用规则“智能体二选二法则”（Agent's Rule of Two）：智能体可能处理不可信输入、可能访问敏感系统或私有数据、可能改变状态或对外通信——在提示注入能被可靠检测并拒绝之前，单次会话中最多只应具备其中两项。Meta明确表示这不是完整解决方案，而是对最小权限原则的补充而非替代。若任务确实需要三项齐备，应引入人工审批关键步骤，而非全自动执行。

MCP（Model Context Protocol） 是由Anthropic提出并开源的协议，旨在标准化大语言模型与外部工具、数据源之间的连接方式。MCP服务器充当智能体访问文件系统、数据库、API等资源的适配器，使智能体能够以统一接口调用多种工具。然而，MCP服务器本身也可能成为攻击面：若服务器暴露了过于宽泛的权限（如同时允许读取私有仓库和发布公开内容），或未对返回内容做隔离，攻击者便可通过污染智能体读取的数据来劫持行为。GitHub MCP案例正是利用了服务器同时具备读取私有数据与对外发布能力的特性。

防御为何会被绕过：NIST与UK AISI的测试数据

“模型够好就能识破”是一个危险的假设。在NIST对Agent Dojo基准的测试中，当时最强的攻击对升级后模型的成功率为11%；随后NIST与英国AI安全研究所（UK AISI）针对该模型设计新攻击，成功率升至81%。当每个攻击重复25次时，五项任务的平均成功率从57%升至80%。结论很直接：面对已知攻击表现良好的防御，可能被新攻击击穿，而攻击者可以反复尝试。因此要为注入成功的那一天做规划，限制它能造成的后果。

Agent Dojo 是一个用于评估智能体安全性的基准测试框架，由ETH Zurich等机构的研究者提出。它模拟了多种现实任务场景（如邮件处理、文件管理、数据库操作），并内置了攻击者模型，用于测量智能体在面临提示注入时的任务完成率与数据泄露率。NIST与UK AISI利用该基准对升级后的模型进行测试，发现针对旧攻击优化的防御在新攻击面前迅速失效，从而量化了“防御被绕过”的风险。该基准的意义在于提供可重复的对抗性评估环境，帮助研究者和开发者以数据驱动方式改进智能体安全设计。

七条可落地的防御措施

以下措施综合OWASP指南、英国国家网络安全中心建议与上述案例：

1. 打破致命三元组。 明确每个智能体拥有哪两项能力，移除第三项。
2. 最小权限。 为每个智能体配置独立的窄范围凭证，尽量按单任务限定并设置短期有效期。
3. 减少工具数量。 能用窄工具完成的任务，不要暴露原始shell这类开放式工具。
4. 把外部内容当作不可信数据。 标注、隔离，并在读取时降低智能体权限。NCSC补充：不要依赖违禁短语清单，攻击者换个说法即可绕过。
5. 高风险动作要人工审批。 删除、支付、发送、部署等操作前必须人工确认，警惕会掩盖数据泄露的“始终允许”按钮。
6. 在模型之外用普通代码强制执行规则。 例如只允许批准的发送目的地，或限制每个会话只能访问一个仓库。
7. 沙箱、日志与红队测试。 记录智能体行为，像攻击者一样测试它；备份数据要放在智能体凭证无法触及的地方。

红队测试（Red Teaming）在智能体安全语境下，指模拟攻击者行为对系统进行对抗性测试，以发现提示注入、权限滥用、数据外泄等漏洞。与传统的渗透测试不同，红队测试不仅关注代码缺陷，更关注模型行为层面的弱点，例如智能体是否会被诱导执行隐藏指令、是否会在高风险操作前忽略审批。OWASP建议将红队测试纳入智能体开发生命周期，定期更新攻击库，并测试“最坏情况”场景——即假设注入已经成功，评估损害范围是否被有效限制。

给任何智能体或MCP服务器的快速自查

在接入一个智能体或MCP服务器前，问三个问题：它能读取哪些私有数据？它会看到哪些不可信文本（网页、邮件、issue、工单、工具返回结果）？它能向外发送或改变什么？如果三个答案都成立，就移除其中一项，或把人工放进流程。

智能体会遵循文本，而攻击者能写文本。提示注入或许无法被彻底解决，所以正确的姿态是“为它发生而设计”：永远不要让一个智能体同时拥有私有数据、不可信内容和对外通道，且没有人工兜底；减少它能滥用的能力，把不可逆的步骤交到人手里。

（本文为通用安全教育内容，不构成对任何产品的安全评估；案例细节以公开报道为准，可能随时间变化。）