很多团队做 Agent 时，第一反应是“先把工具接起来”。
这一步没错，但只做连接、不做治理，系统上线后很快会遇到三类问题：
- 权限边界混乱。
- 工具调用不可审计。
- 高风险操作无法及时阻断。
MCP 的真正价值不只是“统一接口”，而是把工具调用放进可治理的系统里。
架构图：MCP 安全治理栈
时序图：一次高风险动作是如何被拦截的
为什么 MCP 场景一定要做安全治理
1. Agent 能做“动作”而不是只生成“文本”
一旦接入工单、支付、客户系统，错误动作的代价会远高于错误回答。
2. 工具越多，风险面越大
工具调用链变长时，任何一个弱环节都可能成为越权入口。
3. 责任追踪必须可落地
生产事故发生后，必须回答四个问题：
- 谁发起了动作？
- 基于什么上下文？
- 调用了哪个工具？
- 为什么被允许/被拒绝？
可直接落地的 5 个控制点
- 权限前置：在 Gateway 层做角色和 scope 校验，不把权限逻辑散落到各工具。
- 策略集中：用 Policy Engine 管理“谁在什么条件下能调用什么工具”。
- 敏感动作二次确认：如退款、删改客户数据，默认人工确认。
- 全链路审计：每次调用都打审计日志并可关联到会话。
- 异常告警闭环：被拒绝的高风险动作也要告警，不仅仅是失败动作。
指标建议（上线后每周看）
| 指标 | 目标 |
|---|---|
| 高风险调用拦截率 | 持续提升 |
| 非预期拒绝率 | 持续下降 |
| 平均审计定位时长 | 持续下降 |
| 人工接管占比 | 在安全阈值内可控下降 |
结语
MCP 时代的工程竞争，不是“谁接得快”，而是“谁接得稳”。
把安全治理栈和连接栈一起设计，才是企业级 Agent 能持续演进的前提。