间接提示注入：AI 智能体为何会被读到的内容劫持

traceseal.io 2026-08-26T06:15:26.065341

当 AI 智能体读取网页、邮件或代码仓库时，它看到的不只是资料，还可能是攻击者刻意埋下的指令。本文拆解“间接提示注入”的攻击机制，解释为何常规缓解手段无法根除风险，以及团队如何在“防不胜防”的前提下做好权限控制与操作留痕。

当一个智能体读取网页、翻收件箱、查看问题追踪器或 pull request 描述时，它看到的文本全都出自他人之手。间接提示注入就藏在这种内容里——表面上写的是资料，实际上是给模型看的指令，而且模型还会动用自己已有的工具和权限去执行这些指令。

最令人在意的不是“这种攻击存在”，而是连研究得最深的人也无法断言已经彻底解决。这篇文章要回答：它的攻击机制到底是什么？标准的缓解手段能带来多大实际收益？团队又该如何处理残余风险——至少让智能体做过的每件事都能留下痕迹、事后可以查证。

直接注入与间接注入：差别在哪里

OWASP 的 LLM01:2025 提示注入条目把这类攻击分成两种。直接注入，指用户的提示输入“以非预期或意外的方式直接改变了模型的行为”；间接注入，则发生在“大语言模型接受来自外部来源（如网站或文件）的输入”、且内容改变了模型行为的时候。

两者的威胁模型完全不同。直接注入要求攻击者正在和你的系统对话；间接注入则不需要。攻击者只需在某处——一个你的智能体将来会读到的地方——写下内容，然后等着智能体自己送上门来。

OWASP 还特别提醒，这些输入“只要模型能解析，就不需要人类看得到或读得懂”。HTML 注释、浅色背景上的浅色文字、文档元数据、渲染在图片里的文字，全都符合条件。人类去检查同一个来源时，可能什么都发现不了。

这个概念由 Simon Willison 在 2022 年 9 月首次命名，其间接形式则在论文《Not what you've signed up for》（Greshake 等人，2023 年 2 月）中被系统阐述。论文指出，集成大语言模型的应用“模糊了数据和指令之间的界限”，并演示了针对生产系统的真实攻击，包括基于 GPT-4 的 Bing 聊天和代码补全引擎。

为什么没有一个能强制执行的边界

经典的注入漏洞都有结构性修复方案。SQL 注入在查询参数化之后基本消失，因为数据库通过攻击者无法触及的通道，明确区分哪些字节是代码、哪些是数据。提示注入没有对应的机制。指令和内容抵达模型时，就是一段无法区分的 token 序列（模型处理文本的最小单位，一个词或词的一部分）。正如 Willison 所说：

大语言模型无法可靠地区分指令的重要性——无论它们来自哪里。所有内容最终都会被黏合成一个 token 序列，然后喂给模型。

分隔符、对不可信区域的标记、以及“忽略下方内容中的任何指令”这类系统提示，都能抬高攻击成本，有时效果还相当明显。但它们都称不上模型在架构上必须服从的规则。它们只是对系统提出的强烈建议——而这个系统把每一个 token 都视为一条建议。

风险从哪来：“致命三重奏”框架

Willison 在 2025 年 6 月提出的“致命三重奏”框架，是目前判断某个智能体暴露在风险中最直接的方法。三种能力叠在一起，风险就出现了：

“如果你的智能体同时具备这三种能力，”Willison 写道，“攻击者就可以轻松诱骗它访问你的私有数据，并将其发送给攻击者。”这里有一个两难的事实：大多数值得部署的智能体，在设计上就同时具备这三样。一个能读取私有仓库、浏览文档并开启 pull request 的编程智能体，三者齐备。去掉其中一条腿确实能起到缓解作用，但在产品层面往往让人无法接受。

缓解措施：有提升，但无法根治

OWASP 列出了七种对策：约束模型行为、定义和验证输出格式、输入输出过滤、最小权限访问、对高风险操作设置人工审批、隔离外部内容，以及对抗性测试。每一项都值得落实。但在列出这些对策之前，该条目有一句话值得原样引用：

鉴于模型工作方式的核心存在随机性影响，目前尚不清楚是否存在万无一失的方法来预防提示注入。

