Wiki Notes

Appearance

Guardrails与安全策略专题 ​

版本：v1.2

最后更新：2026-07-08

适用对象：正在做企业 Agent、工作流审批、知识助手、工具调用系统，以及需要把自动安全检查、人工审批、风险路由、输出校验和审计机制接成一套控制面的产品、平台与安全同学

很多团队会把“安全策略”理解成：

  • 上线前做一次审查
  • 在入口加一个 moderation
  • 在 Prompt 里写一句“不要做危险事”

但真实可依赖的 AI 系统更像有多层控制面：

  • 输入检查
  • 上下文检查
  • 工具权限
  • 输出校验
  • 风险分级
  • 人工审批
  • 审计与回放

这篇专题关注的，就是如何把这些控制点串成可运行的 guardrails 体系。

1. 先明确：guardrails 不是单个模型，也不是单条规则 ​

根据 OpenAI 当前 Guardrails and human review 文档在 2026-07-08 的说明：

  • guardrails 用于自动验证输入、输出或工具行为
  • human review 用于对敏感动作做批准决策
  • 两者一起决定某次运行是继续、暂停、拒绝还是转人工

从工程角度理解：

  • guardrails 不是“替代模型的另一个模型”
  • guardrails 是围绕运行链路布置的一组控制机制

它更像：

  • 控制平面

而不是：

  • 单点功能

2. 为什么单层 guardrails 通常不够 ​

因为风险并不只存在于用户输入。

真实风险可能出现在：

  • 用户输入
  • 检索结果
  • 外部网页
  • 文件附件
  • 工具参数
  • 输出结果
  • 最终动作执行

所以更稳妥的策略通常是：

text
Input Guardrails
 -> Context Guardrails
 -> Tool Guardrails
 -> Output Guardrails
 -> Action Approval
 -> Audit

如果只做最前面一层，很容易出现：

  • 输入没问题，但文档里带注入
  • 输出没问题，但工具参数越权
  • 规则没报错，但执行动作本身不该自动发生

3. guardrails 和人工审批不是一回事 ​

这是安全设计里最容易混淆的点。

3.1 guardrails 负责什么 ​

更适合做：

  • 自动检测
  • 自动阻断
  • 自动标记风险
  • 自动降级

3.2 人工审批负责什么 ​

更适合做：

  • 最终批准
  • 风险责任判断
  • 例外场景放行
  • 高后果动作确认

换句话说：

  • guardrails 更像自动阀门
  • 审批更像责任决策

如果把两者混成一个黑盒，系统会很难解释也很难审计。

4. Input guardrails 主要解决什么问题 ​

Input guardrails 重点不是“美化输入”，而是识别明显危险或不合规的请求。

常见目标包括：

  • PII 检测与脱敏
  • jailbreak 检测
  • prompt injection 检测
  • 恶意、违法、越权请求识别
  • 高风险意图分类

根据 OpenAI 当前 Safety in building agents 指南：

  • 可以对输入做 PII redaction
  • 可以检测 jailbreak attempts
  • 对高风险动作建议启用审批

4.1 输入层最常见误区 ​

  • 只看关键词，不看语义意图
  • 只做文本检查，不做结构化参数检查
  • 只在外部用户入口做，不在内部服务入口做

5. Context guardrails 为什么特别容易被忽视 ​

很多系统只在：

  • 用户输入
  • 模型输出

两侧做检查，却忽略了中间上下文本身也可能带风险。

典型风险包括：

  • 检索文档带有 prompt injection
  • 网页内容带有恶意指令
  • 附件或知识库含有敏感内容
  • 长会话历史里残留上次任务的危险状态

所以更稳的系统通常会对这些对象单独做校验：

  • 检索结果
  • 文件内容
  • 网页抽取内容
  • 系统拼接后的上下文片段

5.1 这层的核心问题不是“内容好不好看” ​

而是：

  • 这段上下文有没有资格进入模型决策面

6. Tool guardrails 为什么比文本 guardrails 更关键 ​

只要系统能调用外部工具，风险就从：

  • 错误回答

升级为：

  • 错误行动

典型事故包括：

  • 错发消息
  • 错改审批状态
  • 错删记录
  • 错调外部系统
  • 跨租户访问

所以 Tool guardrails 至少要回答：

  • 哪些工具允许这个角色调用
  • 哪些工具只允许只读
  • 哪些参数有边界
  • 哪些工具必须审批
  • 哪些工具只允许特定租户或命名空间

6.1 Tool guardrails 的常见做法 ​

  • 工具白名单
  • 参数 schema 校验
  • 只读 / 可写分离
  • 敏感工具分级
  • 审批前置

7. Output guardrails 解决的不只是违规内容 ​

很多团队把输出安全等同于：

  • 审核有害内容

但输出 guardrails 在企业系统里常常还负责：

  • 结构校验
  • 高风险领域回答约束
  • 引用要求
  • 风险提示插入
  • 拒答与降级

例如：

  • 医疗、法律、金融回答要求更谨慎
  • 审批建议必须附带依据
  • 工具参数必须严格符合 schema
  • 不确定时必须转人工而不是编造

所以 output guardrails 往往需要结合：

  • moderation
  • policy checks
  • schema validation
  • domain rules

8. Action guardrails 是真正决定“是否执行”的最后一道闸 ​

更准确地说：

  • 不是所有正确输出都应该自动执行

