Wiki Notes

Appearance

AI 安全专题索引 ​

版本：v1.6

最后更新：2026-07-08

这组内容主要讨论：LLM 和 Agent 系统在真实业务中的安全风险，以及提示词注入、越权工具调用、权限隔离、审计、红队测试和合规控制应该怎么落到系统里。

它不是单纯讲“模型会不会说违规内容”，而是把安全问题拆到输入、检索、工具、运行时和治理层，帮助你把安全设计做成系统机制，而不是只写在 Prompt 里。

1. 这组内容在解决什么问题 ​

AI 安全和传统应用安全有重叠部分，但也多了很多模型时代特有的问题：

  • prompt injection 和 jailbreak 会污染模型决策。
  • 检索上下文可能把不该信任的内容带进系统提示附近。
  • 工具调用、连接器和 MCP server 会把模型错误放大成真实副作用。
  • 多租户知识和长链路工作流会放大越权、泄露和错误执行风险。
  • 人工审批、回放、审计和回滚如果没有一起设计，事故后很难快速止损。

按 OpenAI 当前的 Safety best practices、Guardrails and human review、Safety in building agents，以及 Anthropic 关于 Reduce prompt leak、Mitigate jailbreaks 的官方资料来看，AI 安全至少要同时回答六个问题：

  1. 哪些输入属于低信任内容，不能直接影响高权限决策。
  2. 哪些动作属于高风险副作用，必须审批、确认或限权执行。
  3. 哪些数据可以进入上下文，哪些数据只能检索不能直接暴露。
  4. 模型输出如何经过 guardrails、校验器和人工 review 才进入真实系统。
  5. 出现异常时能不能快速定位、停用、隔离和回滚。
  6. 安全样例、红队结果和线上事故能不能进入持续回归机制。

2. 推荐阅读顺序 ​

2.1 想先建立 AI 安全基本边界 ​

  1. 01-LLM安全与合规详解
  2. [02-Prompt Injection、越狱与提示词泄露](./02-Prompt Injection、越狱与提示词泄露)
  3. 安全治理
  4. 提示词工程详解

2.2 想补 Agent、工具和连接器风险 ​

  1. 03-工具权限、审批与执行安全
  2. AI Agents专题 / 06-评测、可观测性与安全
  3. 安全治理
  4. 平台工程

2.3 想补企业落地里的权限、审批和审计 ​

  1. 04-数据、日志、红队与事故响应
  2. 安全治理
  3. 知识库与检索
  4. AI Agents 与工作流总目录

2.4 这一组现在包含什么 ​

  1. 01-LLM安全与合规详解：负责总论，把输入、上下文、模型、工具、日志和治理边界先统一起来。
  2. [02-Prompt Injection、越狱与提示词泄露](./02-Prompt Injection、越狱与提示词泄露)：负责讲直接注入、间接注入、prompt leak、低信任上下文和防御分层。
  3. 03-工具权限、审批与执行安全：负责讲最小权限、参数校验、动作分级、审批和执行补偿。
  4. 04-数据、日志、红队与事故响应：负责讲日志分层、数据控制、红队回归和事故响应链。

3. AI 安全最值得先建立的几个共识 ​

3.1 模型安全不等于内容审核 ​

内容审核只是安全的一部分。真正的 AI 安全还包括：

  • 输入可信度分层
  • 工具权限边界
  • 检索权限和多租户隔离
  • 高风险动作审批
  • trace、审计和回放

如果只做违禁内容过滤，很多真实风险仍然会穿过去。

3.2 prompt injection 不能只靠“把提示词写得更强” ​

OpenAI 和 Anthropic 当前关于 agents 安全、prompt leak 和 jailbreak 的官方资料都在强调同一个原则：更稳的做法是把系统提示、检索内容、工具调用和高风险动作分别建立边界，而不是指望一段万能提示词彻底挡住注入。

更实用的思路通常是：

  • 把外部输入默认视为低信任内容。
  • 不让检索文本直接覆盖系统规则。
  • 让工具调用经过 schema、权限和动作分类约束。
  • 对高风险动作加审批、二次确认或人工 review。

3.3 高风险动作要和审批、人工 review、回滚一起设计 ​

如果模型已经能调工具、改数据、发消息、执行工作流，那么安全设计就必须同时考虑：

  • 谁批准
  • 谁追责
  • 哪些动作能自动执行
  • 哪些动作必须人工确认
  • 出错后怎么中断和回滚

