速评：给 agent 的安全策略写在 prompt 里，等于贴了张纸条当锁

MakerChecker，一个给 AI agent 做安全网关的开源项目。静态扫描、人工审批、RBAC、职责分离、审计日志——单拎哪个词都不新鲜，做权限控制的库多了去了。但它切中的是行业一个集体装瞎的共识：把 agent 放出去跑，安全策略还停留在“在 system prompt 里写一句请自觉”。

这不叫安全，这叫祈祷。

最近半年，agent 从“帮你写代码”进化到“帮你转账、操作生产环境”，工具调用权限越来越大，安全思路还停在自然语言。用 prompt 跟 agent 说“没授权不要执行 shell 命令”——agent 点头说好的，上下文一长，或者被注入一段恶意指令，它就把刚才答应的事忘了。把安全策略写在和攻击面同一个通道里，等于没锁门，只是贴了张纸条。这剧本，眼熟——每轮新技术的安全债都是这么欠下的。

所以看到 MakerChecker 的第一反应是：终于有人在碰那个“不让它干”的层。嵌入式库默认拒绝，未授权的工具调用直接执行前拦掉。不是让 agent 自己判断“这个操作合不合适”，而是外面套个控制层说“这个你根本碰不到”。默认拒绝，把安全工作从模型那不可靠的指令遵循能力里剥离出来，放进代码里。这才是工程该干的活。审计日志也到位——哈希链加签名，任何一行被改，整条链都看得出来。这不是给开发人员看的，是给出事故之后给审计方看的：哪一步、哪个角色、在哪个环节放行的，赖不掉。禁止同一角色审批自身操作，一条规则过滤掉一半自导自演的“内部事故”。能把日志做成这个强度，作者是真见过事故现场的。

保留意见也有。扫描器和嵌入式库 Apache-2.0，服务器和 Web 界面 AGPL-3.0——这个分法挺有意思，谁在用、用得起来吗，我持观望态度。安全工具最大的敌人从来不是技术不够好，而是没人愿意多走一道审批流程。但我不太想在这个点上展开。

行业现在所有框架都在抢跑功能、抢跑 benchmark 分数，安全网关被扔在 last priority。agent 的能力往上冲，安全底座得先接住——等到出事了再补，那丢的就不是几个 token 了。这项目不是灵丹妙药，但这个“默认拒绝”的方向，在 agent 真正成为生产力之前，得先立住。

立个 flag：半年后回头看这项目，我不猜哪个大厂会跟进——大概率会跟。我就看一件事：MakerChecker 有多少部署是真的跑在 agent 前面做拦截的，而不是装完之后继续靠 prompt 裸奔。因为安全工具的命，永远不是技术那关，是人性那关。