Deep Water research

DeepTest agent-indirect-prompt-injection defensive research (zh)

Write a thesis-sized defensive research report in Chinese for DeepTest on: Indirect prompt injection against tool-using agents. Topic id: agent-indirect-prompt-injection. Technique card: agent-indirect-prompt-injection. Related defensive guide ids: guide-agent-indirect-prompt-injection. Scope and safety: lawful authorized API penetration testing and secure agent review only. Do not provide exploit payload libraries, stealth guidance, credential theft workflows, persistence, malware, or instructions for unauthorized third-party targeting. Required structure: executive summary; conceptual attack anatomy; prerequisites; affected assets and trust boundaries; common root causes; safe lab validation objectives; detection signals; logs and telemetry; mitigations; remediation tasks; regression-test ideas; report-writing checklist; control mappings; residual risk; references. Make the report suitable for conversion into DeepTest local skills, technique cards, guide checks, MCP report tasks, remediation tasks, and PDF report sections.

Jun 27, 2026127 sources reviewed

执行摘要 (Executive Summary)

本报告针对大规模语言模型（LLM）代理系统中的**间接提示注入（Indirect Prompt Injection, IPI/IDPI）**威胁进行了深度防御性分析。随着代理系统从单纯的文本生成演变为具备工具调用（Tool-using）和环境交互能力的复杂架构，间接提示注入已成为破坏代理系统完整性的核心威胁。

基于严格的行业文献和学术研究，本报告的核心发现与建议如下：

  • 威胁机制本质：间接提示注入是指攻击者将恶意指令隐藏在代理处理的外部内容（如网页、文档或API数据）中，诱导代理在不知情的情况下执行未经授权的有害操作 [1], [3]。其核心漏洞在于“语义鸿沟（Semantic Gap）”，即系统提示词与不可信用户输入共享相同的自然语言格式，导致模型无法区分数据与指令 [9], [30]。
  • 信任边界的崩溃：LLM 会将所有输入流（包括检索内容、系统提示和用户输入）置于同一个上下文窗口中处理，且未能为每个 Token 提供信任级别注释，从而彻底破坏了用户、AI 及数据源之间的信任边界 [11], [12]。
  • 高危工具与传播路径：执行基于 URL 的信息获取工具极易受服务器端请求伪造（SSRF）攻击的利用 [8]；在多代理（Multi-agent）架构中，此类威胁更可能通过 AI 编排器代理（Orchestrator Agent）向外围专用代理级联传播 [34]。
  • 纵深防御与合规建议：必须采取包含概率性与确定性控制的纵深防御方法 [32]。建议结合 NIST AI RMF（治理、映射、测量、管理）框架 [31], [33]，实施结构化提示词分隔 [22]、严格的最小权限原则 [23]、细粒度的代理身份审计日志 [14] 以及自动化的提示词回归测试 [20]。

1. 攻击解剖与概念基础 (Conceptual Attack Anatomy)

1.1 什么是间接提示注入？

间接提示注入（Indirect Prompt Injection, 简称 IPI 或 IDPI）是一种隐蔽的 AI 安全威胁。当攻击者将恶意指令或被篡改的内容嵌入到外部内容（如网页、文档、电子邮件、代码库，甚至表情符号、图像和视频）中，且这些内容随后被基于 LLM 的代理摄取时，代理会错误地将这些隐藏指令解释为系统命令并执行 [3], [5], [7]。

与传统的直接提示注入不同，在间接注入场景中，用户从未直接向系统发送过恶意提示词，而是代理通过其环境交互行为（如网页浏览或 RAG 检索）自动提取并触发了这些有害负载 [6]。

1.2 攻击执行的解剖结构

