不当输出处理原理详解：LLM 输出验证、清洗与执行风险控制
不当输出处理指 LLM 输出缺少验证、清洗、编码和控制。本文梳理 LLM 输出验证、浏览器脚本和系统级脚本风险，帮助开发者建立输出安全边界。
什么是不当输出处理？
不当输出处理，也称 Improper Output Handling，是指应用对大语言模型生成的输出缺乏充分的验证、清洗和处理。在 OWASP LLM05:2025 语境中，它被归入大语言模型应用的重要风险类型，关注点不是模型回答是否流畅，而是输出在被应用继续使用前是否经过安全处理。
更完整地说，不当输出处理还包括未能对 LLM 输出进行适当的验证、清洗、编码和控制。如果模型输出会进入浏览器页面、脚本、系统命令或后续业务流程，它就不应被当作普通文本直接信任。
要点： 不当输出处理不是单纯的内容质量问题。它描述的是 AI 生成内容在进入展示、调用或执行环节前缺少安全边界，因此可能转化为应用安全漏洞。
为什么 LLM 输出不能默认可信？
LLM 输出通常是应用链路中的中间结果，而不一定是最终结果。一个回答可能只是展示给用户，也可能被拼接到页面、传给工具、写入配置、生成脚本，甚至进入自动化执行流程。
当应用没有为 AI 生成内容设置安全测试和验证措施时，输出可能绕过原有的应用边界。尤其在缺少恶意意图验证的情况下，看似合理的内容，可能被下游组件解释为脚本、命令或操作指令。
可以先用三个问题判断风险：
- 这段输出只是作为纯文本展示，还是会被浏览器、脚本引擎或系统环境解释？
- 输出进入下一步之前，是否检查了格式、业务规则和安全意图？
- 应用是否对可执行内容设置了阻断、确认或其他控制机制？
风险如何从生成走向执行？
不当输出处理的风险通常不是在模型生成文本的一瞬间完成的，而是在应用接收、处理并传递输出的过程中逐步形成。可以把它理解为一条从生成内容到执行环境的链路。
| 环节 | 发生了什么 | 风险关注点 |
|---|---|---|
| 模型生成内容 | LLM 返回文本、代码片段、脚本或结构化内容 | 输出尚未经过应用侧安全判断 |
| 应用接收输出 | 应用把输出作为后续逻辑的输入 | 需要确认输出用途和上下文 |
| 缺少处理措施 | 没有充分验证、清洗、编码或控制 | 不安全内容可能继续传递 |
| 进入敏感环境 | 输出被渲染到浏览器，或被当作脚本、命令处理 | 文本可能变成可执行内容 |
| 形成实际风险 | 下游环境执行或解释了不应执行的内容 | 风险从内容层转为应用层或系统层 |
这里的关键是执行边界。普通文本展示与可执行内容处理的风险不同：如果输出只作为受控文本呈现，风险主要集中在内容展示；如果输出会被浏览器直接执行，或被系统作为脚本运行，风险就会明显上升。
输出验证、清洗、编码和控制分别做什么？
验证、清洗、编码和控制是 LLM 输出处理链路中的不同动作。它们解决的问题不同，通常需要组合使用，而不是互相替代。
| 处理动作 | 主要含义 | 适用判断问题 |
|---|---|---|
| 输出验证 | 判断输出是否符合预期格式、业务规则和安全意图 | 这段内容是否应该被接受？ |
| 输出清洗 | 移除或中和不应进入后续环节的危险内容 | 这段内容中是否包含不该继续传递的部分？ |
| 输出编码 | 降低内容在特定上下文中被解释为可执行指令的可能性 | 这段内容进入页面或其他上下文后，会不会被误执行？ |
| 输出控制 | 限制输出进入浏览器、脚本、系统命令等敏感执行路径 | 这段内容是否允许进入高风险环节？ |
例如，验证更关注是否符合规则，清洗更关注是否移除危险内容，编码更关注上下文解释方式，控制则关注输出能否进入敏感路径。对于生成式 AI 应用来说，输出验证是基础，但只做验证往往不足以覆盖所有执行场景。
两个典型案例帮助识别风险边界
两个常见案例可以帮助开发者识别不当输出处理的风险边界：一是要求 LLM 生成可被浏览器直接执行的 JavaScript 代码，二是直接运行 LLM 生成的系统级脚本。
| 场景 | 输出形态 | 风险边界 | 处理重点 |
|---|---|---|---|
| 普通文本展示 | 自然语言说明、摘要、建议 | 主要停留在内容展示层 | 检查内容是否符合业务规则和安全意图 |
| 浏览器 JavaScript | 可被页面环境解释的脚本 | 输出可能从文本变成浏览器可执行代码 | 在进入页面前进行验证、清洗、编码和执行控制 |
| 系统级脚本 | 命令、脚本、自动化操作内容 | 输出可能影响本机或服务器环境 | 避免直接运行，增加验证、安全测试和阻断机制 |
这两个案例的共同点是：模型输出不再只是给人阅读的文本，而可能被环境执行。只要输出具备被解释或运行的可能，就需要把它视为高风险输出类型进行处理。
开发者可以采用的检查清单
在设计生成式 AI 应用时，可以用以下清单检查是否存在不当输出处理风险：
- 确认 LLM 输出最终用途：展示、存储、拼接、调用工具，还是进入执行流程。
- 在输出进入敏感环节前增加验证，检查格式、业务规则和安全意图。
- 对 AI 生成内容设置安全测试和验证措施，避免输出绕过应用原有边界。
- 根据上下文选择清洗或编码方式，尤其关注浏览器页面、代码片段、脚本命令等场景。
- 对可执行输出设置明确控制，避免把 LLM 生成的 JavaScript 或系统级脚本直接交给环境运行。
- 对无法确定安全性的输出，优先阻断、降级为纯文本展示，或转入人工确认流程。
要点： 检查清单的核心不是禁止所有代码生成，而是区分生成、展示和执行。风险通常发生在应用把生成结果直接交给可执行环境时。
哪些生成式 AI 应用更需要关注？
凡是会把模型输出继续传递给浏览器、脚本、命令或业务流程的应用，都应重点关注不当输出处理。以下场景尤其需要建立输出验证与控制边界。
| 用户需求 | 解决方式 | 效果 |
|---|---|---|
| 将模型输出渲染到浏览器页面 | 在页面输出前进行验证、清洗和必要的编码 | 降低脚本内容被页面直接解释执行的可能性 |
| 让模型生成代码片段或自动化脚本 | 区分代码展示与代码执行，执行前增加检查和确认 | 避免把生成内容直接转化为实际操作 |
| 生成运维脚本、系统命令或配置操作 | 将系统级脚本视为高风险输出，限制直接运行 | 减少不安全输出影响本机或服务器环境的风险 |
| 将输出接入后续工具或业务流程 | 在工具调用或流程流转前设置验证和控制边界 | 避免不安全内容绕过应用逻辑进入关键环节 |
对开发者而言，最重要的判断标准是输出会被谁解释。如果解释者是人，处理重点在内容是否符合业务规则和安全意图；如果解释者是浏览器、脚本引擎、系统环境或自动化工具，就必须把输出安全作为应用设计的一部分。