一、问题从哪来：静态 Service Account 的两个硬伤

现在绝大多数实际部署的 MCP（Model Context Protocol）服务，依赖的是静态 Service Account。原文指出这会带来两个主要缺陷：

• 智能体权限过大——令牌是常驻的、权限是固定的，Agent 拿到什么就等于拥有什么。
• 日志里没有任何人的痕迹——每一个动作在审计日志里都只显示为 svc-ai-agent，出了事无法归因到具体的人。

这意味着：一次 Agent 误操作，你连"是谁触发的"都查不出来。这就是为什么作者搭了一套实验环境（Azure APIM、MCP Server、Okta、CrowdStrike）来实测两件事——先用委托令牌替换 Service Account，再验证即便如此能不能堵住外泄漏洞。

二、第一道防线：用委托令牌替代静态账号

做法是用 Cross-App Access（XAA） 实现一个三步令牌交换，目标是把最小权限贯彻到 MCP 服务这一层，同时把人的身份保留在 SIEM 里。

三步的逻辑是：

改完之后，日志里不再只有 svc-ai-agent，而是能顺着身份串起来。原文提到这一段实验从 12:05 开始，配 15:27 讲授权服务器的 scope 与组策略配置。

三、第二道防线：合法工具也能偷数据

这是整篇最值得普通人记住的一点：就算令牌委托做对了，Agent 依然可以滥用一个完全合法的工具——比如 http_request，把用户有权读取的机密做 base64 编码后外传。

绕过 IAM 的路径：不是权限不够，而是"权限刚好够读，但读完之后没被拦住往外发"。

所以作者专门在 18:58 演示了这条路径。而要抓住它，靠的不是 IAM，而是把三类日志关联起来看：

• API 网关的提示词检查（示例环境为 Azure APIM）——看 Agent 到底在提示词里塞了什么指令。
• SIEM 里的身份日志——确认是哪个身份在发起动作。
• SIEM 里的网络日志——确认这次动作最终有没有出网。

三者交叉才能定性。加上严格的工具沙箱与白名单，把 Agent 能调的工具、每个工具能访问的域名和路径都限定死。

四、还没解决的部分

原文没有回避局限，明确列了两项：工具沙箱和完全自治的 Agent。前者意味着很多部署里沙箱能力还不完整，后者意味着当 Agent 自主决策链变长、步骤变多时，「一次请求内拼装出的外泄动作」会越来越难用固定规则拦住。

另外一个背景事实值得记住：原文提到近期已出现过 Asana MCP、Cline、Salesforce 相关事件——这不是理论风险。

五、一份能自己动手查的清单

如果你在给团队或个人环境接 MCP / Agent 工具，这几件事可以立刻做：

• 查令牌类型：服务还在用常驻静态 Service Account 吗？先确认这一点，其他防线都建立在它上面。
• 查日志归因：审计日志里能不能看到一个具体的人？还是清一色 svc-ai-agent？
• 查工具清单：Agent 能调哪些工具？带 http_request 这类能出网的通用工具吗？有白名单吗？
• 查出网权限：MCP 服务所在环境能否任意访问外部地址？能不能限制目标域名。
• 查是否有关联监控：网关提示词检查、SIEM 身份日志、SIEM 网络日志三处是否真的串在一起用，而不是各看各的。

行动建议：先做第 1 和第 3 条——它们成本最低，但能挡掉大部分「出了事查不到人」和「Agent 随手往外发」的问题。剩下的日志关联属于工程投入，可以按需要排期。