企业 MCP 鉴权网关：persona × credential 与服务账号授权边界
企业 MCP 鉴权网关：persona × credential 与服务账号授权边界
知识点轴：MCP Gateway / harness-runtime / sandbox-security。可复用的是身份与凭证分开建模，以及附加服务账号凭证前的 entitlement check；论文的 ROPC 做法不能作为现代安全推荐照搬。
为什么对用户重要
同一个 MCP endpoint 可能既服务用户交互，也服务无人值守 cron。调用协议相同，不代表代表谁行动、借用谁的权限相同。对 Hermes 或企业 coding-agent，如果只记录「agent 调用了某工具」，很容易漏掉后台高权限服务账号和发起人的对应关系。
Suraj Kumar、Amy Wang、Srinivasan Manoharan 的论文 A Gateway Architecture for Enterprise MCP Authentication（arXiv:2608.10760）给出企业部署叙述和鉴权矩阵。生产规模与运行成效是作者报告；本轮完整读取论文，没有访问其内部部署。^[raw/articles/enterprise-mcp-persona-credential-boundaries-2026-09-12.md]
一阶原理：persona 不是 grant type，也不是工具名
论文把两个轴拆开：
- Persona：User，带有某个真实用户的授权；Non-user，工作负载/服务账号代表自身。
- Credential：无鉴权、API key、授权码 + PKCE、client credentials、平台 app-context 等下游机制。
先确定主体和代表关系，再选择凭证适配，不能因下游恰好只收 API key 就抹去真实发起人。相同服务账号可以被后台工作负载使用，也可能被人触发，但后者必须额外检查人的 entitlement。^[raw/articles/enterprise-mcp-persona-credential-boundaries-2026-09-12.md]
| 流程 | 网关必须确定 | 下游实际执行身份 |
| User → 用户 OAuth | 用户身份、工具授权、目标资源 scope | 用户 |
| Non-user → 服务账号 | 工作负载身份、允许的 SA/工具/目的地 | 服务账号 |
| User → 服务账号 | 用户是否被允许借用这个 SA 做这个动作 | 服务账号；审计同时保留发起用户 |
这是 grafana-mcp-session-identity-and-egress-boundaries 的补充：token 不离开网关，只减少凭证泄露，不等于消除了 confused deputy。发起用户仍可能诱使网关替自己使用更高权限。
机制：授权点要放在权限真正切换之前
论文的关键次序是：解析发起人 → 检查 user-has-SA-access → 允许后才附加 SA credential → 下游执行 → 记录 initiated-by / executed-as / decision。拒绝不能在调用结束后才补写；工具级网关授权也不能取代下游的数据级权限。^[raw/articles/enterprise-mcp-persona-credential-boundaries-2026-09-12.md]
建议的迁移模板（本篇综合，不是已部署配置）：将 entitlement 绑定 caller + actor/workload + service_account + tool/action + destination + policy_version + event_time；租户、目的地或动作变化均重新判定。它应进入 MCP-Gateway-Runtime 和 Harness-Engineering 的同一审计链，而不是额外创造一个只有论文能解释的字段体系。
必须保留的标准冲突与限制
1. 「机器身份限定 ROPC」不构成安全规范豁免
论文把 ROPC 限于机器身份，并将其描述为一种企业遗留/现行路径；但 RFC 9700 §2.4 明确写 MUST NOT 使用 resource owner password credentials grant，没有机器身份例外。本页 contested: true 标记该冲突，吸收架构思想但不推荐该 grant。新设计应根据 IdP 能力采用 client credentials、工作负载身份或合适的 token exchange；客户端认证优先考虑 RFC 9700 §2.5 所述非对称方式。^[raw/articles/rfc9700-oauth-security-selected-sections-2026-09-12.md]
2. act 嵌套不等于每一跳都出具双边授权
RFC 8693 §4.1 允许用嵌套 act 表示委托历史，但访问控制 MUST 只考虑顶层 claims 与当前 actor；更深历史 actor 仅供信息记录。授权服务器签了包含历史的 JWT，不等于每个父 agent 对某条边都签了同意。这与 a2a-output-attestation-and-delegation-ancestry 的双边授权证据不是一回事。^[raw/articles/rfc8693-token-exchange-selected-sections-2026-09-12.md]
3. audience 与撤销要按 token 角色和部署合同核验
论文提示其 AT1 的 audience 应按 agent client ID 校验；这是其具体交换路径，不应泛化成「所有 MCP access token 都以 agent 为 audience」。RFC 9700 §2.3 要求资源服务器拒绝并非发给自己的 access token；RFC 8693 则将 subject/actor token 的具体有效性留给 token 类型和部署。先区分输入 subject token、actor token、输出资源 token，再检查 issuer、audience、scope 与授权主体。^[raw/articles/rfc9700-oauth-security-selected-sections-2026-09-12.md] ^[raw/articles/rfc8693-token-exchange-selected-sections-2026-09-12.md]
Token exchange 也不会自动建立输入/输出 token 的持续关联；输入 token 失效/续期/撤销如何传播，需要实现明确支持，不能仅凭用了 RFC 8693 就宣称注销闭环。^[raw/articles/rfc8693-token-exchange-selected-sections-2026-09-12.md]
对 Hermes / agent workflows 的实际启发
- 先梳理同一工具的交互用户与 cron 两条身份路径；禁止把无人值守自动化标成某用户「临时在线」。
- 针对 User→SA 加三个负例：无 entitlement、跨租户、允许工具但不允许目的地；断言 credential injection 之前即拒绝。
- 日志不要记录 token 明文；记录发起人、执行主体、目标、策略版本、拒绝点与后端执行证据，并测试撤销后的下一次请求。
迁移到私有 tunnel 可以减少公网暴露，但不会消除每请求授权、SA 借权或审计要求。论文也把 tunnel 与 token 职责分开。^[raw/articles/enterprise-mcp-persona-credential-boundaries-2026-09-12.md]
尚未证明什么
本轮没有论文部署源码/运行回执、跨网关撤销实验、RFC conformance 测试或用户实际 IdP 配置。不能把此文当作可直接复制的安全配置。最耐久的收获是：架构案例可以提供机制，也可以同时暴露与标准冲突的局部实现。
相关：AI-Knowledge-Point-Radar · A2A-Agent2Agent-Protocol。
写入记录
- 2026-09-12 09:16 CST：新增身份/凭证双轴与 User→SA 授权机制，交叉核对 RFC 9700 / 8693；明确 ROPC 冲突、历史 actor 的授权边界及 audience/撤销的部署依赖。