Guardrails 能管什么、不能管什么：Input、Output 与 Tool Checks

前置：Human Control 如何跨进程工作：HITL、Interrupt、Approval 与 Resume
核心问题：Guardrail 能检查输入输出，但为什么它不能代替 Tool authorization / sandbox policy，高风险动作到底在哪一层被拦住？

Guardrail 最大的误解：把“检查”当成“隔离”

用户输入中含敏感数据，可以在进入模型前检测；模型输出不符合政策，可以在返回用户前拦截；模型准备调用高风险 Tool，可以在副作用发生前检查参数。这些都属于 Guardrail。

但如果进程本身拥有任意文件、网络和 credential 权限，Guardrail 失败、被绕过或实现有 bug 时，资源依然可访问。Guardrail 决定“这次请求应不应该做”，Capability/Sandbox 决定“系统事实上能不能做”。 两者不能互相替代。

三类 Guardrail 的位置不同

可以把执行链画成：

User Input
→ Input Guardrail
→ Context / Model
→ Action Intent
→ Tool Guardrail (pre-execution)
→ Authorization / Capability
→ Executor
→ Tool Result
→ optional post-tool check
→ Model Output
→ Output Guardrail
→ User

Input Guardrail 适合检查请求类别、明显敏感字段或业务准入；Output Guardrail 检查最终响应；Tool Guardrail 则最接近真实副作用，因此必须明确放在 execute 之前还是之后。

例如 send_email 的“收件人是否允许”如果在执行后才检查，已经没有阻断意义。

并行 Guardrail 的性能优化有真实竞态

有些框架允许 Input Guardrail 与模型调用并行，以减少正常请求 latency。但这意味着：

model starts generating
||
guardrail evaluating

Guardrail 后来判定拒绝时，模型计算成本可能已经产生；如果错误地让 Tool execution 也提前开始，甚至可能已经产生副作用。

因此要区分：

safe speculative compute
!=
speculative side effect

对纯模型计算可以接受“先算后丢”；对付款、发送、删除、部署等动作，应等必要 guardrail/authorization verdict 成为程序事实后再执行。

Guardrail failure 也需要结构化语义

不要把所有拒绝都变成 Exception("blocked")。Runtime 至少应知道：

which guardrail
stage: INPUT / TOOL / OUTPUT
verdict: PASS / BLOCK / REVIEW
reason code
evidence / classifier version
whether side effect started

REVIEW 还可能转入 HITL，而不是直接失败。这样 Trace、用户反馈和审计才能区分“模型调用错误”“政策阻断”“等待人工批准”。

Tool Guardrail 不能重复 Tool 的强契约

例如 Tool schema 已规定 amount > 0，Executor 也必须做 schema validation；不要只在 Prompt/Guardrail 里提醒模型“金额必须大于 0”。

更合理的分层是：

Schema validation → 输入形状/类型事实
Authorization     → 调用者是否有权限
Capability        → 进程实际可访问的资源
Guardrail         → 业务/内容/风险判断
Approval          → 需要人类显式决定的动作

同一请求可能同时经过几层，因为它们回答不同问题。

失败场景：Guardrail 通过，但系统仍不安全

模型请求写 /etc/hosts，内容分类 Guardrail 判断文本本身无害。如果 Sandbox 允许任意 root filesystem write，系统仍然危险。

正确设计是：Guardrail 可以给出行为 verdict，但 Executor 仍使用最小 filesystem capability；超出 workspace root 的路径在强边界被拒绝。即使 Guardrail 服务宕机或模型诱导成功，blast radius 仍被控制。

应该怎样测试

Guardrail 测试重点不是“模型有没有听话”，而是 stage 和副作用顺序：

blocked input
→ ModelClient not called (strict mode)

blocked tool action
→ ToolExecutor side effect count == 0

REVIEW verdict
→ durable approval state created

output blocked
→ raw model output not sent to user

security boundary test
→ even if guardrail returns PASS, forbidden filesystem/network capability still fails

最后一条非常重要：它证明 Guardrail 没有被误当成安全边界。

自测

1. Output guardrail 发现敏感内容，能否反过来证明某个 Tool 具有执行权限？为什么 guardrail 和 authorization 是不同边界？
2. Input、output、tool checks 各自能阻止什么；哪类安全问题即使三个都做了仍需要 sandbox/capability 解决？

Sources

• OpenAI Agents SDK — Guardrails
• OpenAI Agents SDK — Human-in-the-loop