AI Agent 的工具调用谁来把关？Agent Chaperone 用双层防火墙拦住危险动作
AI 编码 Agent 真正危险的地方，往往不是它生成了一段不够优雅的代码，而是它已经拿到了执行命令、写文件、读取网页或调用 MCP 工具的权限。传统的权限弹窗只能回答“用户是否允许”，却不一定能判断参数里是否藏着敏感数据，或者工具返回的内容是否在反过来诱导 Agent。
Agent Chaperone 是一个 Apache-2.0 许可的 TypeScript 工具，定位不是沙箱，也不是权限系统的替代品，而是一层可校准的工具调用防火墙。它在调用发出前检查参数，在结果交回 Agent 前检查内容，并把每次判断和产生判断的分数写入本地日志。
先从 shadow 模式开始
安装很直接：
npm install -g agent-chaperone
默认模式是 shadow。它会执行检查，但不会阻断任何调用。这样做很实用：先让 Agent 正常工作，再通过日志观察哪些操作本来会被拦截，避免一上来就把开发流程锁死。
agent-chaperone log
日志会显示调用类型、决策、风险分数和估算成本。例如一次写文件操作可能被记录为“本来会 hold”，而结果因为像是在给 Agent 下指令而被 withheld。确认规则符合预期后，再把策略文件中的模式切换为 enforce。如果连检查服务都不可用也必须停止，则使用 strict。
MCP 代理 + 客户端 Hook
Agent Chaperone 不是只盯着 MCP。MCP 流量可以通过代理接入：
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y", "agent-chaperone", "--",
"npx", "-y", "@modelcontextprotocol/server-filesystem", "."
]
}
}
}
-- 后面的命令仍然是原本要运行的服务器，前面的 Chaperone 负责包住它。项目还提供 agent-chaperone wrap 来修改配置；它默认只打印将要改变的内容，增加 --write 才写入，并保留原文件。重复执行不会继续叠加修改。
但很多客户端自带的 Bash、Edit、Write 和 WebFetch 并不经过 MCP。因此，项目还提供 Hook 适配器，在 PreToolUse 阶段检查动作，在 PostToolUse 阶段检查结果。对 Claude Code 一类客户端，可以把 agent-chaperone hook pre 和 agent-chaperone hook post 接到对应 Hook 上，覆盖代理看不到的内置工具。
检查什么，如何处理异常
调用前的检查包括破坏性操作、向外发送私有数据或密钥、策略违规，以及操作失败时的潜在影响。结果返回前，则重点检查提示注入、秘密泄露和“把内容当指令读给 Agent”的情况。
工具调用被 hold 后不会直接执行。用户可以先查看详情，再只批准这一次调用：
agent-chaperone showagent-chaperone approve
批准令牌绑定到具体服务器、工具和参数；批准一次写入并不等于放行另一个路径的写入。被策略明确 deny 的调用也不能靠 approve 绕过，这种区别让临时人工确认和长期规则保持分离。
工具列表本身还有一层本地摘要比较：当服务器新增、删除或改写工具描述时，变化会被报告。默认不会把工具描述发送给模型；只有显式打开 screen_tool_descriptions 才会进行这项内容筛查。
数据和边界必须看清
这个工具不能代替 OS 级沙箱，也不能阻止一个服务器执行调用描述之外的副作用。更重要的是，模型筛查会把待检查的参数和结果发送到配置的模型后端，虽然秘密形状字符串会先脱敏，也可以按服务器关闭内容筛查，但“本地安装”不等于“所有数据都留在本机”。对敏感代码库，应该先确认后端、日志存储和 --no-store-content 策略。
项目 README 给出的基准也不应被理解为安全保证：使用 Jev 1.13.0、一次请求一项的测试中，InjecAgent tool responses 的 AUC 为 0.976，BIPIA email 为 1.000，手工标注工具调用为 0.993；同一份材料同时列出了漏检和误报。实际部署仍应从 shadow 日志开始调阈值，而不是直接照搬数字。
适合什么场景
如果 Agent 只做只读问答，Chaperone 可能显得偏重；但在它能执行 Git、修改工作区、访问 MCP 服务或处理外部网页内容时，这种“调用前 + 结果后”的双层检查很有价值。比较稳妥的落地顺序是：先接入 MCP 代理，再把客户端内置工具接到 Hook；先使用 shadow，确认日志与团队预期一致后，再逐步启用 enforce，并为高风险仓库单独设置更严格的策略。
它解决的不是“让 Agent 永远不会犯错”，而是把一次不可见的自动动作，变成可解释、可记录、可人工批准的决策点。