真正难的不是“能不能调到工具”，而是“调错后能不能收得住”。

3.4 安全日志不能既没有，也不能什么都留 ​

日志、trace、缓存和审计记录太少，出问题时难追责；留太多，又会制造新的敏感数据暴露面。

因此更合理的做法通常是分层保留：

  • 运行排障字段
  • 安全审计字段
  • 成本和评测字段
  • 敏感内容最小化或脱敏字段

3.5 安全必须进入回归集，而不是只靠临时红队 ​

只在上线前做一次红队测试，通常不够。更稳的做法是把：

  • prompt injection 样例
  • jailbreak 样例
  • 越权工具调用样例
  • 跨租户数据泄露样例
  • 审批绕过样例

一起沉淀为长期回归集。

4. 可以把 AI 安全拆成哪几层 ​

4.1 输入层 ​

重点看：

  • 用户输入
  • 上传文档
  • 网页抓取内容
  • 邮件、聊天记录、第三方返回文本

这些内容大多不应该被天然当成可信规则。

4.2 数据层 ​

重点看：

  • 检索上下文
  • 知识权限
  • 多租户隔离
  • 敏感数据暴露
  • 日志脱敏和最小留存

这层的风险常常不是模型“乱说”，而是系统把不该给它看的数据给了它。

4.3 执行层 ​

重点看：

  • 工具调用
  • 连接器
  • shell / file / browser / MCP server
  • 写操作、外发动作和审批动作

这层要特别强调动作分级，而不是把所有工具都默认暴露给模型。

4.4 运行层 ​

重点看：

  • guardrails
  • human review
  • 回放
  • 审计
  • 告警
  • 事故响应

如果运行层没有熔断、隔离和审计能力，平台再“智能”也不算可控。

5. 企业场景里最常见的五个安全设计决策 ​

5.1 哪些输入算低信任内容 ​

用户问题、上传文档、网页抓取、邮件内容、工具返回文本，通常都不该被当成“天然可信”。

5.2 高风险动作如何分级 ​

不是所有动作都要一刀切审批，但发消息、改配置、删数据、导出敏感内容这类高影响动作，通常都应该默认走更强控制。

5.3 工具权限放在哪一层控制 ​

如果权限只放在 UI 层或 Prompt 里，而检索层、工具层和运行时不做强约束，系统很容易被绕过。

5.4 安全日志留到什么粒度 ​

更稳的做法通常是明确：

  • 什么字段只做排障
  • 什么字段进入审计
  • 什么字段必须脱敏
  • 什么字段能用于回放但不能长期保留明文

5.5 出问题后能不能快速熔断和回滚 ​

上线前就应该想清楚：

  • 哪些工具能停
  • 哪些租户能隔离
  • 哪些写操作能补偿
  • 哪些策略能快速回退

不要等事故发生后再临时拼流程。

6. 上线前最值得先确认什么 ​

  1. 是否已经区分直接注入、间接注入、越权工具调用、跨租户泄露和日志过量留存这几类风险。
  2. 是否已经对高风险动作建立审批、回滚或二次确认。
  3. 是否已经准备好红队回归集，而不是只做几条违规内容测试。
  4. 是否已经能回放关键链路，包括输入、上下文、工具、审批和输出。
  5. 是否已经明确哪些字段进日志、哪些字段进审计、哪些字段必须脱敏。

7. 不同角色更适合怎么读 ​

7.1 应用工程师 ​

优先看 01-LLM安全与合规详解，重点理解 prompt injection、工具边界、输出校验和日志最小化。

7.2 平台或安全负责人 ​

更适合把这组内容和 安全治理 一起看，重点关注权限、审批、审计、红队和事故响应。

7.3 Agent 或工作流负责人 ​

更适合联读 AI Agents 与工作流总目录 和 平台工程，把安全设计接到工具、运行时和可观测性链路上。

8. 常见误区 ​

  • 把 AI 安全缩成“敏感词过滤”。
  • 把权限控制放在 UI 层，而不是检索层和工具层。
  • 把人工 review 当成低效补丁，而不是高风险动作的一部分。
  • 上线前不做红队测试、灰度和安全回归。
  • 把“模型拒答率更高”误当成“系统更安全”。

9. 当前官方资料最值得先建立的四个安全判断 ​