一次成功的针对工具使用代理的间接提示注入（XPIA）通常包含以下阶段，其最终目的是覆盖代理的预期行为并执行有害命令 [4]：

  1. 负载植入：攻击者在 LLM 可能会访问的外部数据源（受信任或不受信任的来源）中部署恶意指令。
  2. 上下文摄取：代理在执行合法任务（如总结网页、查询 API）时，将包含恶意负载的数据提取至其上下文窗口中。
  3. 指令混淆与覆盖：LLM 消化输入时，外部数据中的指令与系统原始提示词发生冲突。由于缺乏执行上下文的隔离，模型被误导，优先服从了外部数据的指令。
  4. 工具调用（Payload Execution）：代理利用其集成的外部插件或工具执行指令，例如通过消息工具窃取敏感信息，或执行未授权的金融交易，从而对物理或数字资产造成直接损害 [1], [17]。

2. 受影响的资产与信任边界的破坏 (Affected Assets and Trust Boundaries)

2.1 信任边界的彻底瓦解

间接提示注入本质上暴露了当前 LLM 应用程序背后的信任模型缺陷 [10]。传统的软件安全依赖于清晰的数据与代码隔离（如 SQL 预编译），但在 LLM 代理中，这一边界不复存在。

间接提示注入从根本上打破了用户、AI 与其数据源之间的信任边界 [11]。由于代理系统的架构设计，检索到的外部内容、系统提示、历史记忆和当前用户输入这四个信息流，最终都会汇入同一个上下文窗口，并由同一个模型读取 [12]。

2.2 Token 级别的信任缺失

当前主流 LLM 的底层 Transformer 架构在读取上下文时，不会接收到每个 Token 的信任级别注释（Trust-level annotation per token） [12]。模型仅基于汇聚后的整体信号来预测下一个 Token，导致原本应被视为“被动数据”的外部文本，被模型赋予了“主动指令”的执行权重。

受影响的资产不仅包括底层的 LLM 模型，还广泛涉及：

  • 工具与插件（Tools/Plugins）：如邮件发送、数据库查询等被滥用的执行引擎。
  • 检索增强生成（RAG）知识库：遭受污染的文档集。
  • 下游集成系统：通过 API 与代理相连的内部微服务或物联网（IoT）智能家居设备 [1]。

3. 常见的高危工具使用模式与先决条件 (Prerequisites & Vulnerable Tool Patterns)

在代理授权渗透测试中，需重点关注以下极易被 IPI 利用的工具模式：

3.1 基于 URL 的信息获取与 SSRF 风险

执行信息获取的工具（尤其是允许用户或代理指定 URL 的函数调用）极易受到服务器端请求伪造（SSRF）攻击 [8]。当代理摄取了包含内部网络终端地址的恶意指令后，若工具未实施严格的网络出站过滤，代理将被迫向通常无法访问的内部网络或云元数据服务发起请求。

3.2 多代理架构（Multi-Agent）中的任务传播

在现代复杂的 AI 系统中，多代理架构日益普及。这种架构通常由一个**AI 编排器代理（Orchestrator Agent）**负责指导和同步多个专用代理 [34]。 一旦编排器代理在规划阶段通过外部环境摄取了注入指令，它可能会在分解任务时，将恶意负载作为“合法子任务”分发给下游的高权限专用代理。这种级联效应使得间接提示注入在多代理系统中具有极高的传播风险。

工具/架构模式 间接提示注入风险机制 潜在危害
网页浏览/抓取插件 被动摄取被植入恶意指令的第三方网页 [6] 劫持当前会话、钓鱼欺诈
URL 请求执行器 代理构造未经授权的 HTTP 请求访问内网 [8] SSRF、内网侦察、凭据窃取
API 调用网关 代理将恶意输出作为参数传递给插件执行 [17] 数据泄露、未授权金融交易 [1]
AI 编排器 (Orchestrator) 编排器将恶意指令解析为系统目标并下发 [34] 全系统级行为覆盖、权限横向移动

4. 根本原因分析：数据与指令的混合问题 (Common Root Causes)

间接提示注入无法通过简单的关键词过滤解决，因为其根本原因深植于 LLM 的底层处理逻辑中。

4.1 “语义鸿沟 (Semantic Gap)”

