场景：你的 AI Agent 在裸奔吗？MakerChecker 给 Agent 装上安全层

问题：Agent 能做很多事，但谁来阻止它做不该做的事？

你正在开发一个能自动操作数据库、调用支付 API、读写文件系统的 AI Agent。功能跑通了，老板很满意。但一个念头始终挥之不去：如果 Agent 在某个边界案例中调用了不该调用的工具怎么办？

这不是杞人忧天。MakerChecker 团队维护的 AI Agent 安全事件数据库已经记录了 41 起真实事故——从数据库被清空到 API 账单失控循环。Agent 被越权操作仅仅是一个错误的工具调用之遥。

传统方案怎么做的？要么在 Prompt 里写「不要做危险操作」，要么在代码里手写大量的 if-else 权限检查。Prompt 级别的约束，模型根本不保证遵守；手写权限检查，每次新增工具都要改代码，维护成本直线上升。

MakerChecker 把安全控制从 Prompt 级别提升到代码级别——在每个工具调用前设一道关卡，拒绝权限不足的请求，并记录每一步到可离线验证的签名审计链中。

快速上手：5 分钟体验 Agent 被拦截

安装和体验 MakerChecker 非常简单，只需要 Docker：

git clone https://github.com/sammysltd/makerchecker
cd makerchecker
docker compose up

Compose 启动 Postgres 17 和服务端，运行迁移，并注入演示数据：一个现金对账流程、演示用的 Agent、以及管理员和审批官两个账户。服务端监听 http://localhost:3000，既提供 API 也提供 Web UI。（注意：服务端包需从源码构建，CLI 工具如扫描器和嵌入式库已发布到 npm，可直接用 npx/npm i 安装使用。）

启动日志会打印两个 API Key：admin key（Agent 验证运行时使用）和 officer key（人类审批官确认操作时使用）。注意这两个 Key 只在首次启动时打印一次，丢失后无法找回。

现在，我们来看一个实际的拦截案例。

export ADMIN="mk_admin_xxx"

curl -X POST localhost:3000/api/flows/pv-icsr-processing/runs \
  -H "authorization: Bearer $(ADMIN)" \
  -H 'content-type: application/json' -d '{}'

curl localhost:3000/api/approvals \
  -H "authorization: Bearer $(ADMIN)"

此时系统有一个待审批项。关键是——发起者不能用同一个身份来审批自己的请求：

curl -X POST localhost:3000/api/approvals//decision \
  -H "authorization: Bearer $(ADMIN)" \
  -H 'content-type: application/json' \
  -d '{"decision":"approved","reason":"self-approval attempt"}'

只有持有 officer key 的独立审批官才能通过：

export OFFICER="mk_officer_xxx"

curl -X POST localhost:3000/api/approvals//decision \
  -H "authorization: Bearer $(OFFICER)" \
  -H 'content-type: application/json' \
  -d '{"decision":"approved","reason":"Seriousness confirmed; file 15-day expedited ICSRs."}'

这就是 MakerChecker 的职责分离——发起者不能批准自己的工作，这不是 Prompt 层面的「请自觉」，而是代码层面的硬性 403。

扫描：先知道你的 Agent 能做什么

在给 Agent 装上安全层之前，先要知道它当前能做什么。MakerChecker 提供了一个离线静态扫描工具 mc scan：

npx @makerchecker/scan .

它会读取你的 Agent 工具定义，标记所有无防护的危险操作——删除数据、转移资金、执行 shell 命令、窃取密钥——每一条发现都关联一个真实的安全事件 ID。扫描默认在本地运行，不离开你的机器，不做任何遥测上报。

npx @makerchecker/scan .

扫描结果可以直接生成 mc-policy.json 治理文件——这是一份声明式权限策略，你可以提交到 Git 仓库，让 CI 流水线也执行同样的检查。

核心功能：三组件架构

MakerChecker 分为三个独立包，每个可以单独使用：

1. @makerchecker/embedded — 嵌入式治理

在代码中引入治理原语，给 Agent 的工具调用加上权限门：

import { createGovernor, GovernanceDeniedError } from "@makerchecker/embedded";

const gov = createGovernor()
  .defineSkill("place-order@1", { riskTier: "high" })
  .defineRole("agent")
  .defineRole("risk-desk")
  .grant("risk-desk", "place-order@1")
  .defineAgent("trader", "agent");

const placeOrder = gov.governedTool(
  "trader", "place-order@1",
  (order) => broker.submit(order)
);

try {
  await placeOrder({ symbol: "BTC", qty: 10 });
} catch (err) {
  if (err instanceof GovernanceDeniedError) console.log(err.code);
  // → "skill_not_granted"
}

每一个技能（Skill）都有名称和版本号，每一个 Agent 都有角色，每一项权限都显式 Grant——没有被 Grant 的操作默认被拒绝。

2. mc scan — 静态代码扫描

前面已经介绍过，它是 CI 流程的第一道防线。你可以把生成的 mc-policy.json 提交到仓库，后续的 CI 构建会自动对比策略文件，让治理变成自动化门禁。

3. 自托管服务器 — 集中治理 + 审计

当需要集中管理多个 Agent、提供人类审批面板、以及可离线验证的审计日志时，运行自托管服务端：

docker compose up

服务端基于 Fastify 和 Postgres 构建，提供：

• 权限检查：每次工具调用前验证 Agent 角色和技能匹配
• 审批面板：高风险操作的审批收件箱，Web UI 实时查看
• 审计链：每条记录 Ed25519 签名 + SHA-256 哈希链

验证审计链的完整性不需要 MakerChecker 的代码——任何人都可以离线运行验证器：

npx @makerchecker/proof-verifier verify bundle.json

横向对比：MakerChecker vs 其他 Agent 安全方案

注意事项

• Agent 框架支持：目前已提供 LangChain 和 Claude Agent SDK 的连接器，CrewAI 等原生无连接器，但可以通过 TypeScript/Python SDK 自行包装
• 首次启动 Key 管理：admin key 和 officer key 只打印一次，务必保存。丢失后需要重新 seed 数据库
• 包尚未发布：目前需要从源码运行，npm 发布即将推出
• 小规模场景可能过度设计：如果只是一个单 Agent 玩具项目，@makerchecker/embedded 嵌入式模式就够用了，不需要跑服务端
• 成本：自托管无额外费用，仅消耗服务器资源

总结

如果你的 AI Agent 开始接触真实世界的操作——操作数据库、调用支付接口、修改文件系统——那么它需要一个独立于模型之外的安全层。MakerChecker 提供了一个开源的、可自托管的解决方案：静态扫描发现风险，嵌入式治理拦截越权，签名审计链让合规可验证。

它不改变 Agent 的现有工作流，只是在你和 Agent 之间加了一道独立的检查关卡——让 Agent 在它的角色允许范围内自由发挥，超出范围的事，交给审批官决定。

相关链接：

• GitHub 仓库
• 官方网站
• 文档
• AI Agent 安全事件数据库