按 2026-07-08 复核可访问的 OpenAI、Anthropic 和 OWASP 官方资料，比较值得先建立的安全判断有这些：

9.1 moderation、safety checks、guardrails、approval 不是同一层控制 ​

OpenAI 当前官方资料把这几层能力拆得很清楚：

  • Moderation：更偏内容分类与风险识别
  • Safety checks：更偏平台与使用方式的安全校验
  • Guardrails and human review：更偏运行流里的 continue / pause / stop 与高风险审批
  • Safety in building agents：更偏工具、连接器、MCP、PII 和执行边界

如果把这些都混成一句“我们做了安全”，系统很容易出现两个误判：

  • 以为做了内容审核，就等于高风险动作也受控了
  • 以为有 guardrails，就不再需要真正的人工批准决策

更稳的理解通常是：

  • moderation 识别内容风险
  • guardrails 自动拦或标
  • approval 决定高后果动作能不能继续
  • agent safety 负责把工具、状态和副作用边界接进系统

9.2 检索文本、工具结果、远端 MCP 返回值都属于低信任内容 ​

很多团队会默认：

  • 工具返回的是系统内结果，所以更可信
  • 检索拿回的是企业文档，所以更可信

但真实工程里，这几类内容同样可能污染模型判断：

  • 被恶意构造的网页或文档内容
  • 被错误配置的知识库结果
  • 第三方 SaaS / MCP server 返回的异常文本
  • 带 prompt injection 的邮件、工单、网页和 PDF

更稳的默认心智通常是：

  • 只要内容不是系统高权限规则本身，就先按低信任输入处理

这也是为什么 OpenAI MCP and Connectors、Anthropic 的 guardrails / prompt leak 资料，以及本组里的 prompt injection 专题都值得一起看。

9.3 真正要单独保护的是四类上下文资产 ​

企业 AI 系统里最容易被混在一起、但其实最该分开治理的上下文资产通常是：

  1. system / developer instructions
  2. retrieved context
  3. tool results
  4. memory / trace / audit snapshots

这四类对象如果不分层保护，常见后果就是：

  • 外部内容离系统规则太近
  • 工具结果被模型误当成“高权限指令”
  • 记忆和日志里意外留下敏感信息
  • 回放能力变成新的泄露面

9.4 红队、回归和上线门禁应该按攻击类型分桶 ​

OpenAI Red teaming、Anthropic 关于 jailbreak / prompt injection 的资料，以及 OWASP GenAI / Agentic 风险框架放在一起看，一个很实用的做法是：

  • 不要把所有“安全失败样例”混在同一个集合里

更适合长期维护的分桶通常至少包括：

  • prompt injection
  • jailbreak / policy bypass
  • prompt leak / system instruction exposure
  • tool misuse / over-permission
  • data leakage / cross-tenant exposure
  • approval bypass / unsafe execution

如果这几类风险不分桶，后面的门禁就会很难判断：

  • 到底是哪一类风险在恶化
  • 是模型问题、工具问题，还是运行配置问题

10. AI 安全里最容易漏掉的四个信任边界 ​

10.1 系统规则和外部内容的边界 ​

系统提示、开发者规则、审批策略，不应该和检索文本、网页内容、邮件正文混成同一层上下文。

10.2 工具描述和工具结果的边界 ​

工具 schema 是“系统允许什么”；工具结果只是“这次返回了什么”。两者不能被模型混成同一个等级的依据。

10.3 审计留痕和长期留存的边界 ​

不是所有能帮助排障的字段都值得长期保留，更不是所有可回放对象都应该以明文长期存在。

10.4 平台可见数据和业务侧可见数据的边界 ​

OpenAI Data controls 讨论的是平台侧控制；你自己的 trace、缓存、知识索引、审批记录和回放快照，往往是第二套完全独立的留存体系，也必须单独治理。

11. 建议搭配阅读 ​

12. 重点官方资料 ​

以下资源已按 2026-07-08 核查可访问：

13. 什么时候该跳到其他目录 ​

  • 当你开始设计审批、回滚、红队和事故响应时，跳到 安全治理。
  • 当你开始处理工具、工作流、handoff 和连接器风险时，跳到 AI Agents专题。
  • 当你开始治理 trace、配置、发布和多模型策略时，跳到 平台工程。
  • 当你开始处理检索权限、多租户知识隔离和数据暴露时，跳到 知识库与检索。