企业 MCP Gateway：多云工具统一入口不等于共享一把万能钥匙
2026 年 10 月 20 日，AWS 与 Eon 公开多云调查 MCP Gateway 架构。Eon 将 AWS、GCP、Azure 及 GitHub、Grafana 等工具的本地 MCP 进程和分散凭证，收敛为一个经认证的远程入口；开发者通过企业 SSO，自治 SRE Agent 使用 client_credentials，Gateway 在每次 tools/call 前执行 Cedar 策略。
统一入口常被误解为“把所有工具挂到一个超级 token 后面”。正确做法恰好相反：入口统一，身份不统一；协议统一，授权仍细到 principal、tool、action 和环境。
Gateway 是策略执行点和协议边界，不应该成为凭证集中泄漏点。
先分开人类与工作负载身份
人类通过 OIDC/SSO 登录，JWT 携带组织、组和会话；Agent 使用独立 workload identity 和短期 client credential。两者都映射到统一 principal，但策略不同。
// human
{"sub":"user:alice","groups":["sre"],"auth_time":1792476000}
// autonomous agent
{"sub":"agent:incident-investigator-v7","tenant":"prod","grant":"client_credentials"}
不要让后台 Agent 复用某位工程师的 token。人员离线或离职后，自治运行会失去合法责任边界。
工具清单也要按主体过滤
Gateway 聚合数百工具时，tools/list 不应向每个主体返回完整 catalog。先执行可见性策略，只暴露允许发现的工具；调用时再执行参数级授权。否则工具名、描述和 schema 本身可能泄漏内部系统结构。
permit (
principal is Agent::Workload,
action == Action::"mcp:Call",
resource is Tool::CloudReadOnly
) when {
principal.tenant == resource.tenant &&
resource.risk == "read"
};
forbid (
principal,
action == Action::"mcp:Call",
resource
) when { resource.environment == "prod" && resource.risk == "destructive" };
实际策略还需要用户委托、事件严重度和变更窗口。禁止规则优先，不能被更宽泛 permit 覆盖。
stdio 到 HTTP 的转换需要会话语义
许多 MCP Server 原本是本地 stdio 进程，远程化后要处理 Streamable HTTP、会话隔离、超时、取消和背压。每个客户端会话绑定 principal 与租户，不能因为连接复用而共享服务器进程状态。
目标服务部署在不同账户或云时，Gateway 不应持有长期全局密钥。通过目标侧角色、workload federation 或短期凭证调用；审计同时记录入口 principal 与目标云实际身份。
Gateway 需要资源和故障隔离
一个慢 MCP 不能拖住所有调查。为每个目标设置并发、超时、熔断、响应上限和重试策略；写操作默认不自动重试，除非有幂等键。工具返回视为不可信数据，进入模型前标记来源并扫描提示注入。
targets:
grafana-query:
timeout_ms: 8000
max_concurrency: 20
max_response_bytes: 1048576
retries: 1
production-delete:
enabled: false
Gateway 自身成为关键基础设施，需要多可用区、配置版本化、策略回滚和只读降级模式。控制面故障不能自动放宽策略。
可观测性要关联两段调用
客户端 → Gateway 与 Gateway → 目标服务是两段信任链。传播 trace context，同时记录策略版本、工具版本、目标账户、延迟、响应大小和结果。敏感参数只记录分类与哈希。
企业 MCP Gateway 的验收应包括跨租户枚举、Agent 冒充用户、策略热更新、目标超时、返回超大内容、恶意工具描述和多云凭证撤销。单一 URL 只解决接入体验；只有身份分离、最小权限和故障隔离同时成立，它才是平台，而不是新的单点风险。