Deep Water research

DeepTest agent-insecure-output-handling defensive research (zh)

Write a thesis-sized defensive research report in Chinese for DeepTest on: Insecure handling of model outputs in agentic systems. Topic id: agent-insecure-output-handling. Technique card: agent-insecure-output-handling. Related defensive guide ids: guide-agent-insecure-output-handling. 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, 2026162 sources reviewed

1. 执行摘要 (Executive Summary)

本报告针对代理系统（Agentic Systems）中“模型输出不安全处理”这一核心安全漏洞，提供了企业级的防御性研究与架构审查指南。随着大型语言模型（LLM）从单纯的文本生成器演变为能够执行系统级操作的自主代理，输出处理的安全性已成为系统防御的决定性环节。

核心发现与建议如下：

  • 零信任输出原则：在代理系统中，所有的模型输出都必须被视为不可信的用户输入 [30]。由于开发者普遍存在将 LLM 视作“内在安全”的错误假设 [9], [11]，导致未经验证的模型输出直接进入下游系统，从而引发跨站脚本（XSS）、命令注入乃至远程代码执行（RCE）等严重漏洞 [1], [7], [33]。
  • 信任边界重构：传统的边界模型已失效。安全的代理架构必须建立明确的“行动边界（Action Boundary）” [4]，并引入后端网关（Gatekeeper）以拦截和验证模型意图 [6]。
  • 深度防御策略（Defense-in-Depth）：单纯依赖提示词工程（Prompt Engineering）无法抵御复杂的注入攻击。必须结合类型安全协议（如 JSON 结构化约束） [3], [14]、基于 RBAC 的工具级鉴权 [5], [34] 以及操作系统级的轻量级沙箱隔离 [26] 来限制爆炸半径。
  • 授权控制的解耦：鉴权逻辑不应依赖模型自身的判断。工具服务器（Tool Server）必须独立返回结构化的允许/拒绝响应，而不受模型提示词的干扰 [35]。

本报告可直接转换为 DeepTest 的本地测试技能库（Local Skills）、技术卡片（Technique Cards）以及安全审计检查清单。

2. 核心概念与威胁模型 (Core Concepts & Threat Model)

2.1 漏洞定义

模型输出不安全处理（Insecure Output Handling）是指在大型语言模型生成的输出被下游组件处理或呈现给用户之前，缺乏充分的验证、清理（Sanitization）和管理 [8]。OWASP 将其定义为 LLM 应用程序十大安全风险之一（LLM02），指出忽视对输出的验证可能导致下游安全漏洞，包括系统代码执行和数据泄露 [22]。

在传统的 Web 应用中，这种漏洞表现为模型输出包含恶意脚本并被前端直接渲染 [10]。例如，向 LLM 提交包含 <img src=1 onerror=alert(1)> 的字符串，若系统未对输出进行转义，将直接触发跨站脚本（XSS）攻击 [7]。

2.2 代理系统中的威胁放大

在代理系统（Agentic Systems）中，这一威胁被呈指数级放大。代理系统不仅生成文本，还通过调用外部 API 和系统函数来实现真实世界的物理或数字效果。OWASP LLM05 强调，在代理系统中，必须将所有的模型输出视为不可信的用户输入，否则恶意输出将直接转化为恶意指令 [30]。如果代理系统在缺乏鉴权、访问控制或沙箱保护的情况下调用外部工具，攻击者可通过提示词注入（Prompt Injection）操纵 LLM 使用恶意参数调用工具 [34]。

3. 概念性攻击剖析 (Conceptual Attack Anatomy)