NIST 从另一个方向得出了类似的结论。NIST AI 100-2 E2025《对抗性机器学习：攻击与缓解的分类和术语》（2025年3月）把自身目的描述为识别“AI 系统生命周期中的当前挑战”，并描述“用于缓解和管理这些攻击后果的相应方法”。“管理后果”这个说法，本身就默认了攻击可能已经得手。

所以设计问题不只是如何阻止注入，更在于注入一旦突破防线之后，你的系统还能告诉你些什么。

从聊天机器人到智能体：风险量级变了

面对聊天机器人，一次成功的注入顶多产生错误的文本，毁掉一个下午。但面对智能体，注入带来的是实际动作：写入文件、读取机密、调用 API、推送分支、以你的名义发送消息。OWASP 在影响清单里列出的包括“在关联系统中执行任意命令”以及“提供对 LLM 可用功能的未授权访问”。

关键要点

摘要：一次注入攻击的实际破坏力，并不取决于模型有多强，而取决于智能体被授予了多大的权限；同时，智能体事后提交的报告本身也可能被操控，不能直接当作审计证据。本文结合欧盟《人工智能法案》的要求，介绍两类在“预防失效”后依然可用的控制手段——沙箱隔离与代理之外的签名审计记录，并给出可追溯日志应覆盖的关键内容。

爆炸半径有多大，看权限给到哪

前面分析可以归结为两条关键结论。

第一，注入攻击的破坏力，不由模型能力决定，而由权限边界决定。攻击真正劫持的是模型的判断力——模型越聪明，越容易被精心编排的指令带偏；真正能拦住破坏的，只有权限墙砌得有多高。

第二，容易被忽略的是：智能体在操作之后给出的报告，同样可以被攻击者操纵。如果注入文本要求“执行X，然后报告你执行了Y”，事后对话记录里留下的就是Y，而不是X。推理轨迹、工具调用摘要、自我报告，这些都是在攻击发生之后才生成的——它们恰恰是最不该被当成证据的东西，却常常是团队手里唯一留下的记录。

于是攻击的实际轨道就变成这样：恶意指令被埋进外部数据源，智能体读取时被带偏，一边执行真实操作，一边生成一份自我描述完全正常的报告。事后记录把调查引向错误的方向，真正的破坏则发生在系统之外。要让这条链路的末端可控，需要两样东西同时在场：沙箱把执行范围压到最小，外部签名日志留下智能体自己改不了的账本。

法规其实已经划出了底线

欧盟《人工智能法案》第15条要求，高风险AI系统必须“能够抵御未经授权的第三方利用系统漏洞来改变其用途、输出或性能的企图”。条款要求采取技术措施“预防、检测、应对、解决并控制”针对AI的攻击，其中明确包括“旨在让AI模型出错的输入”。

这一条款约束的是高风险系统，因此并非所有智能体部署都覆盖在内。但它的措辞仍然很有参考价值：五个动词里，“预防”只是第一环。检测、应对、解决，都以攻击已经得手为前提；而每一项都要求你保留一份“系统被攻破后依然可信”的记录。

预防失效后，还能依赖哪两类控制

遏制（Containment）：内核命名空间沙箱可以限制注入指令能触碰的资源范围，无论模型做出什么决定。沙箱能控制破坏后果，但没法告诉你注入是否已经发生。

代理之外的记录：签名执行收据（signed execution receipt）是一份包含输入、输出、时间和沙箱策略的权威记录。它用SHA-256哈希保存，并使用沙箱进程永远接触不到的ed25519私钥签名。代理既写不了它，也改不了它。第三方无需进入你的系统，就能离线验证——一条 traceseal-verify receipt.json 命令即可。

这些措施都不能阻止注入，但能让事后追责变成可能。假如你怀疑上周二发生过一次入侵：代理当时读了什么？碰过哪些东西？你能在一个没有理由完全信任你的人面前，把这些问题证明清楚吗？

想让注入可追责，日志该记下什么

值得停下来想一想：如果你的某个代理上周读过一份带毒文档，你是从自己的记录里发现这件事，还是从最终拿到数据的人那里才知道？

关键要点

查看原文