OWASP 明确指出，引发提示注入攻击的核心漏洞可以被称为**“语义鸿沟”** [30]。这种鸿沟的产生，是因为系统提示词（开发者指令）和用户输入/外部数据（新指令）都共享相同的基本格式：自然语言纯文本字符串 [9], [30]。

模型没有可靠的内置机制来区分哪段纯文本来自受信任的开发者，哪段文本来自不受信的用户或外部环境 [9]。只要文本在语义上构成了一个连贯且强有力的指令序列，模型就有可能将其采纳为当前的最高优先级任务。在缺乏有效隔离机制的环境下，这种基于指令流氓劫持的攻击是不可避免的。

5. 安全实验室验证与测试目标 (Safe Lab Validation Objectives)

对于 DeepTest 等深度防御平台，构建受控的实验室验证实验是评估代理系统韧性的关键。测试范围仅限于合法的授权 API 渗透测试和安全的代理审查。

5.1 架构审查与攻击面映射

实验室验证必须从全面的架构审查开始。安全分析师必须准确绘制攻击面，识别所有 LLM 会处理的输入，包括直接输入（如系统和用户提示）以及间接输入（如训练数据、RAG 向量源） [15]。 测试前需详细记录 LLM 可以访问的每一个数据源，识别模型检索和处理外部内容的所有位置，并绘制信任关系图谱：明确模型将什么视为权威指令，将什么视为不可信输入 [16]。

5.2 受控负载测试目标

在实验室验证中，核心目标是测试输入提示是否能够操纵 LLM 生成特定的恶意负载，并观察该负载是否随后被代理的插件成功执行 [17]。 如果代理与外部服务之间的接口未经过适当清理和保护，攻击者将通过注入攻击接管 LLM 的输出，从而对外部服务行使超出预期的控制权 [17]。验证应重点关注：

  1. 指令逃逸测试：构造含有隐藏指令的无害文档，验证代理在阅读文档后是否改变了原定的系统目标。
  2. 工具参数污染测试：验证代理是否会将注入文本直接作为变量传递给数据库查询或 API 请求（如验证是否触发了注入型 SSRF 或 SQLi）。

6. 检测信号与遥测分析 (Detection Signals)

由于间接提示注入发生在模型的推理阶段且表现为自然语言交互，传统的基于静态签名的网络应用防火墙（WAF）难以直接捕获。必须采用针对 LLM 语义的专门检测手段。

6.1 结构化句型与语义词汇分析

研究表明，检测间接提示注入的一个有效途径是分析特定的结构化句型和具有针对性语义的词汇 [2]。

  • 启发式特征工程：每种直接或间接提示注入方法都会表现出特定的显式模式（Explicit patterns）。例如，使用诸如“忽略之前的指令（Ignore previous instructions）”等具有特定语义的词汇，或者呈现出打破当前对话结构的特殊句型 [2]。
  • 异常行为偏离：监控代理回复中是否突然出现与其系统设定不符的语气转换、语言切换或拒绝执行原始任务的声明。

6.2 代理记忆模块的异常分析

在 LLM 代理架构中，**记忆模块（Memory module）**负责存储代理的内部日志，包括过去的思考（Thoughts）、行动（Actions）以及来自环境的观察结果（Observations），覆盖代理与用户之间的所有交互 [18]。 监控工具必须实时分析记忆模块中的数据。如果“思考”日志中出现了凭空产生的任务目标，或“观察”日志中记录了包含大量命令语气的外部文本，这通常是 IPI 正在发生的强信号。

7. 日志与遥测数据要求 (Logs and Telemetry)

全面的可观察性（Observability）和身份审计是审查代理安全威胁的基础设施。

7.1 工作流跨度追踪（Workflow Spans）

在复杂的工具使用代理中，一个请求可能触发多轮思考和多个 API 调用。集成诸如 Datadog LLM Observability 等可观察性工具至关重要，它提供了一种易于使用的机制，能够细粒度地检查 LLM 工作流中的每一个单独的执行跨度（Span） [13]。通过查看 Span，安全团队可以精确定位恶意指令是在哪一次外部检索中被引入上下文的。