针对代理系统输出不安全处理的攻击通常遵循以下概念性执行链：

  1. 注入载荷（Input/Prompt Injection）：攻击者通过合法通道（如用户聊天窗口、被污染的网页内容、恶意文档）输入精心构造的对抗性提示词。
  2. 模型意图劫持（Intent Hijacking）：LLM 在处理上下文时，被对抗性提示词误导，将攻击者的指令视为系统级指令。
  3. 不安全的输出生成（Malicious Output Generation）：模型生成包含恶意载荷的工具调用指令（如请求执行系统 Shell 命令或向未授权 API 发起 HTTP 请求）。
  4. 参数注入与人工绕过（Argument Injection & HITL Bypass）：攻击者利用预先批准的合法命令，通过参数注入（Argument Injection）的方式绕过“人在回路（Human-in-the-Loop, HITL）”的安全检查 [33]。
  5. 下游执行（Downstream Execution）：代理工作流未对模型的输出进行结构化验证或清理，直接将其传递给代码解释器或操作系统，导致远程代码执行（RCE）或特权提升 [33]。

4. 攻击前提条件 (Prerequisites)

要使输出不安全处理漏洞被成功利用，通常需要满足以下一个或多个前提条件：

  • 开发者的过度信任：漏洞的根源通常在于开发者错误地将 LLM 输出视为安全的，忽略了强大的清理机制的必要性 [9], [11]。
  • 工具端鉴权缺失：模型在调用外部工具时，工具服务器缺乏独立的访问控制策略评估（Policy Evaluation）。如果安全策略仅仅作为建议文本放在 LLM 的提示词中，它很容易被绕过 [35]。
  • 权限配置过度（Over-permissive Identities）：运行代理或自定义训练任务的服务账户被授予了超出所需的权限。例如，在 Vertex AI 中，如果自定义训练任务的默认服务代理对云存储和 BigQuery 数据集拥有过多权限，将导致模型泄露或特权提升 [32]。
  • 缺乏执行前验证：在代理生成的动作被执行或呈现给用户之前，未进行任何形式的验证 [13]。

5. 受影响资产与信任边界 (Affected Assets and Trust Boundaries)

在基于代理的架构中，准确界定信任边界对于防御至关重要。信任边界可以通过自动化的威胁建模（如分析数据流、系统架构和基于角色的访问控制 RBAC）来明确识别 [5]。

5.1 行动边界 (The Action Boundary)

行动边界控制着代理对现实世界产生影响的能力。安全架构必须明确界定：代理是只能提供建议、可以起草但不能发送、还是能够直接更新记录？哪些高影响力的变更必须需要明确的人工批准？[4]

5.2 后端网关模式 (Backend Gatekeeper)

一个安全的代理系统应当在后端应用层设定物理的信任边界。后端应用作为网关（Gatekeeper），负责确定用户输入提示词的意图，随后将请求及衍生出的意图转发给路由机器人微服务，而不是让 LLM 直接与所有后端微服务交互 [6]。

受影响资产清单：

  • 代码解释器/沙箱环境：直接执行模型输出的核心资产。
  • 内部 API 与数据库：被代理调用的业务系统。
  • 云基础设施底座：如云服务提供商（CSP）的对象存储、计算实例（若服务代理权限过大 [32]）。

6. 常见的根本原因 (Common Root Causes)

结合工业界和学术界的研究，输出处理不当的根本原因可归结为以下三点：

  1. 架构认知偏差：开发者未能将 LLM 视为基于概率的模式匹配机器（基于数据模式生成文本），错误地认为其输出是具备确定性和固有安全性的 [11]。
  2. 验证环节前置不足：仅在输入阶段进行过滤，而未在执行阶段（输出阶段）实施拦截。不安全的输出处理本质上是在输出被下游组件处理前，缺乏充分的验证、清理和过滤 [8], [10]。
  3. 安全控制耦合：将安全检查机制（Guardrails）与业务 LLM 强绑定，未进行物理或逻辑隔离。若攻击者突破了业务 LLM，安全检查机制随之失效。

7. 防御性实验室验证目标 (Safe Lab Validation Objectives)

