devgo.cn大模型 Agent 越来越能干，能写文件、发邮件、调 API，但这也意味着一个被提示词注入的模型，可能在你眼皮底下执行危险操作。你当然可以把所有工具调用都交给云端平台审核，但那样一来，你的数据、你的密钥、你的执行记录全都过了一遍别人的手。DeadBolt 的思路很直接：把审核这道闸门，从云端搬到本地，放在真正执行动作的那行代码里。
它不是一个沙箱，也不拦截网络流量，更不是独立计费系统。它只做一件事：在你自己的代码调用某个动作之前，先问一句“这个动作该不该执行”。你把它嵌进 Rust 程序，或者作为本地 sidecar（一个独立运行的小进程，主程序通过它来请求决策）供 Python、Node 调用，甚至可以直接包在 MCP 服务器外面，让现有工具链无缝接入。
最让我意外的是它的部署方式：不需要模型账号、不需要 API key、不需要任何云端服务，下载一个原生可执行文件就能跑。v1.0.3 版本提供了 Linux、Windows、macOS 的预编译包，解压后直接 `./deadbolt drill` 就能跑通一个完整的自检，它会启动一个私有 sidecar，写几个无害的临时文件，验证策略、审批、终止、故障阻断这些效果，然后清理干净。整个过程只需要 Python 3.9+，连 Rust 编译环境都不用装。
核心机制是“许可”（lease）。默认情况下，每个工具调用会获得一个 60 秒的滑动窗口许可，窗口过期后必须重新申请。被终止的 ID 会保持终止状态，它的所有子调用也会被一并阻断。对于不可逆的操作，比如转账、删除、发送邮件，你可以配置“一次性审批”，操作员在本地 CLI 上确认后，这次调用才被放行。v1.1.0 的候选版本更进一步，支持对精确参数（比如收款人、金额、邮件正文）进行审查，而不是笼统地批准整个工具。
策略配置也很有意思。你可以设置工具白名单、目标地址限制、上报费用上限，甚至给每个 run（一次完整的 Agent 任务）单独配置策略。默认情况下，如果存储不可用，它会直接拒绝执行——宁可什么都不做，也不冒险放行。所有决策记录都写入 SQLite 证据库，同时输出 JSONL 镜像，方便事后审计。
但 DeadBolt 的边界也很清晰。它信任你的执行器，信任你配置的下游服务器，信任 MCP 子进程——它不隔离任意代码，也不阻止模型提供商，更无法让外部副作用与审批操作保持事务性一致。换句话说，它管的是“动作该不该发生”，而不是“动作发生之后怎么收场”。
这套设计的价值在于，它把 Agent 安全从“平台责任”变成了“应用责任”。你不需要把控制权交给某个 Harness 或云服务，而是自己掌握策略、审批和证据。对于在本地跑 Agent、处理敏感数据、或者想对工具调用有细粒度控制的开发者来说，这是一个可以直接落地的方案。接入方式也很灵活：Rust 应用加一个依赖，Python 应用起一个 sidecar，OpenAI Agents SDK 用户可以用装饰器标记受保护函数，MCP 服务器用户则可以直接替换启动命令。
需要注意的坑是：策略列表默认是开放的，你必须为每个 run 和子任务显式配置；身份、工具路由、目标地址这些信息来自可信的应用代码，不是网络拦截，所以如果你的应用本身被攻破，DeadBolt 也拦不住。部署前最好读一遍信任边界文档，用它的试点清单核对一下你的实际路由。
DeadBolt 用 Apache-2.0 协议开源，代码质量有保障——`cargo test`、`clippy` 和 Python 契约测试都在 CI 里跑着。如果你正在为 Agent 的工具调用安全发愁，与其等平台提供审核能力，不如先在自己代码里加一道本地闸门。
内容与图片版权归原作者所有 · 原文: https://github.com/seanebones-lang/deadbolt