LLM 应用仍需要身份管理、最小权限、输入输出验证和审计，但也出现了新的失败类型。常见问题包括以下三类。
- 将不可信内容当作指令，包括 prompt injection 及其变体。
- 将模型输出直接当作可信代码或政策依据，造成不安全的输出处理。
- 赋予模型的工具、插件、浏览或检索能力，超出系统能够有效控制的范围。
OWASP 的 2025 年 LLM 应用十大风险提供以下分类。
- LLM01：Prompt Injection，提示注入。
- LLM02：Sensitive Information Disclosure，敏感信息泄露。
- LLM03：Supply Chain，供应链风险。
- LLM04：Data and Model Poisoning，数据与模型投毒。
- LLM05：Improper Output Handling，不当输出处理。
- LLM06：Excessive Agency，过度自主权限。
- LLM07：System Prompt Leakage，系统提示泄露。
- LLM08：Vector and Embedding Weaknesses，向量与 embedding 相关弱点。
- LLM09：Misinformation，错误信息。
- LLM10：Unbounded Consumption，无限制资源消耗。
典型生产系统至少有五类信任边界：用户输入、检索内容、模型可调用的工具或 API、模型提供商或自有推理服务，以及可观测性和存储系统。模型行为影响这些边界，但应用通常无法完全控制模型。
攻击如何发生
直接与间接提示注入：攻击者在提示或数据中嵌入指令，例如邮件、文档和网页，诱使模型将其当作具有权威性的要求。间接注入通过系统获取的外部内容进入，用户可能完全看不到恶意部分。当模型同时能够读取不可信内容和调用工具时，恶意片段可能诱使它泄露秘密或滥用权限。
RAG 投毒：攻击者将错误事实或恶意指令加入检索资料或上游来源，使模型引用或遵循它们。少量被污染文档就可能造成有针对性的错误回答，因此知识库也是需要保护的攻击面。
不安全的输出处理：未经验证就渲染、执行或转发模型输出，可能引入 shell 或代码注入、政策绕过等传统漏洞。模型内容能够触发后续操作，因此在验证之前应视为不可信。模型可以大量生成看似可信且形式多变的字符串，将其直接用于代码、浏览器或自动化流程会扩大影响。
成本与可用性滥用：攻击者或使用过度的用户可以要求巨大输出、超长上下文或大量并行检索，扩大 token 开销，并影响其他租户，效果类似拒绝服务。
供应链：风险覆盖模型、embedding、推理服务、向量数据库、数据集和防护组件。权重、容器镜像和数据来源都可能引入问题。检索流程中的未审核资料、工具运行环境中的未知代码，以及可能记录秘密的可观测性系统，尤其需要关注。
隐私与数据保护：风险包括非预期记忆与提取、追踪日志中的个人信息，以及提供商的数据处理方式。部署时应明确记录什么、发送到哪里，以及提供商保留哪些信息，并依据适用要求配置保留周期。
用于分析风险的框架
OWASP Top 10 for LLM Applications 提供便于设计审核和威胁建模的分类，覆盖 RAG 与智能体。它有助于与非安全专业人员讨论风险，并记录已经处理的类别。2025 年内容属于 OWASP GenAI Security Project，每项风险都有示例及常见缓解方法。
NIST AI Risk Management Framework（AI RMF 1.0） 通过 Govern、Map、Measure 和 Manage 组织风险管理活动。配套的 Generative AI Profile 进一步讨论生成式系统的数据治理、滥用和透明度等问题，有助于产品、法律及管理团队使用共同语言讨论数据保留、事件响应等控制措施。
Google Secure AI Framework（SAIF） 强调扩展已有安全基础，将检测和响应应用于 AI，并自动执行防护。其风险与控制资料覆盖模型、数据、处理流程和运行环境，帮助安全团队将 AI 纳入现有安全运营与漏洞管理工作。
Guardrails：运行时防护措施
Guardrails 位于不可信输入、输出和敏感操作之间，限制系统能够接受、生成或执行的内容。它们帮助减少模型或外围代码越过安全边界的机会。LLM 失败除了错误回答，还包括遵循恶意数据中的指令、不安全工具使用、日志泄密，以及成本或可用性滥用。因此，运行时防护应与身份授权、最小权限和安全检索共同构成多层防御。
防护措施的分类
可以从三个方面分类。
- 执行时间：生成前验证或转换提示及检索内容；生成中限制解码或工具调用；生成后在内容到达用户或工具前审核、遮盖、核查依据或阻止输出。
- 判断方式：确定性方法包括正则表达式、JSON Schema、语法约束、允许列表、拒绝列表和策略引擎；模型方法包括安全分类器、注入检测器和依据核查模型。
- 部署位置：应用 SDK 或服务层、gateway 或 Sidecar，以及提供商托管的安全服务。
确定性措施较便于预测和审计，但覆盖范围有限；模型措施可以处理更难用规则表达的问题，却具有概率性，需要校准，也可能被绕过。尤其面对间接提示注入，需要多种措施配合。
生产环境可以考虑以下防护类别。
输入与输出内容安全
在提示和输出到达用户或工具之前，使用分类器及政策规则检测仇恨、自伤、性内容或暴力等类别。相关服务包括 OpenAI moderation 模型，例如 omni-moderation-latest，Azure AI Content Safety，以及 Vertex AI 或 Gemini 的安全设置。应提前确定命中规则后是阻止、遮盖，还是转交人工审核，并根据所用服务版本验证支持能力。
提示注入与越狱检测
这类检测针对试图覆盖系统要求或诱导非预期工具调用的输入和数据。Microsoft Prompt Shields、Meta Llama Prompt Guard 2 等工具可以作为生成前检查的一部分。检测结果可用于阻止或转换内容，或暂时关闭高风险工具。这些检测器依据已知技术训练并持续更新，属于概率信号，必须结合工具和输出的架构限制，使漏检不至于直接造成事件。
结构化输出与约束解码
系统只接受 JSON 或有限值集合时，应使用结构约束。第一类方法通过 schema 控制输出，例如 OpenAI Structured Outputs、支持 strict=true 的工具调用，以及 Instructor 等库提供的相应模式，减少解析错误及任意文本进入后续代码。第二类方法在解码时使用语法或正则表达式限制 token 选择，例如 vLLM 的结构化解码。它可以提高格式可靠性，某些实现也能加速确定性片段的生成。格式正确仍需配合业务语义、授权及参数验证。
个人信息遮盖与敏感内容过滤
PII 检测器和自定义规则可以在用户提示、检索内容、模型回答及工具结果中识别个人数据或秘密，再执行遮盖或阻止。云服务通常支持内置类型和自定义模式。受监管场景还应严格限制可观测性记录，例如默认不记录原始请求正文，减少日志泄露。声明式策略便于统一执行，无需每个微服务分别修改代码。
依据核查与纠正
Groundedness 检查评估回答是否得到所提供来源支持，部分系统还能标注或改写缺少依据的文本。它类似实时评估：同时输入上下文与回答，再根据结果采取措施。在 RAG 或权威来源场景中，它可以减少无依据主张，但来源本身的真实性仍需另外核查。应根据领域评估决定阻止、标注还是纠正。
工具与网络出口防护
模型意图转变为实际操作前，需要独立策略检查。可以在模型与工具之间设置控制节点，通过 policy-as-code 明确允许哪些操作、参数和目标地址。策略可以由通用引擎执行，也可以在 gateway 中统一检查，使权限独立于提示文本。Amazon Bedrock 的 ApplyGuardrail 等服务可以提供内容防护，并与智能体或知识库结合；工具授权、业务权限和网络出口限制仍需要对应的独立控制。只有允许的工具、验证通过的参数和授权目的地址，才应进入执行步骤。
实现模式
应用内防护：在构建提示的服务中直接调用内容审核、注入检测和结构化输出。功能团队能够快速调整，但应使用共享库和默认策略，减少不同服务之间的规则差异。
Sidecar 或 gateway 防护：在应用代码之外统一实施内容审核、注入检查、schema 验证、PII 遮盖和网络出口允许列表。多个团队同时集成模型与工具时，这种方式便于集中管理和审计。
提供商托管防护：Azure Content Safety、Prompt Shields、Google 安全设置和依据检查，以及 Bedrock Guardrails 等，可以通过配置接入。使用时需要考虑可迁移性和透明度，记录供应商判断，并在适用政策范围内决定后续处理。
处理结果应明确，通常包括允许、阻止、转换或遮盖，以及转交人工。每条规则都应规定用户会看到什么，例如以下情况。
- 发现注入：禁止相关工具操作，并提供安全回应。
- 依据核查失败：显示来源并标明置信度不足，或按风险阻止输出。
- 发现个人信息：按策略遮盖后继续处理。
云服务常返回结构化原因和分数，应将适当信息纳入遥测，以数据校准阈值。
后续步骤涉及代码执行或数据修改时，应使用 schema 或语法约束表达操作意图，并独立验证操作权限及参数。约束输出能够提高可控性，某些场景也能减少延迟。
检索器也需要保护。公开网页和共享文档都应视为不可信内容。可以对获取内容执行注入检测，限制可访问目的地址，并禁止工具访问未经授权的内部主机名或敏感 API。
校准与测试
防护需要结合真实数据调整。内容安全和注入检测阈值应满足应用风险要求，记录原因与分数，并由产品及安全人员检查误报和漏报。追踪记录应标记策略版本，例如 vX.Y，以关联事件和策略变化。依据检查需要在评估集上测量阻止或标注是否减少错误，同时观察用户体验。还应运行红队测试，并随新攻击技术更新案例。
运维中可以尽量集中执行策略，通过 gateway 或 broker 统一调整规则、PII 模式和阈值。托管防护能够提供持续更新，但仍需记录判断和结果，以便解释阻止原因，并识别供应商更新后的回归。
分类器可能漏检，攻击方式也会持续变化。因此，代码化策略、出口允许列表、schema 或语法约束，以及严格的输出处理，对于涉及实际操作和内容渲染的路径尤为重要。依据核查只检查与来源的一致性；内容分类也无法覆盖全部业务风险，需要补充自定义规则和人工交接条件。防护本身会增加延迟和成本，低风险路径可以使用批量或异步检查，高风险操作则应在执行前同步验证。
应用示例
- 基于内部文档的客户聊天：输入输出审核、检索片段注入检测、回答依据核查及标注或阻止、结构化回答格式，以及 PII 遮盖。
- 具有工单、账单或邮件工具的智能体：工具执行前审核和注入检测，工具层策略及参数验证，受约束的操作意图输出，出口允许列表，以及每个工具的调用限额。
- 公开网页浏览或链接访问：检查获取页面，限制内部主机名和云元数据端点，减少任意文本控制工具的机会，显示引用和置信度，并限制检索扩展范围及预算。
生产级 LLM 安全依赖清楚的边界和适当的自动化范围。将不可信输入中的指令与授权分开，执行操作前检查策略，验证输出，限制单个请求能够消耗的资源，防止遥测和缓存泄露，并持续使用真实对抗案例测试系统。