在SAP BTP上构建AI Agent的开发者，大概率撞过这堵墙：Agent调用后端REST API时，每个请求都落在ABAP系统里同一个共享服务账号下。审计日志记录的是服务账号，而不是请求背后的人。当所有调用都带着同一身份抵达时，ABAP根本无法执行按用户的授权控制。

问题根源在于身份链断裂。浏览器里的用户登录后，其身份信息在云端的某个环节被替换成了技术账号。ABAP系统看到的是一张"通用通行证"，而非具体某个人的"实名证件"。这在需要精细权限管控和合规审计的企业场景中，是个不小的隐患。

解决方案是主体传播（Principal Propagation）——一条信任链，将终端用户的身份从浏览器会话一路传递，穿过BTP Cloud Foundry、Cloud Connector，最终抵达ABAP ICM层。在那里，一个短期的X.509证书确认了真正发起调用的人是谁。

为什么不能直接用服务账号？

直接使用ABAP技术用户确实更简单，但代价不小。ABAP的授权对象围绕单个用户设计，共享账号意味着所有调用都运行在相同权限下，无法为不同人员设置不同权限。审计日志（SM20、SAL）记录的是技术用户而非实际请求人，这让事件调查和合规报告变得困难。更关键的是，一旦Agent行为异常或遭到入侵，受影响范围就是该服务账号的全部权限。

主体传播的价值在于：在ABAP层实现按用户授权和完整审计，同时云应用无需管理任何ABAP凭据。身份信息在每一跳都被保留，只有用户JWT跨越云与本地边界，两个client_credentials令牌完全在BTP内部消耗。

MCP服务器在链条中的位置

本文聚焦的是MCP服务器及其主体传播链路——从MCP服务器到ABAP的完整路径。MCP（Model Context Protocol）服务器是一个轻量级HTTP服务，向LLM Agent暴露类型化工具。浏览器通过approuter登录获取用户JWT的部分，假定已经就绪。

链路起点是MCP服务器，它从VCAP_SERVICES读取Connectivity服务绑定，发送带有用户JWT的请求头。BTP Connectivity Proxy通过已建立的WebSocket通道转发，Cloud Connector验证JWT签名后，提取user_uuid并生成短期X.509证书，再通过mTLS连接转发给ABAP ICM。ABAP层验证证书后，在EXTID_DN中查找对应用户，业务逻辑最终以真实终端用户身份执行。

这条链路的精妙之处在于：每一跳都保留终端用户身份，但只有用户JWT跨越云与本地边界。两个client_credentials令牌完全在BTP内部消耗，不会泄露到本地环境。对于正在SAP BTP上构建Agent、又受困于共享账号权限困境的团队，这条路径值得仔细研究。