给 Agent 接 MCP 之前，先想清楚权限边界
数据截至 2026-07，规范与各项目能力以官方文档当前版本为准。
MCP 真正棘手的地方不在于怎么接通，而在于接通之后，你的 Agent 事实上获得了多大的权力，而这件事默认是没人替你想的。协议负责让调用发生，不负责判断这次调用该不该发生——判断权限边界，从头到尾都是接入方自己的活。
常见的误解是把 MCP server 当成一个”只读的数据源”来对待：反正它就是给模型补点上下文，能出什么事。但 MCP 的工具调用天然是双向的，一个 server 既可以查数据库，也可以写数据库；既可以列出仓库文件，也可以提交并推送。一旦模型判断”该调用它”，调用就真的发生了，没有中间那道”你确定吗”的默认防线。所以边界这件事必须在写配置文件之前想清楚，而不是出事之后补。
一、把”权限”拆成三层，别混在一起谈
日常讨论里”权限”常常是一个含糊的整体，落到 MCP 场景需要拆开：
第一层是身份：这次调用是以谁的身份发出的。 是以你个人开发者账号的身份，还是以一个专用服务账号的身份，还是以最终用户的身份。很多问题的根源是这一层被偷懒了——直接把开发者本人的长期凭据塞进配置，于是 Agent 拥有了和你完全一样的权力。
第二层是范围：这个身份被允许触及哪些资源。 同样是”接了 GitHub”，是接一个仓库还是整个组织，差别是数量级的。范围应该在凭据签发的时候就收紧，而不是指望 server 端或模型侧自觉。
第三层是动作：在允许的范围内，允许做哪些操作。 读、写、删除、对外发送，这四类的风险完全不同。尤其是”对外发送”这一类（发邮件、发消息、调第三方 API），它意味着一次错误调用产生的后果不可撤回。
这三层要分别回答，任何一层含糊，整体边界就是含糊的。实践中最省事也最容易被跳过的做法，是每接一个 server 就单独签一份专用凭据，而不是复用手边现成的那把万能钥匙。关于凭据本身怎么存、怎么轮换，可以配合看API 密钥安全管理。
二、接入前先问清楚：这个 server 到底能碰什么
在把一个 server 写进配置之前，值得花十分钟做四件事：
- 看它声明了哪些工具。 大多数 server 会在文档或代码里列出工具清单。逐条读一遍工具名和描述，重点找带写入语义的动词——create、update、delete、send、execute 这类。
- 看它需要哪些凭据。 如果一个”只读查询”类的 server 要求你提供具备写权限的 token，这本身就是一个需要问清楚的信号。
- 看它在哪里运行。 本地 stdio 方式启动的 server 跑在你自己的机器上，能访问你的文件系统和本地网络；远程 server 则意味着数据要出网。这两种形态的风险模型不一样，不该套用同一套判断。
- 看它是谁维护的。 官方注册表 registry.modelcontextprotocol.io 由 modelcontextprotocol GitHub 组织维护，社区驱动，提供 server 发现、文档与 API 参考，是比随手搜到的第三方列表更靠谱的起点。路线图里还有一项 MCP Server Cards，思路是通过
.well-knownURL 暴露 server 元数据，让注册表和爬虫不必实际连接就能发现其能力——具体形态以官方文档当前版本为准。相关背景见MCP 官方注册表与MCP Server Cards。
按官方与行业公开资料的口径，目前有超过 10,000 个公开 MCP server 在生产中使用，SDK 月下载量超过 9,700 万。这是个汇总口径的量级估计，不是精确统计，但足以说明一件事：生态里的 server 数量已经远超任何人能逐个审计的程度，所以”默认信任”这个策略在这个规模下是不成立的。
三、新规范的授权加固，改的正是边界这块
2026-07-28 发布的新版 MCP 规范，官方称是自协议发布以来最大的一次修订，内容涵盖六块：无状态协议内核、Extensions 框架、Tasks、MCP Apps、授权加固，以及正式的弃用策略。其中和权限边界直接相关的是授权加固这一块。
这次授权部分由 6 个 SEP（Specification Enhancement Proposal）共同推进，方向是让授权规范更贴近真实的 OAuth 2.0 / OpenID Connect 部署。具体条款里点名的一条是：要求客户端按 RFC 9207 校验授权响应中的 iss 参数，对应 SEP-2468。
这条改动的意义在于，它把一件本来”看实现者自觉”的事变成了规范要求。授权响应里的 iss 标识的是签发方，客户端如果不校验它，就无法确认手里这份授权到底来自哪个授权服务器。把这类校验写进规范，等于承认了一件事：MCP 的授权不能停留在”照着 OAuth 库抄个流程跑通”的水平，得按真实部署的要求来做。更细的展开见MCP 授权加固。
对你的实际影响是：如果你自己写 client，升级到新规范意味着要补上这些校验；如果你只是使用现成 client，那么”这个 client 是否已经跟进新规范”就成了选型时一个需要确认的问题，而不是可以默认成立的前提。
四、协议层无状态化之后，状态该放哪
这次规范另一处大改动是协议内核变成无状态的，由 6 个 SEP 共同实现。实际影响是：以前需要粘性会话、共享 session 存储、网关做深度包检测才能跑的远程 server，现在可以直接跑在普通轮询负载均衡后面，按 Mcp-Method 头路由。协议层不再要求会话追踪。
这里有个容易走偏的理解需要澄清：无状态说的是协议层不再要求会话追踪，不是说 MCP 场景下不能有状态了。应用层该有的状态照样有，只是它的存放位置和生命周期由你自己决定，协议不再替你规定。展开可以看MCP 变成无状态。
从权限边界的角度看，这个变化有两面。好的一面是部署链路简化了，少了一层容易配错的粘性会话逻辑。需要留意的一面是，既然协议不再兜着会话，那么”这次请求对应哪个用户、他有什么权限”这件事，就更依赖每次请求自带的授权信息是否完整可信——校验的责任更集中地落到了授权那一层，也就是上一节说的部分。
同一轮修订里，用于长时间运行操作的 Tasks 特性已从核心协议移到 extension，用户也可以自建 extension 与官方认可的 extension 并存（见Tasks 移出核心）。这对边界设计的提示是：长任务的授权有效期问题，现在归 extension 管，你需要单独确认所选实现是怎么处理的。至于 MCP Apps 这一块，官方博客没有展开细节，具体能力和边界以官方规范文档当前版本为准，这里不做推测。
五、工具描述本身就是需要防的一面
有一类风险和协议改了什么无关，属于把 LLM 接入外部工具这个模式的固有特征：模型决定调用哪个工具，靠的是读工具的名字和描述。这意味着工具描述文本是会被模型当作指令来理解的内容。
由此引出两条实践建议：
- 不要让不可信来源的文本自动进入工具描述。 如果某个 server 的工具列表是动态生成的、内容部分来自外部输入，那么这条链路值得单独审一遍。
- 同名工具要注意。 接了多个 server 之后，工具名撞车不是罕见情况。撞车时模型选中哪个、你的 client 怎么消歧，最好在接入时就实测一遍，而不是等它选错了才发现。
再往前一步是数据流向：一个 server 读到的内容，会不会通过另一个 server 流出去。单看每个 server 都合规，组合起来可能出现你没设计过的通路。接之前把”哪些 server 能读敏感数据、哪些 server 能对外发送”这两张名单摆在一起看一遍，比事后追查省力得多。相关的通用风险梳理可以看AI 数据安全风险。
六、留一道人工闸门，别全交给模型判断
对不可撤回的动作，最有效的防线仍然是最朴素的那种：执行前让人确认一次。
值得设成人工确认的动作，大致是这几类——删除数据、对外发送消息、涉及资金的操作、修改线上配置、以及任何”做了就没法回退”的操作。读取类和可回退的写入类（比如创建一条草稿）可以放开，否则确认弹窗太密，人会开始条件反射地点同意，那道闸门就失效了。
这里的取舍是真实存在的：闸门太密影响效率，太松等于没有。比较务实的做法是按上一节说的动作分级来定，而不是按 server 粒度一刀切。更系统的做法见Agent 的人工介入设计。
另外建议把调用日志留下来——调了哪个工具、传了什么参数、返回了什么。出问题时，有日志和没日志是完全不同的两种排查体验。
七、接入前的自检清单
把前面几节压缩成可以照着走的条目，一共八条：
- 这个 server 用的是专用凭据，还是复用了我自己的账号凭据？
- 凭据的权限范围收到了最小必要吗？能不能只授权到单个仓库、单个库、单个项目？
- 工具清单里有哪些带写入或对外发送语义的工具？我确实需要它们吗？
- 它跑在本地还是远程？如果是远程，哪些数据会离开本机？
- 来源是官方注册表还是随手搜到的？维护方是谁？
- 我用的 client 跟进新规范的授权校验了吗？
- 哪些动作设了人工确认？分级合理吗？
- 调用日志有没有落盘、能不能查？
八条里如果有超过两条答不上来，通常说明这次接入还没准备好，值得再花点时间。此外，新旧版本的兼容问题也要一并考虑：2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然，弃用机制给旧版本留了 12 个月窗口。这个窗口既是缓冲，也意味着接下来一年里你的环境中会新旧混存，边界策略需要在两种版本下都成立。排期思路见MCP 新规范落地。
八、诚实说局限
有几件事这篇给不出确定答案。
一是各家 client 对权限控制的支持程度差异很大，有的提供细粒度的工具白名单和确认策略，有的只有全开或全关。这篇讲的是原则，具体能配到什么程度，取决于你用的那个 client 当前版本支持什么，得自己去文档里确认。
二是 MCP 从 2024-11 发布到现在约一年八个月，2025-12 由 Anthropic 捐给 Linux 基金会下的 Agentic AI Foundation 至今约七个月，仍是一个在快速变动的规范。OpenAI、Google、Microsoft、AWS 这四家主流厂商都已把它接进自家 agent 栈，各自的实现细节和默认策略并不一致。这篇提到的具体条款以官方 blog 与规范文档当前版本为准，网上还能搜到把更早版本当作”当前稳定版”的过期内容，看到时间对不上的说法，直接回官方源核对。
三是安全没有一劳永逸的配置。今天审过的 server 明天可能更新，权限边界需要跟着复查，尤其是在版本迁移窗口里。接入时容易踩的具体坑，另见MCP 常见误解。
小结
MCP 让”接上工具”变得很便宜，但没有让”该不该接、能接到多深”这个判断变便宜，那部分成本只是从协议层转移到了你身上。把权限拆成身份、范围、动作三层分别回答，比笼统地讨论”安全不安全”更容易落地。新规范里授权加固与协议层无状态化这两处改动，方向上都是把责任更明确地压到授权环节，跟进它们不只是为了兼容。对不可撤回的动作保留人工确认，日志留全，是成本最低、回报最稳的两件事。规范还在变，边界策略需要定期回头看，不能一次配置吃三年。