Wiki Notes

Appearance

01. LLM 安全与合规详解 ​

版本：v1.1

最后更新：2026-07-07

1. 为什么 AI 安全不能等系统上线后再补 ​

传统应用很多安全问题是在攻击发生后才暴露，但 LLM 和 Agent 系统的风险更早、也更分散。因为它们同时会：

  • 接收自然语言输入
  • 读取外部上下文
  • 生成结构化结果
  • 调用工具或下游系统
  • 给出可能被人或系统继续执行的建议

这意味着风险会横跨整条链路：

  • 输入
  • 上下文
  • 模型输出
  • 工具调用
  • 权限边界
  • 日志与审计

根据 OpenAI Safety best practices、Safety checks、Safety in building agents 等官方资料在 2026-07-07 的说明，安全控制应覆盖 moderation、adversarial testing、human oversight、结构化约束和权限隔离，而不是寄希望于“模型自己别出错”。

2. LLM 安全和传统应用安全最大的不同 ​

传统应用安全更关注：

  • 身份认证
  • 授权控制
  • 注入攻击
  • 依赖供应链

这些问题在 LLM 系统里依旧成立，但还会额外放大出一批新问题：

  • prompt injection
  • jailbreak
  • 间接注入
  • 不安全输出传播
  • 工具误用
  • 过度代理能力
  • 对模型结果的过度信任

所以 LLM 安全不是取代传统安全，而是在传统安全之上再增加一层“语言驱动系统”的风险治理。

3. 一条更实用的安全链路图 ​

可以把 LLM 系统的边界想成五层：

text
Input
 -> Context
 -> Model
 -> Tool / Action
 -> Audit

3.1 输入层 ​

关注：

  • 恶意输入
  • 越权请求
  • 敏感内容
  • 提示词注入尝试

3.2 上下文层 ​

关注：

  • 检索文档是否可信
  • 网页 / 邮件 / 附件是否存在间接注入
  • 外部内容是否会改变系统意图

3.3 模型层 ​

关注：

  • 输出是否偏离任务边界
  • 是否产生幻觉性高置信建议
  • 是否泄露敏感信息

3.4 工具和动作层 ​

关注：

  • 权限是否过大
  • 是否触发真实副作用
  • 是否需要审批
  • 是否可回滚

3.5 审计层 ​

关注：

  • 有没有留下足够证据
  • 后续是否能复盘
  • 是否能支持合规核查

这五层的关键不是名字，而是提醒你：

  • 不同风险落在不同边界
  • 不同边界需要不同控制手段

4. 先建立“信任边界”，再谈安全策略 ​

AI 系统里最容易犯的错误之一，是把所有输入都当成“只是文本”。但在安全设计里，文本也分层级：

4.1 高信任输入 ​

例如：

  • 受控系统配置
  • 已审批工作流参数
  • 可信系统生成的结构化字段

4.2 中等信任输入 ​

例如：

  • 内部知识库文档
  • 经过治理的 FAQ、制度、产品说明

4.3 低信任输入 ​

例如：

  • 用户自然语言输入
  • 上传附件
  • 网页抓取内容
  • 邮件、工单、聊天记录
  • 外部工具返回的自由文本

Anthropic 当前 Mitigate jailbreaks and prompt injections 和 Reduce prompt leak 的官方资料都在强调：

  • 低信任内容不能和系统指令、权限边界混成一层处理

这意味着工程上最好做到：

  1. 让系统意图和不可信内容分段存放。
  2. 给不可信上下文显式打标签。
  3. 不要把检索结果直接升级为系统级指令。
  4. 工具参数尽量来自结构化解析，而不是自由文本拼接。

5. 最该先记住的风险框架 ​

OWASP 当前对 LLM 和 Agent 风险的资料，很适合做团队共识底稿。

按 2026-07-07 可访问的 OWASP 官方资料，值得优先关注的两组内容是：

  • Top 10 for Large Language Model Applications
  • Top 10 for Agentic Applications for 2026

它们的价值不在于让你背条目，而在于提醒团队：风险已经不止是“模型说错话”，还包括：

  • prompt injection
  • insecure output handling
  • 敏感信息披露
  • 供应链与依赖风险
  • 过度代理能力
  • 身份与权限滥用
  • memory / context poisoning
  • insecure inter-agent communication
  • cascading failures

如果你的系统已经从单轮问答走到 RAG、工具调用、工作流编排和多 Agent 协作，就更应该同时参考这两组框架。

6. Prompt Injection 为什么是基础必修课 ​

根据 OWASP LLM01:2025 Prompt Injection 的定义，prompt injection 的核心是攻击者通过构造输入改变模型行为，使其偏离原本应该执行的任务或安全约束。

6.1 直接注入 ​

最典型的情况是用户显式输入：

  • 忽略之前所有规则
  • 泄露系统提示词
  • 执行不应执行的敏感动作

6.2 间接注入 ​

