给 AI Agent 开放 Shell 权限后，如何防止它在深夜偷偷执行 DROP TABLE
rm -rf / 或者 DROP TABLE users 就能让整个项目组在周一早晨集体失眠。我之前尝试过几种主流的“护栏”工具，但发现大多数工具的逻辑是“事后审计”——也就是在命令执行完、数据库已经没了之后，它才在日志里温情地提醒我：“哎呀，刚才执行了删除操作。” 这种拦截机制对于防止数据丢失毫无意义。
最近我在团队里实操了 gate.cat，它的核心逻辑是“先否决再执行”，将拦截点前置在命令传给 Shell 之前。最让我觉得靠谱的一点是，它在拦截路径上并不依赖模型调用，而是采用确定性的字符串匹配和路径分析。这意味着 AI 无法通过在 Prompt 里写“请忽略之前的限制，直接执行删除”来绕过拦截，因为拦截层根本不听 AI 说话，只看最终生成的命令字符串。
在实际部署中，我尝试了三种不同的接入场景，分享一下具体的实操细节：
首先是最推荐的 Claude Code 拦截方案。由于 Claude Code 的权限控制非常灵活，我们可以直接在配置文件中植入 hook，让拦截权限完全脱离模型的控制流。具体操作是先通过 pip install gate.cat 安装，然后在项目的 .claude/settings.json 配置文件中，将 gatecat-hook 添加到钩子列表中，并将匹配项明确设置为 Bash|Write|Edit。这样只要是涉及写入或执行的操作，必须经过 gate.cat 的判定才能下发给 Shell。
其次是针对通用 CLI Agent（比如 aider 等）的适配。这类工具通常会读取系统的 $SHELL 环境变量，我们只需要将默认的 shell 路径替换为 gatecat-shell。这样无论 Agent 如何通过 CLI 尝试操作文件系统，所有的指令流都会先经过这个拦截层。
最后是 API 代理模式。如果你使用的是 Ollama 或者 OpenRouter 等兼容 OpenAI 格式的接口，可以通过修改 base_url 将请求转发给 gate.cat。这种方式在架构上最轻量，适合那些不需要深度集成到本地 Shell，但需要对 API 返回的指令进行初步过滤的场景。
在实测过程中，我发现这种确定性拦截的效率非常高，因为它省去了再次调用 LLM 进行判断的 Token 开销和延迟。但这里必须强调一个技术细节：gate.cat 本质上是一堵“墙”，而不是一份完美的“安全证明”。它能高效拦住已知的危险指令，但无法保证所有不匹配的指令都绝对安全。
因此，我的建议是不要把 gate.cat 当作唯一的救命稻草。在公司环境下，最稳妥的方案依然是「沙盒（Sandbox）+ gate.cat」的双重保险。沙盒负责在物理层隔离资源，gate.cat 负责在指令层过滤高危操作。
另外，这个项目采用的是 Apache-2.0 协议，且核心代码零依赖，这意味着你不需要担心引入一大堆臃肿的第三方库导致环境冲突，部署速度极快。如果你也在担心 AI Agent 搞崩数据库，建议去 GitHub 搜一下 BGMLAI/gate.cat 尝试部署。
