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

THE BOUNDARY

一次 `tools/call` 成功，不等于业务安全完成

如果工具开始退款、改库存、停账号、发通知或触发部署，协议成功只说明请求到达了允许访问的工具服务。它不能单独证明主体、对象、审批、幂等、业务状态和责任证据都正确。

协议成功

一个结构正确的请求，是否通过协议授权送达给了 MCP Server？

业务完成

正确主体是否在正确状态下，对正确对象只执行了一次正确行动，并留下足够证据？

这不是因为 MCP “没有安全”。MCP 已提供工具协议、HTTP 授权规范与安全实践；缺口来自协议互操作和业务后果本来就是不同层次的问题。

RESPONSIBILITY MAP

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

责任按语义划分，而不是按进程数量划分。同一个部署可以承担多项责任，但不能因为放在一个盒子里就省略它们之间的边界。

层次	主要责任	不能替代
工具协议与 MCP Server	工具发现、Schema、协议调用、协议授权、执行接口	业务对象的最终授权
Agent Runtime	理解任务、选择工具、生成参数、维护工作流、人机交互	可信业务身份与最终权限
共享执行控制	Reach、可信上下文、审批绑定、任务状态、去重、派发与追踪	企业身份、审批权威、事务与全部业务规则
企业身份、策略与审批系统	解析身份、组织策略、审批资格	真实业务操作
业务系统	租户隔离、对象授权、当前状态、不变量、事务和最终执行	盲目信任上游声明的被动后端

PERMISSIONS

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

1

MCP 协议授权。当前客户端能否访问这个 Server？OAuth Scope、Token Audience 和过期时间属于这里。

2

能力 Reach。当前 Agent 场景应该看见哪些工具？售后 Agent 可以触达退款申请，不应看见员工删除。

3

业务 Authority。当前主体此刻能否对这个对象执行这次操作？订单状态、剩余可退金额、租户边界和对象权限属于这里。

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

END-TO-END CONTROLS

五类控制都必须穿过整条执行链

人工审批

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

幂等与重复执行

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

重试与部分失败

超时不等于未执行。调用方应查询或恢复同一任务，而不是盲目创建新的写请求；重试安全最终依赖业务边界的幂等。

审计与证据

要能区分请求者、可信主体、批准者、执行者和最终业务结果。由同一 Runtime 自己声明审批并书写唯一日志，仍然只是自述。

回滚与恢复

可逆、补偿和不可撤销属于业务语义或 Workflow / Saga。共享层可以触发已定义的补偿，不能凭字段制造事务原子性。

MINIMUM PRODUCTION PATH

以一次 Agent 退款为例

refund execution path

用户提出退款
  -> Runtime 选择 refund.create 并提出参数
  -> MCP Client 通过协议授权调用 Server
  -> 执行控制检查 Reach，并从可信来源解析主体
  -> 如需审批，暂停在精确参数快照上
  -> 同一任务携带审批证据和稳定幂等身份恢复
  -> 业务系统重新校验主体、租户、订单、金额与状态
  -> 业务系统提交或拒绝
  -> 结果与证据链写回同一任务

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

FAILURE SEMANTICS

比“支持治理”更重要的是失败时会怎样

失败情况	保守处理
可信主体缺失或无法验证	不派发要求主体的操作
审批证据与精确请求不匹配	拒绝执行或重新审批
超时后执行状态未知	查询同一任务，不盲目新建写请求
可重试写操作没有幂等身份	拒绝自动重试
业务授权失败	返回最终拒绝；上游审批不能覆盖它
审计存储不可用	执行明确的 fail-open / fail-closed 策略，不伪造“已落盘”
补偿没有定义	报告不可逆或人工恢复，不宣称支持回滚

CONCRETE EXPERIMENTS

ACC 与 BailingHub 在这张图中的位置

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

BailingHub（百灵中枢）探索一个可自托管的共享执行控制面，在业务工具调用周围处理能力触达、可信主体、审批绑定、任务状态、派发和追踪。它是一个具体实现，不是唯一架构。

同样的责任边界也可以被实现在 MCP Server、Agent 平台、API 网关、工作流引擎或它们的组合中。重要的是每项责任都能被明确回答和独立验证。

运行 Docker Demo 查看工具接入

PRIMARY SOURCES

参考资料

MCP Tools specification

工具发现、Schema、调用与工具相关协议语义。

MCP Authorization specification

HTTP 传输下受保护资源、OAuth 流程与令牌受众约束。

MCP Security Best Practices

Scope、会话、凭证、沙箱和逐次授权等安全实践。

MCP Tasks utility

长任务、状态查询和延迟结果的协议工具。

一次 tools/call 成功，不等于业务安全完成