Operant AI 近期发布 Semantic Firewall，引起 agent 安全社区关注。产品宣传围绕 Tool、Code、Data、Scope 四类守卫展开，目标是保护 AI agent 在工具调用、代码执行、数据访问和任务边界上的风险。参考来源：Operant AI 官网、Operant Semantic Firewall、OWASP Top 10 for LLM Applications。
我把这类产品看作 agent 安全栈的一次自然演化。早期 LLM 安全主要靠内容过滤：输入是否有违规词，输出是否包含敏感文本。后来大家发现，agent 的危险不只在说什么，而在做什么。它可能读错数据、调用错工具、写出危险代码、绕过审批、把内部上下文发给外部 API。传统 WAF 看的是请求包，LLM guardrail 看的是文本，Semantic Firewall 想看的是行为语义。
这个方向是对的，但也容易被市场话术说得太满。下面我们用工程视角评估它到底解决什么，不能解决什么。
为什么普通 guardrail 不够
普通 guardrail 通常有三类：输入过滤、输出过滤、模型 judge。它们对聊天场景有用，但对 agent 场景不够。
假设一个 agent 接了 GitHub、Slack、Jira、CRM 和数据库。用户输入一句“帮我整理客户升级风险”，看起来正常。风险可能出现在后面：agent 检索到不该看的客户字段，把 Slack 私信内容混进报告，调用外部总结模型，生成 SQL 时没有租户过滤，或者把内部 ticket 链接发给客户。
这些风险都不是简单输入过滤能看出来的。系统必须理解“这个工具调用是否符合当前任务”“这个字段是否可见”“这个输出是否离开了允许作用域”。这就是语义防火墙存在的空间。
TCDS 四个维度
Operant 的 Tool、Code、Data、Scope 可以翻译成四个工程问题。
Tool：agent 是否在正确时间调用正确工具，参数是否越权，工具链是否出现异常跳转。
Code：agent 生成或执行的代码是否包含危险操作，例如删除文件、外发密钥、禁用日志、绕过测试。
Data：agent 访问和输出的数据是否符合分类、租户、字段级权限和脱敏规则。
Scope：agent 是否仍在用户授权任务内，还是把任务扩展到未授权目标。
这四类刚好覆盖了 agent 最常见的事故路径。尤其是 Scope，经常被低估。很多越权不是一开始就恶意，而是 agent 在解决问题时逐渐扩大任务边界。
和 MCP 网关的关系
MCP 让工具暴露标准化，但安全产品要回答：谁能调用哪个 MCP tool，调用参数是否合理，工具返回内容是否应该进入上下文，下一步动作是否超出范围。
一个最小策略可以这样表示：
type AgentPolicy = {
allowedTools: string[];
deniedFields: string[];
maxExportRows: number;
externalNetwork: "deny" | "allowlist";
writeActions: "deny" | "approval" | "allow";
};
function evaluateToolCall(tool: string, args: unknown, policy: AgentPolicy) {
if (!policy.allowedTools.includes(tool)) return "deny";
if (tool.includes("export") && policy.maxExportRows === 0) return "deny";
return "allow";
}Semantic Firewall 的价值在于把这类策略从应用代码里抽出来，放到统一控制面。否则每个 agent 项目都会手写一套半成品安全逻辑，最后无法审计。
它应该接在哪里
最好的接入点不是只放在用户输入前，也不是只放在模型输出后，而是放在 agent loop 的关键节点。
user request -> scope classifier
planner output -> tool policy
tool response -> data redaction
code block -> sandbox policy
final answer -> disclosure policy每个节点的风险不同。用户请求阶段判断任务边界，planner 阶段判断工具意图，工具响应阶段做数据脱敏，代码阶段做沙箱限制，最终回答阶段做泄露检查。只在最后一步拦截，通常太晚。
对比传统 WAF
传统 WAF 仍然有用，它负责 HTTP、SQL 注入、路径遍历、已知恶意 payload 等网络边界问题。但 agent 会把自然语言变成多步行为。它可能先读文档，再查工具，再生成代码，再调用 API。单个 HTTP 请求看起来正常，组合起来却越界。
Semantic Firewall 更像运行时行为审计器。它不是替代 WAF，而是补上 WAF 看不懂的 agent 层。企业如果已经有 API gateway、WAF、SIEM 和 DLP，Semantic Firewall 应该接到这些系统，而不是成为孤岛。
评估工具时看什么
第一，看它是否支持工具级可观测性。只给“高风险”标签不够，必须能看到哪个 tool、哪些参数、哪个上下文触发了策略。
第二，看它是否支持数据分类。客户字段、内部链接、密钥、代码片段和财务数据的处理规则不同。
第三，看它能否和身份系统打通。没有用户、角色、租户和目的，安全策略只能粗暴拦截。
第四，看它是否支持本地或私有部署。agent 安全日志本身很敏感，包含工具参数和业务上下文。
第五，看误报处理。安全工具如果频繁阻断正常任务，团队会绕开它。需要观察模式、灰度模式和策略调试。
不能期待它做什么
它不能替你设计权限模型。工具不知道某个字段对你的业务有多敏感，除非你先分类。
它不能保证模型永远不会被骗。prompt injection 是一个系统问题，需要数据源隔离、工具最小权限、引用验证和上下文清洗。
它不能替代沙箱。代码执行仍需要容器、权限、网络限制和文件系统隔离。
它也不能替代人工审批。高风险写操作、批量导出、客户通知和生产变更，仍应该有人或独立策略批准。
采购和试点建议
试点不要从全公司 agent 平台开始。先选一个真实但边界清楚的场景，例如客服知识库加工单查询，或者代码 agent 读取仓库并生成修复建议。把 20 个高频任务跑一遍，观察它能否解释每次拦截原因，能否导出审计事件，能否和现有身份系统对齐。安全工具的采购指标不应只看拦截率，还要看团队能不能用这些信号改进工具权限和业务流程。
结论
Operant Semantic Firewall 代表了一个正确方向：agent 安全必须从文本过滤走向行为语义。Tool、Code、Data、Scope 四类守卫正好对应企业 agent 最容易出事故的四条路径。
我的建议是把它当成 agent runtime 的一层，而不是万能安全外壳。先整理工具清单和数据分类，在观察模式下接入，记录 1 到 2 周真实调用，再逐步打开阻断策略。安全产品的价值不在于拦截所有事情，而在于让团队知道 agent 正在做什么、为什么被允许、什么时候必须停下来。