我们发布了一个MCP服务器，代理继承人类身份。然后我们不得不弄清楚这个身份来自哪里。

Reddit r/AI_Agents 产品
mcp-server identity authentication oauth rbac open-source ai-agents

摘要

我们发布了一个MCP服务器，代理继承人类身份，实现了OAuth 2.1联合身份认证和每个IdP的声明映射器，以解决代理身份管理和RBAC策略评估问题。

嘿！大多数生产环境中的MCP服务器将代理自身认证为独立实体。使用服务账户、静态承载令牌，审计日志显示'Claude Code做了这个。'三个工程师使用同一个代理，你就无法分清谁请求了什么。我们在构建一个开源访问网关时遇到了这个问题，并在过去几周内发布了两个比我们预期更相关的更改。第一：我们发布了一个用户MCP服务器，代理以启动会话的人类用户身份行动。RBAC、审批门、数据掩码，全部基于人类评估，而非代理。关键设计决策：代理没有自己的身份，而是继承一个身份。第二：一旦代理继承了人类身份，下一个问题就是这个身份来自哪里。我们的第一个版本在网关内部映射身份。虽然可行，但创建了第二个事实来源，必须与客户的IdP保持同步。今天，我们在MCP端点上发布了OAuth 2.1联合身份认证。实现了MCP 2025-11-25授权配置文件，RFC 9728保护资源元数据以实现自动发现。协议部分是最简单的。困难的部分是组声明的标准化。Okta称之为`groups`。Auth0将其放在带命名空间的自定义声明中。Entra ID使用对象ID，除非你翻转租户设置。我们的RBAC引擎需要一种格式来评估策略，因此我们最终采用了每个IdP的声明映射器，在令牌到达策略引擎之前运行。好奇其他人如何在MCP服务器中处理代理身份。是将代理自身认证，映射到人类，还是联合到IdP？
查看原文

相似文章

@swyx: 解释一下

X AI KOLs Following

本文介绍了用于构建可插拔AI代理架构的模型上下文协议（MCP），详细介绍了在Sentry构建MCP服务器的经验教训，包括OAuth 2.1集成、设计对代理友好的工具接口以及当前生态系统的局限性。