MCP 选中工具之后，到安全执行之间还缺什么？

MCP 让 Agent 能够发现和调用工具。真实业务系统还需要回答：正确主体是否在正确状态下，对正确对象只执行了一次正确行动，并留下足够证据？

一次 tools/call 成功只证明协议请求到达工具服务，不自动证明业务安全完成。这不是因为 MCP “没有安全”，而是协议互操作与业务后果本来属于不同责任层。

五种责任，不一定是五个产品

责任层	应回答的问题	不能代替什么
工具协议 / MCP Server	工具如何发现、描述、调用和返回？	不知道企业用户能否操作某条订单
Agent Runtime	如何理解目标、规划步骤和选择工具？	不能凭模型判断创造业务权限
共享执行治理	哪些工具可见，何时审批，怎样幂等、恢复和审计？	不能替业务系统提交领域事务
企业身份与审批	这个主体是谁，谁有资格批准？	不能替每个业务域判断对象状态
业务系统	当前主体能否对当前对象产生最终后果？	不应独自承担跨 Agent 的工具发现与编排

这些责任可以部署在同一个进程，也可以由多个产品组合承担；关键是每一项都有明确事实源和失败边界。

“有权限”至少包含三个问题

工具访问权限：这个客户端或 Agent 是否能发现并调用该工具？
操作主体权限：请求代表哪个经过验证的用户、租户或门店？
资源级业务权限：这个主体此刻能否操作这一张订单、这一笔退款或这一名员工？

有效的 MCP Token 不是订单级授权；工具白名单不能替代租户隔离；业务系统保留最终授权，也不意味着所有危险工具都应该暴露给模型。

五类控制必须穿过整条链路

人工审批

界面可以在 Runtime，暂停和参数快照可以在治理层，审批资格来自企业系统，写入前仍由业务系统最终授权。一次审批至少绑定可信主体、能力、规范化参数和任务身份。

幂等与重复执行

Runtime 应保持稳定请求身份，治理层对派发去重，业务系统用领域幂等键和唯一约束防止跨入口重复后果。

重试与未知终态

超时不等于未执行。先查询或恢复同一任务，再向业务事实源核账；不要把网络失败直接变成新的写请求。

审计与证据

审计需要区分请求者、可信主体、批准者、执行者和最终业务结果。只记录一段对话或由同一 Runtime 自述批准，证据都不完整。

回滚与恢复

可逆、补偿和不可撤销是业务语义或 Workflow/Saga 设计。共享层可以触发业务已经定义的补偿动作，不能凭一个字段制造事务原子性。

一次 Agent 退款的正确路径

用户提出退款
  ↓
Agent Runtime 识别目标并选择 refund.preview
  ↓
治理层确认可信主体、路由、scope 与参数
  ↓
业务系统返回试算和当前可退款状态
  ↓
Agent 提交 refund.request.create 或 refund.execute
  ↓
高风险调用冻结参数并进入业务审批
  ↓
批准后重新检查身份、策略、参数、时效与业务状态
  ↓
业务系统用领域幂等键提交退款
  ↓
治理层记录调用、批准者和最终结果

模型提出行动，协议承载行动，Runtime 协调行动，企业系统建立身份和审批信任，业务系统授权并提交最终后果。

失败时应该怎样

失败	安全处理
无可信主体	工具保持不可见或调用被拒绝
route/scope 不允许	在业务请求发出前拒绝
审批参数变化	原批准失效，不能执行新参数
调用超时	进入未知终态并使用相同业务键核账
审计写入失败	不把它简化成可盲目重试的工具失败
业务最终授权失败	保留拒绝事实，不由中枢或模型绕过

ACC 与 BailingHub 的位置

Agent Capability Contract（ACC）用可移植、操作级声明表达能力触达和治理意图。它不执行工具、不定义企业身份，也不替代业务最终授权。

BailingHub是一个可自托管的具体实现，在业务工具调用周围处理可信主体、能力裁剪、审批绑定、任务状态、派发和追踪。相同职责也可以由 MCP Server、Agent 平台、API 网关、工作流引擎或它们的组合实现。