很多团队的 AI Agent 卡在同一处：demo 敢连测试库，一到要连生产数据就没人敢点头。差的往往不是模型能力，而是权限边界和人工接管闸没有建起来——出错没人拦、改错没人知道。
把 Agent 接进真实数据，本质是把一个不确定的执行者放进一套确定的权限体系里。下面是几条工程上的硬要求。
一、只读与写操作分层授权
第一步是把动作按“副作用”分层，而不是给 Agent 一把万能钥匙：
- 只读查询：可以相对宽松地授权，但仍要限定到具体表/字段/租户。
- 写操作：单独授权，且默认收紧——能查不代表能改。
- 高风险写操作（改订单状态、对外发消息、涉及资金/设备）：默认需要人工确认。
二、权限在工具层强制，不靠 prompt 自觉
一个常见的错误是把权限写进 prompt（“你不可以删除数据”）。模型不是可靠的权限边界。权限必须在工具实现层校验：每个 typed tool 声明它需要的权限，调用前由系统校验当前上下文是否被授权。
const updateOrderStatus = defineTool({
name: "update_order_status",
requires: ["order:write"],
highRisk: true, // 触发人工确认闸
async run(args, ctx) {
assertPermission(ctx, "order:write"); // 工具层强制，不信任 prompt
return db.orders.updateStatus(args.id, args.status, { actor: ctx.actor });
},
});
不给 Agent 一个“裸” SQL 或通用 HTTP 工具——那等于把权限边界交给模型自觉。给的是类型化、职责单一、带权限声明的工具。
三、每次读写都带审计与归属
被授权做，不等于做完就没人知道。每次读写都要落审计：谁（哪个 run、哪个角色）、动了什么、结果如何。归属（actor）要一路带到数据库操作，方便事后追溯和权限复盘。
四、人工接管闸怎么设计才不拖慢
“全部人审”太慢，“全部自动”不敢。做法是只对高风险动作设确认闸：
- 只读、低风险写：直接执行。
- 高风险写：生成一个待确认动作，人工点确认后才真正执行；超时未确认则丢弃。
这样绝大多数调用无需人工介入，人只花在真正有风险的动作上。
flowchart TD
A[Agent 发起动作] --> B{高风险?}
B -->|否| C[工具层校验权限 -> 执行 -> 审计]
B -->|是| D[生成待确认动作]
D --> E{人工确认?}
E -->|确认| C
E -->|超时/拒绝| F[丢弃 + 记录]
常见问答
Q：直接给 Agent 一个数据库连接不行吗？ A：不建议。给类型化工具，带权限声明和审计；裸连接把权限边界完全交给模型，风险不可控。
Q：权限校验放模型还是代码里？ A：一定放代码（工具层）。prompt 里的约束是提示，不是边界，模型可能绕过。
Q：状态已经被改乱了怎么办？ A：说明当前后台还不具备安全接管条件。先把状态机、权限和审计补齐，再谈让 Agent 写入。
权限边界做对了，才敢让 Agent 碰真实数据。这正是生产就绪审查里“安全动作 / 权限”这一支柱的核心：上线前把可越界的动作、缺失的人审闸列成 P0，先补齐再接入。如果你想先自查权限边界和人审闸是否到位，可以做一次生产就绪自检。