提示注入与致命三重威胁：保护AI智能体安全。
提示注入与致命三重威胁：为何人工智能代理无法区分用户的指令与攻击者的指令，以及EchoLeak和GitHub MCP攻击的运作原理。
来源: Prompt Injection and Agent Security: The Unsolved Problem
2025年6月，研究人员发现了Microsoft 365 Copilot中的一个漏洞，并将其命名为EchoLeak。攻击方式如下：有人向你发送一封看似普通的邮件。你既不打开它，也不点击任何内容，甚至不阅读它。但Copilot仍会读取这封邮件，因为它需要查看你的全部收件箱才能回答你的问题。该邮件中隐藏着指令，指示Copilot从你的其他文档中收集敏感数据，并通过自动加载的图片将其悄悄发送到外部服务器。整个过程无需任何点击操作，受害者也没有做任何错事。只是有恶意程序执行了这些指令，只不过对象不是目标人物而已。
EchoLeak遭遇了CVE漏洞（CVE-2025-32711），在得到修复后便停止了运行，这成为了已知首例在生产环境AI系统中利用提示注入窃取真实数据的案例。但这不会是最后一例。次年，同一类型的攻击又出现在GitHub的MCP集成、GitLab的Duo、Slack的AI功能、Google的NotebookLM以及所有新推出的AI浏览器中。到2025年底，OpenAI自身的安全团队公开表示，浏览器代理中的提示注入问题可能永远无法彻底解决，英国国家网络安全中心也持相同观点。
代理型人工智能的核心安全问题其实很简单，但我们至今仍没有明确的答案：模型通过完全相同的渠道接收用户的指令和攻击者的指令，且无法可靠地区分二者。下文将解释为何如此，为何这对代理型系统造成的危害远大于聊天机器人，以及哪些防御措施是有效的，而非那些厂商宣传材料中所说的。
所有指令都通过同一渠道
首先要了解其运作机制，因为对机制的误解正是薄弱安全指导的根源。
语言模型接收的输入只有一个：一长串标记符。系统的提示语也是其中的一部分，用户的提问同样属于标记符。代理程序刚刚获取的网页、它读取的邮件、它收到的工具输出结果、解析后的PDF文件以及图片上的替代文本，都属于标记符。所有这些内容都会以一个连续的序列形式呈现，模型则据此预测接下来的内容。其中并没有任何机制将某些标记符标记为操作员发出的可信指令，而将其他标记符标记为需要谨慎处理的不可信数据。2022年提出“提示注入”这一术语的西蒙·威利森这样描述它：模型会毫无异议地执行传给它的任何指令，无论这些指令来自操作员还是其他来源。
这就是问题的核心，而且根深蒂固。无论对模型进行何种升级都无法解决这个问题，因为这种缺陷源自设计本身。这些系统原本就是为执行用通俗语言表述的指令而设计的。然后我们把从公开网络中抓取的通俗文本交给它们，当这些隐藏的指令被执行时，我们便装作很震惊的样子。实际上，注入攻击只不过是让这些系统为错误的“老板”执行指令罢了。
所谓SQL注入正是这种攻击的名称由来。其实有一种有效的解决办法，那就是使用参数化查询——通过这种方式可以明确告知数据库，某部分内容是命令，某部分是数据，绝不能被当作命令处理。三十年来，网络安全的保障就在于在系统内部划清这一界限。而在大型语言模型中，没人知道该如何做到这一点，因为所有信息都在同一通道中传输，命令通道与数据通道合二为一。正因如此，那种让模型在系统提示中忽略网页内容中指令的常见做法根本行不通。你实际上是在用已被攻破的通道来保护另一个已被攻破的通道，而一段精心设计的文本内容总能绕过英文警告的约束。
有两种攻击类型常常被混淆。在直接注入攻击中，是用户自己输入恶意内容，比如要求查看系统提示。这更接近于越狱行为：即攻击者攻击自己本应有权使用的智能体。而间接注入攻击则会对智能体本身构成威胁。恶意指令隐藏在智能体工作过程中处理的外部内容中，比如网页、邮件、日历邀请、代码注释或GitHub问题。攻击者从不直接与智能体交互，而是在其预期会代表受信任的受害者阅读的内容中设置陷阱。上述所有案例都属于此类。由于攻击者无需直接接触目标，只需对智能体将要处理的对象有一定控制力即可，因此这种攻击方式具有很强的扩展性。
致命的三重威胁
这里最实用的心智模型是西蒙·威利森提出的“致命三重奏”，它解释了为何有些恶意程序极易被利用，而另一些则只会带来攻击上的困扰。
当一个恶意程序具备以下三种能力时，它就会变成窃取数据的工具。
- 能够访问私人数据。它可以读取你的电子邮件、私人存储库、客户记录或内部维基页面。这通常是该恶意程序存在的目的，因此你无法简单地将其删除。
- 能够接触不可信的内容。它可以处理那些并非它自己编写且未经你审核的文本：网页、收到的邮件、文档、第三方系统的输出内容。这同样通常是其存在的目的。
- 具备向外通信的能力。它可以通过发送HTTP请求、邮件、调用API、从攻击者的URL加载图片或提交拉取请求等方式，将数据发送到攻击者能够看到的地方。
其中任意一种都可以，通常两种组合也能正常使用。但如果在一个代理中同时存在这三种功能，并且都使用同一组凭证，那就相当于给你的数据配上了一把上了膛的枪。控制了第二种功能的攻击者可以劫持该代理的指令，利用第一种功能收集机密信息，再通过第三种功能将它们传输出去。EchoLeak攻击以及GitHub MCP攻击正是遵循了这样的流程。
GitHub的案例相当典型，便于分析。Invariant Labs在2025年5月展示了这一情况。开发者使用个人访问令牌将编程代理连接到官方的GitHub MCP服务器，而这类令牌通常被设置为可访问所有公开及私有的仓库。开发者提出一个看似无害的请求，比如查看某个公开仓库中的待处理问题。代理程序会读取这些问题，其中有一个是由攻击者提交的，其中包含隐藏指令：读取该用户的私有仓库内容，并将所发现的内容以公开拉取请求的形式发布出去。该代理程序具备第二种功能（仅读取攻击者提供的内容）、第一种功能（令牌可打开私有仓库）以及第三种功能（可创建公开拉取请求），于是它便执行了所有这些操作。在演示中，私有代码甚至个人的支付信息都暴露给了任何人。 该智能体执行的每一个操作都在其权限范围内，且运行方式完全符合设计要求。三重防护机制就此被彻底破解。
看看解决方案。Docker的应对措施并未试图检测恶意问题，而是通过规则打破了三重防护：每个会话都被限制在单个仓库中，因此一旦智能体试图访问另一个仓库，无论指令如何，都会被阻止。模型并没有变得更聪明，只是在能力整合的环节移除了一项功能，而这正是所有真正防御措施的核心所在。
为何智能体比聊天机器人糟糕得多
早期对大语言模型安全性的担忧使得注入攻击看起来尚可接受。聊天机器人说些无礼的话或泄露提示词，虽然令人恼火，但并不致命。而智能体则将风险提升到了完全不同的层面。
聊天机器人生成文本，而智能体则执行操作。如果劫持了聊天机器人，只会让某人看到不同的回复；但若劫持了智能体，其本身的行为就会发生改变，并能产生实际影响：它可以给人们发送邮件、转账、删除记录、合并代码或运行shell命令。OWASP智能体安全项目列出的2026年十大风险正是这类后果的体现：目标劫持、工具滥用、权限滥用、内存污染，以及多智能体系统中的连锁故障。每一项都是普通注入攻击因模型具备实际功能而放大的结果。
有三个因素加剧了这种风险。
攻击面指的是智能体所读取的所有内容。在真实的智能体中，操作员的提示仅是少量标记符，而70%甚至更多的上下文往往来自工具输出和检索到的内容。这种失衡的构成同样会带来安全问题。模型在做出决策时所依据的大部分信息都来自外部，其中的任何标记符都可能构成指令。在海量不可信输入面前，你信任的提示简直微不足道。
自主性消除了人为干预带来的阻碍。智能体的价值在于能够无需每一步都请求许可即可持续运行，但每一个无人监督的步骤都意味着有指令可能被注入且无人能够及时发现。智能体的自主性越强、功能越出色，这种风险窗口就越大。能力与被注入指令的可能性是同步增长的，这意味着在其他条件相同的情况下，能力越强的智能体越容易被攻击者利用，造成的损失也越大。
持久性机制与链式结构会进一步加剧问题。智能体具备记忆功能，而这种记忆可能被篡改：攻击者可在周一将虚假的“事实”植入长期存储中，从而在数周内影响决策。智能体会互相调用，因此某个子智能体数据中的注入内容会沿着无人全程监控的链式结构逐级传播。像Atlas和Comet这样的智能体浏览器，会同时在你登录银行、邮箱及公司管理控制台的标签页中植入可被注入内容的智能体。研究人员早已用伪装成URL的恶意文本以及能植入虚假记忆的内容欺骗过Atlas。OpenAI的回应值得肯定，它通过对抗性训练和自动化红队测试强化了产品，并明确告知用户该问题尚未完全解决。
有效的防御措施
坦白说，没人知道如何让模型始终100%抵抗注入攻击。下面的每种防御措施都能降低风险，但没有一种能彻底消除风险。真正的安全保障在于叠加多种不完美的防护层，更重要的是设计系统，确保成功的注入攻击无法触及任何有价值的内容。以下是真实的防御手段，而非那些令人安心的幻想。
首先打破这三项要求同时存在的状况。这样做带来的收益远超其他方法，而且无需使用机器学习。对于每个智能体，检查它是否同时具备这三种能力，如果具备，则进一步判断在特定场景下是否可以舍弃其中某一种能力。负责读取不可信网页的智能体不应同时拥有生产环境数据库的访问权限；处理敏感数据的智能体其外部通信应受到严格限制，仅允许与预先列出的地址进行通信，从而确保没有途径泄露机密信息。GitHub规定的每次会话仅处理一个仓库的机制，正是对这三项要求的一种突破。这一措施之所以有效，是因为它是基于架构设计而非概率算法。
应采用能够防止规划器接收到恶意输入的设计。最有前景的研究将注入攻击视为数据流动方式的问题，而非能否检测到的问题。Dual LLM模式及其更严格的衍生方案CaMeL（《通过设计击败提示注入攻击》，2025年）将智能体分为两个角色：一个拥有特权的模型负责读取请求并规划操作步骤，但绝不会看到不可信的内容；另一个被隔离的模型则负责读取邮件或网页等不可信内容，但它没有相应工具，也无法采取任何行动。CaMeL还进一步采取了措施：特权模型的计划会被编译成受限程序，同时有一个自定义解释器会追踪每个值的来源。任何来自不可信来源的内容都会被标记出来，除非有相应策略允许，否则它无法触发任何危险操作。 这最接近于用于大型语言模型的参数化查询，真正实现了命令与数据之间的界限划分。不过这也有代价：必须有人来编写相关规则，而且无尽的审批提示可能会让用户养成条件反射般地选择“同意”的习惯。尽管如此，它依然基于原则，而原则在面对坚定的攻击者时也能站得住脚。
通过权限层级来限制操作。根据每个操作可能造成的损害程度为其排序，由管控机制而非提示语来执行这一排序。阅读操作是无声的，任何可逆操作都会被记录下来；那些难以逆转的操作（发送、删除、支付、合并）则需要人工确认，明确说明即将发生什么；而那些不可逆转且代价高昂的操作则会被阻止，或通过模型无法干预的审批流程处理。提示语只是攻击者可以争辩的建议，而管控规则则是他们无法逾越的障碍。要求模型在发送资金前始终先询问是值得的，但单独这样做并无太大意义。让支付代码需要模型根本无法拥有的令牌，这才是真正的安全措施。
应使用具有限定范围的凭证来实施最小权限原则。注入攻击所能造成的危害仅限于该代理被允许的操作范围，因此应为每个代理分配最狭窄的权限范围、有效期最短的令牌，以及完成工作所需的最少工具。GitHub事件正是由于使用了权限过大的令牌，而按仓库划分的OAuth权限范围本可以避免此类问题。这虽是老生常谈的基础安全措施，却比任何复杂的提示都更有效。
添加检测功能，但不要过度依赖它。团队通常会首先采用这一层防护，但实际上它应处于最后位置。注入检测分类器是经过训练的模型，能够识别“忽略先前指令”及其各种变体，确实能捕获大量攻击行为。Anthropic的计算机使用分类器、Microsoft的XPIA过滤器以及许多初创公司都在这一领域开展研究。既然这些工具能提高攻击成本，那就加以使用。不过要清楚了解它们的实际作用。虽然某种分类器能拦截99%的攻击尝试，但从安全角度而言这仍算失败，因为注入攻击并非随机噪声。攻击者可以不断重试并适应你的过滤机制。EchoLeak的首次攻击就是通过精心设计的邮件来绕过Microsoft的注入检测分类器，而且确实成功了。面对会不断适应的攻击者，1%的泄露率都可能成为阻碍。应将检测功能视为其中一层防护，绝不能将其作为安全体系的基石。
记录一切。每一次工具调用、检索到的文档以及执行的操作都应被记录下来并明确归属。从安全角度而言，这就是检测与取证机制。事后你需要知道在出现异常行为之前代理读取了什么内容，以及指令来自何处；当代理突然开始使用超出常规模式的资源时，还需要有异常警报。如果看不到攻击，就无法进行防御，甚至无法理解其本质。无法观测的代理不仅难以调试，还会导致你只能从他人那里得知安全漏洞的存在。
三起可供研究的事件
当模式与真实事件相结合时，它们就会更加清晰。这三起发生在大约18个月内的事件，展示了该问题的不同严重程度。
EchoLeak（Microsoft 365 Copilot，CVE-2025-32711）。其独特之处在于无需任何点击操作，而非依赖复杂技巧。该漏洞于2025年1月被发现，5月得到修复，6月公开披露，它是首个能够在用户无需任何操作的情况下从生产环境中的AI系统中获取真实数据的提示注入漏洞。攻击者通过四种手段实现攻击：设计用于通过XPIA分类器的邮件、能够绕过链接屏蔽功能的引用式Markdown链接、可自动加载并发送外部请求的图片标签，以及作为中转站的已白名单化的Teams预览API，从而使数据通过授权通道流出。微软原有的每一项防护措施单独来看都是合理的，但攻击者找到了它们之间的漏洞。多层检测机制本身也意味着存在多层漏洞，而耐心的攻击者会逐一探测这些漏洞。
GitHub MCP安全漏洞事件（Invariant Labs，2025年5月）。此事件此前已有报道，但仍需重申关键点：没有任何系统出现故障，所有凭证均正常，模型也保持完好状态。造成漏洞的原因是通用访问令牌、能够读取攻击者编写问题的智能体，以及开启公开PR的功能被组合在了一起。这里不存在需要修复的利用代码或内存错误，仅有三种本不应共享同一会话的功能。这正是智能体安全成为一门新兴学科的原因——漏洞在于各组件的组合方式，而非某个单独组件本身。
代理型浏览器（Atlas与Comet，2025年末）。当ChatGPT的Atlas和Perplexity的Comet问世后，研究人员立即展示了全功能搜索框注入攻击——那些伪装成网址的文本会被当作指令执行——以及会在不同会话之间留下虚假上下文的记忆攻击。尤为恶劣的是这些攻击元素的共存情况：可被注入的代理程序存在于用户同时登录银行、邮箱和管理控制台的同一位置，这三者默认就聚集在风险最高的场所。OpenAI的反应为整个行业定了调子：通过对抗性训练、自动红队测试，并公开承认这一问题尚未解决。应当相信他们的表态，按照浏览器代理程序最终可能被欺骗的前提来设计系统。
按层次进行评估
从不同层次入手，为每一层选择相应的评估项。
- 设计模式防御机制：CaMeL与双大语言模型模式。这类机制将规划过程与不可信数据分开，并追踪数据来源，从而提供最强的保障。
- 注入检测分类器：Anthropic的检测分类器、Microsoft的XPIA、Lakera Guard、PromptArmor以及protectai/rebuff。它们能识别不可信输入中的恶意内容，在不构建完整防护墙的情况下增加处理成本。
- 网关与策略执行机制：Docker MCP Gateway拦截器、Invariant Guardrails以及出口允许列表。这些机制通过制定策略限制会话范围、阻止跨资源访问并控制出站流量，从而打破恶意攻击的三重组合。
- 红队测试工具与基准测试：AgentDojo、AgentDyn、BIPIA、CyberSecEval以及deepteam，这些工具使得注入测试具备可重复性和可衡量性。
一条能避免麻烦的准则：不要仅购买一款产品就认为自己已得到保护。上述每一项都是一层防御机制，关键在于没有任何单一层能单独起到作用。完善的防护策略应结合设计模式防御、受限的凭证机制、权限层级结构、分类器以及完整的追踪功能，如此即便突破某一层防御，攻击者仍会面临后续的防护措施。
实际环境中的故障模式
- 数据窃取链。不受信任的内容会指示代理收集私有数据并将其传输出去，如EchoLeak和GitHub MCP中所见。可通过打破这一完整流程、使用出站允许列表、追踪数据流（CaMeL）以及限制凭证权限来加以防范。
- 被误导的代理。注入的内容会迫使代理执行用户从未期望的、会改变系统状态的操作，比如发送邮件、删除文件或批准交易。可通过权限层级机制阻止此类行为，要求任何重要操作都必须经过人工审批，且相关规则需嵌入到控制框架中。
- 零点击攻击。由于代理的常规后台读取行为即可触发攻击，因此无需用户任何操作，就像EchoLeak中的自动加载图片一样。应严格限制自动获取和外部渲染功能，控制数据出站，并将所有被动接收的内容视为恶意威胁。
一周安全检查清单
这份清单简短、具体，且可直接用于你已有的代理进行测试。
第一天，梳理全方位防护机制。针对你运行的每个代理，记录它能访问哪些私有数据、会接收哪些不可信内容，以及如何将数据传送到外部。具备这三项功能的代理应被列入优先清单。这份清单将成为你编写的最有价值的安全文档，只需一个下午的时间即可完成。
第二天，至少削弱每个三重组合中的一个组件。对于每个高风险智能体，取消其在该设置中的一个功能。将其拆分为两个职责更明确的智能体，降低其权限，或仅允许其访问白名单内的地址。并非所有三个组件都能被移除，但只需削减一个就能避免数周的繁琐强化工作。
第三天，建立权限层级结构。列出该智能体可以执行的所有操作，并根据影响范围将其分为静默执行、记录日志、需要确认以及被阻止四类。在代码层面强制执行最高两层的权限控制，使其超出模型的干预范围，同时确认提示信息能准确显示实际会发生的情况。
第4天，攻击你自己的智能体。准备十种恶意输入，包括带有陷阱的页面、消息、问题、邀请、包含隐藏文本的PDF，以及其替代文本包含指令的图片。在沙箱环境中让智能体逐一处理这些输入，观察会发生什么。总会有某种方法奏效，自己发现它总比让别人发现更好。像AgentDojo这样的基准工具能让这项练习可重复进行。
第5天，加入检测机制并保持预期合理。在不可信输入之前放置注入检测器，并记录它标记出的内容。这只是一个提高攻击者成本的警报系统，并非真正的防护屏障。将其输出结果用于第6天要启用的追踪功能中。
第6天，出于安全考虑启用追踪功能。确保每一次工具调用、数据检索和操作都被记录下来，并明确标注操作者身份；同时为超出正常模式的资源访问设置警报。如果已有追踪功能，你只需修改配置，而非重新启动整个项目。
第7天，每次做出更改后都要将其记录下来并重新测试。注入防御并非一个需要达成的阶段性目标，而是一种需要持续维护的属性。任何新的工具、数据源或功能都可能再次引发之前已解决的安全问题，因此要在审查清单中加入“这是否会重新引发安全问题？”这一项，一旦答案是肯定的，就立即重新执行第4天的攻击测试。
没有完美的结局
提示注入问题仍未得到解决，而且可能无法像SQL注入那样被彻底解决，因为让这些模型能够理解普通语言指令的优点，恰恰也是使其容易被利用的根源，目前还无人知道如何在保留前者的同时避免后者。开发前沿浏览器的人已经开始公开表达这一观点，这是目前最令人鼓舞的进展：业界终于不再假装更智能的模型就能让这个问题消失。
等待修复并非可行的方案。真正的方案是让智能体在模型被欺骗后仍能保持安全，因为这种情况迟早会发生。这能引导工程团队将精力从设计更巧妙的系统提示语以提醒谨慎，转向构建保护模型的架构。要打破这种三重风险，就要将规划与不可信数据分开，严格限制所有权限，让每一项关键操作都被置于模型无法绕过的屏障之后，并对一切行为进行监控。所有这些措施都应体现在控制系统中，而非模型本身。
模型是一个功能强大、容易轻信且容易被植入恶意内容的组件，而控制系统则是确保其安全使用的手段。如果把模型当作安全边界，安全防线就会被突破；只有将边界设置在模型之外、处于你的控制之下，才能获得安全保障。
相关阅读
- DS-STAR详解：谷歌的数据科学智能体及其优势所在 — 详细介绍谷歌的DS-STAR数据科学智能体：其七个模块、DS-STAR+报告机制、已发布的提示词、消融实验结果以及现存的局限性。
- 实践笔记：我在本地运行AI编码智能体，效率几乎提升一倍 — 详细指导如何实现“我在本地运行AI编码智能体，效率几乎提升一倍”这一目标：包括相关契约设计、验证步骤，以及供团队直接使用的代码模板。