Agent 写数据：业务工具和动态代码要分开控制

所有写入都需要受控执行入口，但不是每次调用业务 API 都要额外运行一段沙箱代码。沙箱、授权、审批和审计各自负责不同问题。

两条路径

执行方式	教学示例	必要控制
已实现业务工具	修改获准订单的备注	可信身份、对象权限、参数与状态校验、事务／幂等及审计
动态代码或命令	生成脚本批量处理文件	上述控制，加工作区、网络、进程和资源隔离

沙箱限制代码接触什么，不能替数据库决定某个用户能改哪一行。护栏提供风险信号，也不能替代业务授权或事务约束。

从预览走到执行

先生成目标范围、预计影响数量和差异预览。需要审批时，将批准绑定到具体对象、参数与版本；恢复后复核当前权限和对象状态。目标变了，旧批准不能直接复用。

执行使用最小权限身份，限制影响数量、时间和批次。写入后向资源端确认结果，将任务、工具版本、授权依据和影响数量关联到脱敏审计。

超时不等于未发生

请求超时可能是提交未完成，也可能是提交成功但响应丢失。先按业务标识对账；确需重试时复用稳定幂等键。任务取消不会自动撤回已经发送的消息或已经提交的业务变更。

动态 SQL 同样需要限制身份、对象、语句类型和影响范围，不能仅用关键词正则判断安全。这里是通用设计建议，不是某个产品已经实现的保证。

参考：MCP 安全最佳实践。业务授权、事务和审批的组合为工程建议；整理：2026-10-14。