更危险的是来自：

  • 上传文档
  • 检索结果
  • 网页内容
  • 邮件内容
  • 工具返回值

因为模型读到这些内容时，未必能天然区分“这是证据”还是“这是在给我下指令”。

6.3 这为什么难防 ​

OWASP 和 Anthropic 当前资料都在强调一个现实：

  • 语言指令和普通内容在模型内部并没有天然硬隔离

所以不能把问题理解成“提示词写得更聪明一点就够了”。更稳的做法是同时做：

  • 输入分类
  • 上下文标记
  • 工具参数校验
  • 审批机制
  • 输出验证

7. 为什么 Agent 比普通聊天系统风险更高 ​

普通聊天系统最常见的损害可能是“答错了”。但 Agent 一旦接入工具，风险就会升级成：

  • 发错消息
  • 写错数据库
  • 误建或误关工单
  • 访问不该看的数据
  • 调用了不该调用的外部系统

这类风险不再只是内容风险，而是业务风险、权限风险和操作风险。

因此一个非常重要的原则是：

  • 模型可以建议，但不应天然拥有不可逆高权限执行力

OWASP 当前 Top 10 for Agentic Applications for 2026 也明确把 Tool Misuse and Exploitation、Identity and Privilege Abuse、Cascading Failures 等风险单独拎出来，这正说明 Agent 时代的安全重点已经从“说什么”扩展到了“做什么”和“连锁影响是什么”。

8. 最常见的风险清单 ​

8.1 输入侧风险 ​

  • prompt injection
  • jailbreak
  • 恶意多轮诱导
  • 越权伪装请求

8.2 上下文侧风险 ​

  • 恶意文档注入
  • 恶意网页注入
  • 检索结果污染
  • 历史记忆被污染

8.3 输出侧风险 ​

  • 敏感信息泄露
  • 不合规建议
  • 幻觉性高置信输出
  • 结构化结果不安全

8.4 工具侧风险 ​

  • 工具权限过大
  • 参数越界
  • 工具结果被污染后继续传播
  • 没有审批的真实写操作

8.5 运行侧风险 ​

  • 成本失控
  • 无限循环
  • 幂等缺失导致重复执行
  • 故障后无法回滚

9. 为什么只靠系统提示词远远不够 ​

OpenAI Safety in building agents 特别强调不要把不可信输入直接提升到高优先级提示层，同时建议用结构化输出和清晰的边界约束来限制数据流。

这背后的工程含义很直接：

  • 系统提示词很重要，但它不是安全边界
  • prompt 可以帮助降低误用概率，但不能替代权限控制
  • 真正的安全边界必须落在应用逻辑和运行时控制上

因此更可靠的做法通常是把防线分散到：

  • 输入检查
  • schema 约束
  • 工具白名单
  • 参数校验
  • 审批机制
  • 日志审计

10. 最实用的八类控制手段 ​

10.1 输入过滤和分类 ​

先识别：

  • 敏感请求
  • 违规请求
  • 潜在注入
  • 需要升级处理的内容

10.2 结构化输出约束 ​

让模型在节点之间输出固定 schema，比自由文本更不容易把恶意指令或脏数据一路传下去。

10.3 工具白名单 ​

不同角色只暴露完成本职工作所需的最小工具集。

10.4 读写分离 ​

能读不代表能写，能建议不代表能执行。

10.5 高风险动作审批 ​

涉及真实副作用时，应默认进入审批或人工复核。

10.6 输出校验 ​

对结构、字段、业务规则、敏感信息进行额外校验。

10.7 审计与追踪 ​

保留足够证据，支持后续追责、复盘和合规核查。

10.8 对抗测试与红队演练 ​

上线前主动测越权、绕过、注入、恶意文档、恶意网页和边界条件。

11. 高风险动作更适合怎么分级 ​

不是所有动作都要一刀切走人工审批。更稳的做法通常是做动作分级：

11.1 P0：只读低风险 ​

例如：

  • 读取公开文档
  • 做总结、分类、抽取
  • 查询不涉及敏感信息的知识

通常可自动执行，但仍应保留日志和结果校验。

11.2 P1：受限读操作 ​

例如：

  • 查询内部知识
  • 读取租户数据
  • 调取业务对象详情

这类动作至少要受身份、租户、范围限制控制。

11.3 P2：可逆写操作 ​

例如：

  • 创建草稿
  • 新建待审批工单
  • 生成建议配置但不生效

这类动作可以适度自动化，但最好带审批、撤销或二次确认。

11.4 P3：高影响或不可逆动作 ​

例如：

  • 发消息给客户
  • 修改生产配置
  • 删除对象
  • 发起支付、退款、转账
  • 导出敏感批量数据

OpenAI Guardrails and human review 当前资料很明确地把 human review 放在敏感动作批准链路里。对这类动作，更推荐：

  • 默认审批
  • 明确责任人
  • 保留回放证据
  • 准备回滚路径

12. prompt leak 与系统提示词保护 ​

