MCP 把工具交给模型去调用，但「谁能调、能调什么、调完留痕吗」必须守住，否则一个被诱导的提示词就能让模型删库、发邮件、改配置。本文讲清 MCP 的权限与认证模型：OAuth 委托、 scope 最小权限、服务端鉴权与审计，帮你把「模型能做事」和「模型乱做事」隔开。这是 MCP 何时该用 之后最该补的工程课。
先把「认证」和「授权」拆开
认证回答「你是谁」，授权回答「你能做什么」。 MCP 里客户端要先拿到凭证证明身份，再由服务端按策略决定这次调用是否被允许。很多事故出自把两者混为一谈——以为「登录过」就等于「什么都能干」。和 智能体权限范围 的思路一致：默认无权限，需要什么显式给什么，而不是默认全开。
认证：OAuth 2.1 委托是主流形态
远程 MCP 服务端通常用 OAuth 2.1：用户在一次授权流程里把访问权委托给客户端，客户端拿到短期令牌，过期再刷新。关键在于「用户知情且可撤销」——授权画面要清楚列出客户端要哪些权限，用户随时能收回。本地 stdio 服务端多靠本机凭证或环境变量，但仍要区分「谁在跑这个进程」。选型时参考 MCP 客户端对比选择，看客户端是否正确处理令牌存储与刷新，别把令牌写死在配置里。
授权：用 scope 做最小权限
授权才是安全的核心。服务端应暴露细粒度 scope（如 files:read 、 files:write 、 mail:send），客户端按本次任务申请最小集合，用户批准后才生效。原则：只读不写、临时不长期、单资源不全局。一个只做代码搜索的 Agent，绝不该拿到 files:write 。这和 MCP 生产部署 的稳健性要求同源——把爆炸半径压到最小，单点失误不至于全局崩。
服务端鉴权与审计：每次调用都要可追
服务端在每次工具调用前都要重新校验令牌与 scope，不能「登录一次管终身」。更关键的是审计：谁、在几点、调了哪个工具、传了什么参数、返回了什么，全部留痕。出事时能还原现场，比事前拦截更现实。审计日志要和 MCP 安全提示注入 的防御叠加——提示注入防的是「被骗去调」，审计兜底的是「调了也能查」。
人类确认：高危动作的最后一道闸
发邮件、删文件、执行 shell 、改生产配置——这类动作不该由模型自主决定。成熟的做法是「分级确认」：低风险只读自动过，中风险给摘要让人点一下，高风险必须显式输入确认。配合 MCP 传输层 的连接可靠性，确认机制才不会成为被绕过的安全纸。把「确认」做成服务端强制策略，而非客户端可选功能。
- 拆认证与授权：先确认身份（你是谁），再按策略决定权限（能做什么），默认无权限、显式授予。
- 用 OAuth 2.1 委托：远程服务端走标准授权流，令牌短期+可刷新+可撤销，绝不写死在配置。
- 细化 scope：按 files:read/write 、 mail:send 等粒度申请最小权限，只读不写、临时不长期、单资源不全局。
- 每次调用重校验+审计：服务端对每次工具调用重验令牌与 scope，并留痕谁/何时/调了什么/传了什么参数。
- 分级人类确认：低风险自动过，中风险给摘要确认，高风险（发邮件/删文件/改生产）强制显式输入确认。
常见问题
MCP 的认证和授权有什么区别？
scope 该怎么设计才安全？
本地 stdio 服务端也要鉴权吗？
哪些动作必须人工确认？
评论 (0)