7.2 身份与行为审计日志

为进行深入的取证分析和安全监控，代理身份与行为的全面日志记录不可或缺 [14]。

  • 防篡改记录：必须为代理的每一项操作创建全面、不可更改的记录。
  • 细粒度追踪：代理进行的每一次 API 调用、数据访问请求以及决策过程，都必须被准确记录，并能追溯到其经过身份验证的代理身份 [14]。只有这样，在发生由 IPI 导致的越权调用时，才能快速进行损害评估。

8. 防御间接提示注入的缓解策略 (Mitigations)

缓解 IPI 需要采取跨越概率性（Probabilistic）与确定性（Deterministic）控制的纵深防御策略（Defense-in-depth） [32]。目前没有任何单一机制可以 100% 消除该漏洞，但以下组合策略能大幅降低风险。

8.1 提示词防护盾 (Prompt Shields)

在请求到达核心 LLM 之前，部署独立的安全分类模型或“提示词防护盾”。这些工具专门用于分析和清理传入的提示，以检测并中和潜在的注入尝试 [25]。

8.2 结构化接口与分隔符强制执行

为了减少模型对指令与数据的混淆，应创建结构化接口或提示词模板，限制用户（或环境数据）将自由格式文本注入敏感上下文的能力 [26]。

  • 分隔符标记：在系统提示词与不受信输入之间强制执行结构化分隔。例如，将外部数据包裹在特定的标记符（如 <<<USER_INPUT>>> 和 <<<END_USER_INPUT>>>）中，这能显著帮助模型区分系统指令和外部内容 [22]。

8.3 最小权限原则 (Principle of Least Privilege)

虽然限制权限本身不能直接防止提示注入攻击的发生，但实施最小权限原则可以极大限制攻击成功后所造成的破坏范围 [23]。

  • 组织应仅授予 LLM 及其相关 API 执行当前任务所需的最低权限 [23]。
  • 工具调用应要求人工环路验证（Human-in-the-loop），尤其是对于涉及财务操作、敏感数据修改等高危插件操作。
缓解策略类型 具体实施机制 防御层面
确定性 (Deterministic) 强制结构化分隔符 (<<<DATA>>>) [22] 提示词工程/输入格式化
确定性 (Deterministic) 对高权限 API 实施最小权限访问控制 [23] 代理身份/工具权限
概率性 (Probabilistic) 部署 Prompt Shields 扫描器过滤恶意载荷 [25] 请求网关/预处理层
结构化 (Structural) 限制自由格式文本输入的模板引擎 [26] 应用程序接口层

9. 补救任务与数据卫生 (Remediation Tasks)

在识别出 IPI 漏洞后，修复工作不仅涉及代码更改，还需覆盖整个数据管道的卫生（Hygiene）。

9.1 数据集与检索语料库验证

开发团队在将数据用于微调（Fine-Tuning）或作为 RAG（检索增强生成）数据集摄取之前，必须执行严格的内容验证 [24]。

  • 微调卫生 (Fine-Tuning Hygiene)：清洗训练预料，移除可能导致后门或条件触发恶意行为的毒性文本 [24]。
  • RAG 数据清洗：在将外部网页或文档向量化存入数据库前，使用消毒器（Sanitizer）去除隐藏在 HTML 注释、不可见字符或白色字体中的恶意指令。

10. 提示词回归测试架构 (Regression-Test Ideas)

为了确保代理系统在迭代过程中的安全性，必须建立自动化且幂等的**提示词回归测试（Prompt Regression Testing）**体系。

10.1 回归测试的核心定义

提示词回归测试是一种工程实践：每当代理的提示词、底层模型版本或工具配置发生变更时，都需要针对该 AI 代理重新运行一组固定的评估用例（Fixed set of evaluation cases） [20]。 通过回归测试可以回答一个核心问题：“在给定相同输入的情况下，我是否仍然能获得符合预期契约（即包含特定结构、风格和安全约束）的输出？” [21]。