在进行合规的授权 API 渗透测试及安全代理审核时，验证目标应侧重于架构的弹性和配置的最小特权原则，而非开发破坏性利用链。

  1. 执行接收器分析（Execution Sinks Analysis）：审计人员必须对代理系统的执行接收器进行面向证据的检查（Evidence-oriented checks），包括权限边界评估、持久化风险评估以及潜在的“金融爆炸半径”测试 [24]。
  2. 工具权限审计（Tool Permission Auditing）：针对企业应用中的 LLM 安全测试，应评估代理工具（Tools/Functions）是否允许了不必要的访问或操作 [12]。
  3. 人类批准绕过验证（HITL Bypass Testing）：验证是否存在通过参数注入来操纵预先批准的命令，从而执行未授权操作的风险 [33]。

8. 检测信号、日志与遥测 (Detection Signals, Logs & Telemetry)

针对代理系统内部执行的遥测监控，传统的基于日志的 SIEM 分析方法在面向 LLM 代理时存在严重局限。

8.1 内部轨迹的可观测性 (Observability into Trajectories)

评估代理系统的可靠性和安全性时，不能仅看最终输出结果。必须构建针对代理“内部轨迹（Internal Trajectory）”的可观测性，这包括：输入提示词、模型做出的工具调用请求以及中间状态的输出 [20]。测试人员应将执行轨迹作为判断系统正确性与安全性的主要单元 [20]。

8.2 遥测数据被“智能截断”的风险 (Log Deprioritization)

向 LLM 直接输入系统日志以发现威胁是危险的。代理在依赖原始日志摘要进行分析时，往往难以确定调查线索的优先级。例如，在应对“离地攻击（Living-off-the-Land, LOTL）”时，LLM 看到 powershell.exe 或 svchost.exe 会认为它们是合法的系统二进制文件从而降低其风险权重，却去追踪不相干的未知程序 [18]。因此，在监控模型是否正在处理恶意输出时，必须保留人类专家设定的基于规则的警报，而不是完全交由另一个 LLM 进行日志裁决。

9. 架构缓解与防御模式 (Architectural Mitigations & Defense Patterns)

为防止模型输出造成系统级危害，应在架构层面引入以下防御模式：

9.1 动作选择器模式 (Action Selector Pattern)

该模式是缓解提示词注入导致恶意输出的最有效架构之一。在此模式下，系统将 LLM 作为一个“路由器”对待。LLM 的唯一输出是一个工具调用指令（Tool Call），并且该调用必须属于预定义的允许操作列表。任何由 LLM 生成的自然语言文本都不会展示给用户，且 LLM 永远看不到其所调用工具的返回结果（闭环隔离）[16]。

9.2 工具级硬性策略评估 (Tool-Level Policy Evaluation)

在工具调用中缺失鉴权会极大加剧风险 [34]。缓解这一风险的核心是：绝对不能在 LLM 的提示词中评估安全策略，因为攻击者精心设计的提示词可以覆盖这些建议性文本。工具服务器（Tool Server）端必须独立进行鉴权，并无视代理的指示，严格返回结构化的允许（Allow）或拒绝（Deny）响应及状态码 [35]。

9.3 专用的对抗性提示评估器 (Adversarial Prompt Evaluator)

引入一个独立的、专门设计的 LLM（或小型分类模型）作为提示评估器（Prompt Evaluator），将其部署为独立的代理，专门负责标记和拦截对抗性提示词，从而防止业务主模型生成有害输出 [21]。

10. 输入验证与输出沙箱化的权衡 (Trade-offs: Input vs. Output Sandboxing)

在企业级部署中，防止代理执行恶意操作的最常见方法是人工审批（Manual Approval）和输出沙箱化（Sandboxing）。两者的权衡如下：

