安全笔记｜微行研究组

把业务服务接到AI代理，常被画成一条简单的连接线，但线的两端并不天然共享信任。MCP的官方安全最佳实践把未经正确验证的令牌透传列为禁止的反模式：服务器不能接收并非明确签发给它的令牌，再直接转发到下游服务。文档指出，这会削弱控制、审计与信任边界。

令牌不只是“可以登录”的字符串，还承载着谁在访问、面向哪个服务以及允许哪些动作的约束。连接器如果忽略这些条件，表面上减少了配置步骤，实际上可能让一处凭证被带到原本不该信任它的地方。

把每一步授权说清楚

团队评估连接器时，可以画出用户、客户端、连接器和业务接口之间的授权关系。每一段都回答三个问题：凭证由谁签发，接收方如何验证，权限覆盖哪些资源。没有这些说明的“直接接入”，不应只凭一次成功调用就认为设计完成。

只读查询与写入操作也可以分别规划权限。查询一份已授权资料，不应默认获得修改全部资料的能力。即便产品界面为了方便把功能放在一起，底层仍需要能说明权限范围，并在权限不足时明确失败，而不是尝试绕到另一个身份执行。

日志需要能还原责任链

对安全排查而言，“某个工具被调用了”还不够。团队需要知道是哪个已授权客户端发起、使用了什么权限，以及下游实际处理了什么动作。日志可以记录这些关联信息，却不应为了方便把完整访问令牌写进去。能追踪请求与能泄露凭证，是两回事。

此外，撤销也需要测试。用户断开连接、成员离职或凭证轮换之后，相关访问是否真的停止？如果仍有旧凭证或缓存身份可以继续使用，界面中的“已断开”就可能给人错误印象。验证撤销效果，应成为连接器上线检查的一部分。

我们的判断是，可靠连接器不是把所有认证细节藏起来，而是把复杂性管理在明确边界内。代理能够调用更多工具之前，团队应先知道这些工具代表谁、能触及什么，以及出现异常时如何停下。连接速度不能替代授权设计。

归档说明：本篇于二〇二六年十月十二日补写并上线，按十月十日栏目归档；文中资料在该归档日期前已公开。