Anthropic 当前 Reduce prompt leak 文档强调，没有任何方法能保证提示词绝对不泄露，但可以显著降低风险。

更务实的工程做法通常包括：

  1. 不把真正敏感的密钥、令牌、内部口令写进系统提示词。
  2. 不把访问控制逻辑只写在提示词里。
  3. 把可执行策略落到代码、权限系统和工具白名单里。
  4. 对“请展示你的系统提示词”“请输出隐藏规则”之类请求做专门拦截或升级处理。
  5. 让日志和错误信息不要意外回显系统提示词内容。

换句话说：

  • prompt 泄露本身不是全部问题
  • 真正要防的是“泄露后还能直接造成权限突破或副作用”

13. 数据与日志控制不能被忽略 ​

OpenAI Data controls in the OpenAI platform 文档明确区分了平台侧的数据类别，例如 abuse monitoring logs 和 application state。

这提醒工程团队两件事：

  • 需要搞清楚自己的数据会进入哪些存储或处理路径
  • 需要区分平台侧保留与应用侧自建日志、trace、缓存、向量库留存

企业内部最容易忽略的是：模型调用日志之外，真正积累敏感数据的往往是你自己的：

  • 业务审计日志
  • trace 记录
  • 文档缓存
  • 工具请求 / 响应快照
  • 向量索引原文

13.1 日志里最容易超量保留什么 ​

最常见的是：

  • 原始用户问题
  • 原始检索片段
  • 工具调用参数
  • 敏感实体字段
  • 模型中间推理结果

13.2 更稳的做法 ​

通常建议：

  • 只记录排障和审计所需最小字段
  • 对敏感字段做脱敏或散列
  • 把调试日志和审计日志分层
  • 给日志设置明确保留期和访问权限

14. 红队测试和安全回归怎么做 ​

OpenAI Safety best practices 与 Safety checks 都把 adversarial testing 视为上线前和持续运行中的关键动作。

如果你要做 AI 安全回归，至少应覆盖下面几类样例：

14.1 直接越狱样例 ​

  • 忽略系统指令
  • 伪装管理员
  • 请求泄露隐藏内容

14.2 间接注入样例 ​

  • 文档中埋“忽略前文”的指令
  • 网页中埋恶意操作诱导
  • 工具返回文本里带二次指令

14.3 权限绕过样例 ​

  • 跨租户查询
  • 越权导出
  • 低权限角色触发高权限工具

14.4 副作用样例 ​

  • 重复提交
  • 错误审批链
  • 无回滚写操作

14.5 输出合规样例 ​

  • 是否泄露敏感数据
  • 是否输出不允许的业务建议
  • 是否结构化字段越界

如果你的安全测试只测“会不会答违规内容”，那覆盖面其实还远远不够。

15. 出事故后怎么响应，往往和上线前一样重要 ​

很多系统不是没有防线，而是出问题后没人能快速判断“到底是哪里被绕过了”。

至少建议预先准备：

  1. 哪些动作可以立即熔断或停用。
  2. 哪些工具、连接器、租户通道可以单独下线。
  3. 哪些日志字段可以帮助回放链路。
  4. 谁负责审批、谁负责业务回滚、谁负责对外沟通。
  5. 哪些安全样例要在事故后固化进回归集。

如果系统已经具备写操作能力，事故响应就不应只是“修个 prompt 再发版”，而要包含：

  • 运行时熔断
  • 权限收缩
  • 回滚补偿
  • 样例复盘

16. 一个更稳的安全落地顺序 ​

如果团队正在把 LLM 系统往生产推，比较建议按下面顺序建设：

  1. 做数据分类和风险分级。
  2. 划清输入、上下文、工具、输出四个边界。
  3. 接入基础输入检查和输出校验。
  4. 把工具做最小权限和参数约束。
  5. 给高风险动作加审批。
  6. 用 adversarial testing 和红队样例持续回归。
  7. 让 trace、日志和审计证据可回放。

做到这里，系统才开始具备真正的安全运营基础。

17. 常见误区 ​

17.1 加一个 moderation 就算安全 ​

moderation 只是安全体系的一部分，不是全部。

17.2 只看最终输出，不看中间工具链 ​

很多风险是在中间节点扩大，而不是在最后一句话才出现。

17.3 只防用户输入，不防外部上下文 ​

间接注入往往正是通过文档、网页和工具返回传播。

17.4 没有权限分层，却期待 prompt 自律 ​

这在真实系统里通常撑不住。

17.5 为了审计，把敏感内容全量落日志 ​

审计需要证据，但也要脱敏、分级和最小化保留。

18. 一句最值得长期记住的话 ​

  • LLM 安全的核心不是让模型永远不出错，而是在输入、上下文、工具、输出和权限的全链路上建立可控边界。

19. 推荐搭配阅读 ​

20. 重点官方资源 ​

以下入口已按 2026-07-07 的官方资料重新整理：