防御策略 优势 劣势与剩余风险
人工审批 (Manual Approval) 提供最高级别的业务确认，技术实现成本极低。 导致开发者摩擦（Developer Friction），极易引发用户的“习惯化（Habituation）”疲劳，导致用户在不审查的情况下盲目批准潜在的危险操作 [28]。
应用层输入/输出过滤 开销小，能够防御已知的特定词汇或正则表达式匹配的恶意载荷。 无法抵御复杂的编码攻击或逻辑绕过，对于参数注入等未知模式防护能力弱。
操作系统级沙箱 (OS-level Sandboxing) 共享宿主内核，启动开销低，可严格限制文件系统视图、环境变量和系统能力 [26]。 仍可能面临内核提权漏洞的威胁。
全面隔离与声明式沙箱 (如 Nix/VM) 使用 Nix 等工具提供声明式的安全规则限制，将 AI 代理部署在极其受限的环境中，赋予自主权的同时保护核心系统 [25], [29]。跨架构隔离（如在 ARM 主机上通过 Rosetta 2 运行 Intel 容器的虚拟机 vmOpts: vz: rosetta: enabled: true, binfmt: true）提供硬件级防护 [27]。 增加了基础设施管理的复杂性和计算开销。需要复杂的网络配置以允许必要的 API 通信。

11. 类型安全协议与结构化输出 (Type-safe Protocols & Structured Output)

未经验证的自由文本是代理安全的大敌。使用类型安全的协议和解析器是规范模型输出的重要防线。

11.1 JSON 模式 (JSON Mode)

强制模型使用 JSON 模式进行工具调用。JSON 模式通过修改模型的采样过程（Sampling Process），限制其仅考虑能够保持有效 JSON 语法的 Token [14]。这种方法确保了模型响应能够精确遵守预期的输出数据结构 [3]。

11.2 输出解析器集成 (Output Parser Integrations)

使用成熟的框架（如 LlamaIndex）来强制执行结构化输出解析。这些框架提供了专门的模块，能够为任何提示词提供格式化指令（output_parser.format），并对模型的输出进行强类型反序列化（output_parser.parse），一旦输出不符合预期结构，系统将在执行前抛出异常从而阻断执行链 [15]。

12. 修复与整改任务清单 (Remediation Tasks)

当在代理系统中发现不安全的输出处理机制时，应根据优先级执行以下整改任务：

  • 高优先级：将所有解释器和执行后端移至专用的沙箱环境中（如通过限制文件系统视图和内核 Capabilities 的 OS 级容器）[26]。
  • 高优先级：在工具服务器端（Tool Server）实施独立的鉴权逻辑和 RBAC。拒绝依赖 LLM 将鉴权状态作为参数传递 [5], [35]。
  • 中优先级：强制所有工具调用使用 JSON Mode 及强类型验证（如 Pydantic Schema），废弃所有使用正则表达式提取自由文本中命令的逻辑 [3], [14]。
  • 中优先级：检查所有代理所使用的云服务标识（如 Vertex AI 的自定义任务服务代理），遵循最小特权原则移除对存储桶和数据仓库的不必要写/读权限 [32]。
  • 低优先级（纵深防御）：实施动作选择器模式（Action Selector），确保前端完全屏蔽包含工具执行反馈的 LLM 原始对话输出 [16]。

13. 回归测试策略 (Regression-test Ideas)

为了确保修复措施在未来的迭代中不被破坏，必须设计针对代理系统的自动化回归测试。

  • 利用 Agentic Testing 进行自愈回归：部署 Agentic Testing 工具。此类工具不仅能生成涵盖复杂工作流和边界情况的自动化测试脚本 [19]，还能在 UI 或 API 发生非功能性变更时自动“自愈（Self-healing）”测试脚本，从而在极低的维护成本下运行全面的回归套件 [17]。
  • 对抗性 OWASP 自动化扫描：集成开源测试工具（如 Promptfoo），并在插件页面选择 OWASP LLM Top 10 预设。这些插件专门生成针对 LLM02 (不安全输出处理) 等分类的对抗性输入，持续验证防线 [23]。
  • 轨迹断言测试：在持续集成（CI）流水线中，不仅断言最终输出结果，还必须断言代理执行的轨迹。例如，编写测试用例验证：当注入 rm -rf / 指令时，断言模型生成的轨迹被系统在解析（Parse）层或权限（Policy）层成功拦截 [20]。