10.2 实现幂等性（Idempotency）的要素

为了在提示词驱动的应用程序测试中实现幂等性（确保测试结果的可重复性），必须使用带日期标签的模型检查点（Dated model checkpoints），而不是通用的模型别名（如 gpt-4） [19]。通用别名会在后台被重定向更新，这可能会破坏回归测试的基准线。

11. 防御研究报告与合规审计检查清单 (Report-Writing Checklist)

在编写针对代理安全架构的深度审计和防御报告时，研究人员应覆盖以下合规与治理控制点：

  • AI 伦理与风险委员会设立情况：审查组织是否建立了一个生成式 AI 伦理委员会，来管理伦理政策和缓解生成式 AI 风险。据统计，目前仅有 47% 的企业建立了此类委员会 [27]。
  • 集中式治理基线：审查所有 AI 代理是否都遵循了一个强制执行且集中化的治理和安全基线，并与现有的身份验证、数据治理和安全实践保持一致 [29]。
  • 工具与 API 权限矩阵：映射所有代理可用的工具列表，并交叉比对身份权限 [23]。
  • 输入输出清理机制：评估是否部署了提示盾及格式化模板 [25], [26]。

12. 控制映射与行业合规标准 (Control Mappings)

间接提示注入防御必须与国际公认的框架建立映射，以满足企业风险合规要求。

12.1 OWASP Top 10 for LLM Applications

在最新的 OWASP 大模型应用安全 Top 10 列表中，提示注入被分类为首要安全风险：

  • LLM01: Prompt Injection（提示注入）。攻击者通过精心设计的输入操纵 LLM，可能导致未经授权的访问、数据泄露及决策受损 [28]。

12.2 NIST AI RMF (AI 风险管理框架)

美国国家标准与技术研究院发布的 NIST AI RMF (NIST AI 100-1) 是一个自愿性框架，旨在管理 AI 生命周期的各类风险 [31]。它由四个核心功能模块组成，组织可将其直接应用于 IPI 防御 [31], [33]：

  1. Govern (治理)：框架的核心连接组织。涉及企业文化、安全监督、问责制、角色定义及政策（如建立 AI 治理基线 [29]）。
  2. Map (映射)：提供上下文和框架。了解代理系统在何处运行，绘制信任边界 [16]，并识别该环境上下文带来的间接输入风险。
  3. Measure (测量)：分析功能。对安全风险进行评估、基准测试（包含上述的回归测试 [20]）及持续监控。
  4. Manage (管理)：执行功能。实施诸如最小权限、提示盾拦截等具体的纵深缓解策略 [32]。

13. 残余风险与局限性 (Residual Risk & Limitations)

尽管实施了包括隔离、严格格式化和最少权限在内的全面控制，针对工具使用代理的间接提示注入攻击仍然存在显著的残余风险。

  1. 权限限制的局限：实施最小权限原则虽然能限制损害规模，但无法从根本上防止提示注入的发生 [23]。如果代理被授权代表用户撰写邮件或总结机密报表，攻击者仍可利用 IPI 操纵代理将这些特定范围内的机密数据泄露（如外发给攻击者控制的邮箱）。
  2. 多代理黑盒效应：在多代理协同网络中，AI 编排器可能将恶意意图转化为极其细微的子任务分发 [34]。当前的可观察性工具（如追踪 Span）在面对极高复杂度的级联推理时，可能会遇到语义解析层面的“噪音”过载，使得细粒度防御失效。
  3. 未知的自然语言对抗样本：由于“语义鸿沟”仍未从 Transformer 架构底层消除 [30]，随着模型能力的进化，攻击者可能通过更高级的修辞手法绕过现有的句法特征扫描 [2]。目前业界缺乏完全确定性、零误报的“数据/指令”底层硬件级分离方案。

14. 参考文献 (Sources)

Source Quality Summary: Evidence draws on 2 academic sources, 29 professional/industry sources, and 3 general web/community sources.