一个回答可以合规，但对应的动作仍然可能需要审批。

例如：

  • 转账
  • 删除
  • 对外发送
  • 调整客户权限
  • 发布生产变更

对于这些动作，最稳妥的策略通常不是让模型“更谨慎”，而是：

  • 显式中断
  • 进入人工确认
  • 记录审批结果

9. 风险分层路由比统一策略更适合生产 ​

很多 guardrails 体系之所以不好用，是因为对所有请求都采用同一套处理逻辑。

更实用的设计通常是先做风险分层：

  • 低风险
  • 中风险
  • 高风险
  • 禁止类

然后分别绑定不同策略：

9.1 低风险 ​

  • 自动放行
  • 常规记录

9.2 中风险 ​

  • 自动检查
  • 结构约束
  • 可能加提示或限流

9.3 高风险 ​

  • 强化 guardrails
  • 需要审批或二次确认
  • 更严格审计

9.4 禁止类 ​

  • 直接拒绝
  • 留审计痕迹

这样系统会比“一刀切全拦”更稳定，也更可运营。

10. guardrails 设计时最少要想清楚的五个问题 ​

  1. 这道 guardrail 要挡住的具体风险是什么？
  2. 它是自动检查、自动阻断，还是只打标？
  3. 误杀的代价是什么，漏放的代价是什么？
  4. 触发后是拒绝、降级、转人工，还是等待审批？
  5. 触发结果是否进入 trace 和 audit？

如果这五个问题答不清，guardrail 很容易变成“写了规则，但团队并不知道它在生产里意味着什么”。

11. 更实用的 guardrails 架构模式 ​

11.1 前置筛查模式 ​

适合：

  • 用户输入过滤
  • PII redaction
  • 基础越权和违法请求过滤

11.2 上下文隔离模式 ​

适合：

  • RAG
  • 文件解析
  • 网页浏览
  • 外部内容接入

关键是先判定上下文是否可信，再给模型使用。

11.3 工具沙箱模式 ​

适合：

  • MCP 工具
  • 外部 API
  • 文件和命令操作

关键是把工具能力本身做成有边界的资源，而不是全权开放。

11.4 输出校验模式 ​

适合：

  • 结构化输出
  • 高风险建议
  • 自动行动前最终检查

11.5 人机协同审批模式 ​

适合：

  • 任何有高后果副作用的场景

12. guardrails 和 moderation 的关系应该怎样理解 ​

OpenAI 当前 Moderation 文档提供的是：

  • 对有害文本和图像内容的检测能力

它通常是 guardrails 体系中的一个重要检测器，但不是 guardrails 的全部。

更准确的关系通常是：

  • moderation 是检测组件
  • guardrails 是控制编排

除了 moderation，guardrails 往往还需要：

  • schema 校验
  • 工具权限校验
  • 业务规则检查
  • 风险分级
  • 人工审批

13. guardrails 必须接进可观测与审计体系 ​

如果 guardrails 只在运行时默默触发，但没有进入 trace 或审计，后面会有几个大问题：

  • 不知道哪类风险在变多
  • 不知道哪些 guardrails 经常误杀
  • 不知道事故时是没触发、误放行还是被绕过

建议至少记录：

  • request_id
  • trace_id
  • policy_version
  • guardrail_name
  • risk_level
  • decision
  • approver
  • tool_name
  • tenant_id

这样你才能在之后回答：

  • 这次为什么放行
  • 为什么阻断
  • 为什么转人工

14. guardrails 本身也需要版本化和变更治理 ​

一个常见误区是：

  • 只把代码当发布资产

但真实生产里需要版本化的往往还包括：

  • Prompt
  • guardrail 规则
  • 工具白名单
  • 风险阈值
  • 审批规则
  • 输出 schema

因为这些变化都可能直接引入新的安全后果。

更稳妥的做法通常是把它们纳入：

  • 变更单
  • 灰度验证
  • 回滚路径
  • 安全回归

15. 怎么判断一个 guardrail 设计得是否健康 ​

建议从四个维度看：

15.1 防护有效性 ​

  • 是否能稳定拦住目标风险

15.2 误杀成本 ​

  • 是否把大量正常请求也一起拦掉了

15.3 可解释性 ​

  • 团队能否清楚解释为什么被挡

15.4 可运营性 ​

  • 能否灰度、回滚、追踪、复盘

如果只剩“能挡住”这一条，系统通常会越来越难维护。

16. 最常见的反模式 ​

  • 只做输入检查，不做上下文、工具和输出检查
  • 把 guardrails 和审批混成一个黑盒
  • 工具权限过大
  • 高风险动作自动执行
  • guardrails 触发不进 trace / audit
  • 规则没有版本号和 owner
  • 只做技术规则，不做业务规则
  • 不把检索结果和外部内容当作风险源

17. 建议的落地顺序 ​

第一阶段：先把五层控制面画出来 ​

  • 输入
  • 上下文
  • 工具
  • 输出
  • 动作

第二阶段：为高风险链路加审批 ​

先从：

  • 删除
  • 外发
  • 写操作
  • 敏感权限调整

这些动作入手。

第三阶段：把事件接进 trace 和审计 ​

让系统能真正被观察和复盘。

第四阶段：把 guardrails 纳入版本化和回归 ​

让它成为可发布、可灰度、可回退的资产。

18. 推荐搭配阅读 ​

19. 重点官方资源 ​

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