14. 报告撰写与安全审计检查表 (Report-writing Checklist)

在为客户撰写安全代理审核报告时，报告应涵盖以下关键维度 [24]：

  1. 证据导向（Evidence-oriented）：避免纯理论的漏洞描述，需提供如“通过参数注入绕过审计日志记录”的详细漏洞复现证明 [33]。
  2. 执行接收器详述（Execution Sinks Focus）：清楚地列出系统中所有能够接收并执行代理指令的节点（如 Shell 解释器、数据库 SQL 引擎、MCP 协议端点）。
  3. 权限边界评估（Authority Boundaries）：记录代理可以访问的 API 的确切范围。
  4. 持久化风险评估（Persistence Risk）：评估模型是否能通过恶意输出修改系统配置，导致后门长期存在。
  5. 爆炸半径与财务影响（Financial Blast Radius）：特别是对于 Agentic DeFi 系统，需评估不安全的输出是否可能导致大规模资金转移 [24]。

15. 安全控制映射与合规性 (Control Mappings & Compliance)

  • OWASP 映射：本报告讨论的防御措施直接应对 OWASP LLM Top 10 中的 LLM02（不安全输出处理） [22] 及 LLM05（不当输出处理的代理场景延伸） [30]。
  • 欧盟 AI 法案 (EU AI Act) 合规：根据法案要求，高风险 AI 系统在投入市场前，必须实施充分的“风险评估与缓解系统（Risk Assessment and Mitigation Systems）” [2]。对代理系统的强制沙箱化和独立的工具级策略控制正是满足此要求的技术实现途径。
  • 治理策略与约束：自主代理必须在既定的政策和约束（Constraints and Policies）内运作。企业需对安全检查（Guardrails）、监管合规和访问权限进行硬编码（Hardcode）规范，不可将其交由模型动态判断 [31]。

16. 剩余风险评估 (Residual Risk)

在实施了严格的输入验证、类型安全解析以及底层沙箱化之后，代理系统仍存在以下剩余风险（Residual Risk）：

  1. 人工审批的习惯化（User Habituation）：即便采用了 HITL 机制，如果代理频繁请求操作，开发人员或操作员可能因疲劳而盲目批准高危动作，从而将安全防线失效 [28]。
  2. 供应链层面的云服务提权：如果代理依赖的云原生环境底层（如模型训练/推理的默认服务账号）自身存在配置缺陷（如云存储权限过大 [32]），那么即使应用层的输出处理无懈可击，攻击者仍可利用业务逻辑实现模型外泄或数据窃取。
  3. 合法工具的滥用（LOTL）：攻击者可能仅利用代理已经被完全授权且通过验证的合法工具（如合法的查询工具、邮件工具）进行恶意的数据拼装和窃取，这种逻辑层面的滥用很难被沙箱防范 [18]。

17. 局限性与开放问题 (Limitations / Open Questions)

  • 卡片证据的局限性：当前的引用主要涵盖了概念验证（PoC）、主流沙箱策略以及高级架构设计，但缺乏对特定底层运行时（如 Deno Deploy、AWS Lambda）在防御具体大模型非标准恶意输出时的性能损耗数据。
  • 多模态输出的处理缺失：当前防御体系绝大部分集中在基于文本和 JSON 格式的命令输出控制。若代理直接输出生成的音频指令（如声控欺骗）、图像（视觉提示注入响应）或编译后的二进制文件流，当前的 JSON 验证机制将面临失效。
  • 开放问题：如何在不大幅增加延迟的情况下，在微秒级别实时验证大语言模型产生的复杂多步骤工作流（Multi-step Trajectories）中的每一个中间状态输出的安全性？

18. 参考文献 (Sources)

Source Quality Summary: Evidence draws on 1 academic source, 1 government document, and 33 general/professional web sources (including cybersecurity blogs, framework documentation, and industry whitepapers) ensuring a robust blend of theoretical definitions and practical enterprise mitigation strategies.