大多数部署上线的 MCP（模型上下文协议）服务器，今天还在用静态服务账号跑。这套做法留下两个硬伤：智能体权限过大，日志里没有任何人的责任痕迹——每一次操作都只显示为 svc-ai-agent。

打开网易新闻 查看精彩图片

在 Asana MCP、Cline、Salesforce 几起事件之后，有人搭了一个实验环境（Azure APIM、MCP 服务器、Okta、CrowdStrike），专门验证两件事。

第一件：用委派令牌替掉服务账号

为了让最小权限一直落到 MCP 服务器这一层，同时把人的归属信息留在 SIEM 里，实验采用了跨应用访问（XAA）的三步令牌交换。配套动作还包括认证服务器的 scope 与组策略配置。

思路是把"机器身份"换成"人的委派身份"，这样日志里能追到具体是谁授权了这次调用，而不是又一个服务账号。

第二件：IAM 为什么不够用

即便令牌委派做得再严，智能体仍然可以滥用一个合法工具——比如 http_request——把用户本来就有权读取的机密做 base64 编码后外带出去。这条路径不违反权限，只违反意图。

要抓住这种泄露，得把 API 网关的提示词检查（Azure APIM）和 SIEM 里的身份日志、网络日志做关联分析，再叠加严格的工具沙箱与白名单。

实验环境里还演示了如何绕过 IAM、通过 http_request 工具完成数据外带，以及随后如何在网关侧发现这次泄露。演示视频的音频是法语，YouTube 的英文自动字幕可用，控制台和终端操作本身是可视的。

最后一段留给局限：工具沙箱和完全自主的智能体，目前都还没有干净的解法。