READ · UNDERSTAND · TRANSFER
阅读理解，按需巩固
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · MCP 集成中的协议与信任边界
先理解核心原理
先备概念：OAuth 资源服务器、工具网关、最小权限
协议互通证明消息能被理解，不证明服务器可信或动作获准。工具元数据、输入身份和返回文本都需要各自的信任来源；令牌必须给正确的资源使用，不能靠代理转发把权限扩散到下游。
从接通到可执行之间还有哪些判断
发现一个工具只能说明服务器宣称具备能力。主机还要确认服务器身份、当前用户范围、实际工具契约和风险；执行端检查具体资源。把全部工具展示给模型，再期待它自动遵守权限，相当于把管理员按钮隐藏后便取消后端鉴权。
注解为什么是提示
readOnlyHint 描述工具行为，却不是证明。可信、受审查服务器的注解可参与策略，不可信服务器自称只读不能免去验证；真实读操作也可能泄露敏感数据。工具结果中的“已批准”同样只是数据，不能改变服务端批准记录。
HTTP 令牌绑定的因果
若服务 A 接受原本发给 B 的 token，合法凭据就变成跨服务通行证。固定 MCP 2025-11-25 修订讨论 HTTP 授权时，客户端带资源标识，资源服务器核验令牌面向自身；访问下游 API 用单独面向下游的 token。协议修订和实际部署要一致，stdio 的凭据方式也不能套用成 HTTP 授权流程。
回到问题：怎样回答？
MCP 统一工具发现和调用方式，但不替我们完成业务鉴权、幂等、限流和审计。主机要控制可用服务器与工具，服务端校验参数和资源权限。工具标注的只读、幂等属于提示，来自不可信服务器时不能直接作为放行动作的依据。对于 HTTP 授权，令牌要绑定目标资源并由服务器验证；访问下游系统使用面向下游的独立令牌，不能把入站令牌原样转发。
实现与取舍
协议与应用责任分别是什么
MCP 让主机通过客户端发现服务器能力并调用工具，协议定义了输入、结果与错误等结构。业务集成还需要服务器白名单、工具版本管理、调用超时、并发配额、日志脱敏和资源授权。服务器可用不等于其所有工具都适合当前用户。工具集合应按任务和身份收窄，真正执行时仍在服务端验证，不把“模型没有看见这个工具”当作安全边界。
注解和工具结果为什么不能全信
工具可标注只读、破坏性或幂等行为，但 MCP 规范要求不可信来源的注解按不可信信息处理。主机应根据自己维护的策略、服务器身份与审查结论决定审批，不允许陌生服务器声明 readOnlyHint 就获得生产权限。工具描述与结果文本也可能包含恶意指令。它们是供模型使用的数据，不是系统授权的来源。结构化结果需校验并限制大小，资源链接需检查访问范围，密钥不得进入模型上下文。
HTTP 授权要避免代理混淆
以 MCP 2025-11-25 授权规范为具体讨论范围，客户端在授权和令牌请求中使用 resource 参数，服务器验证令牌确实签发给自身。仅验签而不验证受众可能误收其他服务的令牌。MCP 服务访问下游 API 时使用单独面向下游的凭据，不能原样透传入站 token；否则下游可能误把上游身份与权限当成自己的授权。服务端还需要把 OAuth 范围映射到业务动作和具体资源，不把“成功登录”扩大成任意文档可读。
生产验证如何覆盖越界
建立矩阵：错误受众令牌、过期令牌、合法令牌访问无权资源、伪造只读注解、超大结果和工具调用超时。预期分别是拒绝认证、拒绝资源访问或受控失败，并有脱敏审计。对写工具额外演练重复请求和不确定执行结果。协议版本必须在集成中固定并测试；本题引用特定修订说明机制，不意味着该修订适用于所有部署。接入成功是起点，边界经过反例验证才算可交付。
工程推演
- 场景
- 假设工程场景：企业将文档查询和工单修改作为两个 MCP 工具提供给研发 Agent。
- 设计决策
- 按任务只暴露必需工具；查询与修改使用不同动作权限；服务端检验受众、租户和工单归属。
- 验证目标
- 预期行为：只读任务不能修改工单；另一个服务签发的 token 被拒绝；下游凭据不进入模型。
- 适用边界
- MCP 规范不替代企业权限模型；stdio 本地部署与 HTTP 授权的安全配置也不能混为一谈。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层只读工具注解能否作为免审批依据？
协议元数据需要信任前提，不能代替具体动作判断。
参考解答
可以作为来自可信、受审查服务器的一个策略输入，不能单独决定免审批。主机根据实际副作用、数据敏感度和用户已有授权判断；不可信来源的注解按不可信数据处理。查询工资虽只读仍有泄露风险，标为只读的工具若实际发信则需拒绝或重新审查。
沿着这个回答继续深入
第 2 层服务器原来可信，升级后工具仍标只读但新增导出功能，怎么办？
信任会随版本变化，静态白名单不能证明新行为仍安全。
参考解答
工具描述、Schema 与实现版本纳入发布审查，变化触发契约回归和策略重算。执行网关限制允许的操作与目的地，监测异常副作用；升级不能自动继承旧批准。目录展示是提示，放行依据保存在受控策略。
沿着这个回答继续深入
第 3 层Schema 没变，服务器实现偷偷改了，客户端能完全防住吗？
契约检查有观测边界，需要用权限限制降低无法观察的风险。
参考解答
不能仅靠协议验证内部行为。减少服务器权限，使用受限凭据和隔离环境，要求可信发布渠道与审计；客户端可检查可见结果和请求范围，但无法证明远端没有隐藏副作用。无法信任的服务器不授予高影响能力，说明这一实际限制。
第 1 层有效 OAuth token 为什么仍可能被拒绝？
凭据真实性与凭据适用范围是不同判断。
参考解答
有效可能只意味着格式和签名正确。还要检查是否过期、目标受众是否本服务、scope 是否允许该动作，以及用户是否有具体资源权限。令牌通过认证却无订单读取权时仍拒绝资源访问；错误受众是认证边界失败，不能为方便集成忽略。
第 1 层MCP 服务访问下游 API 时如何处理凭据？
跨服务代理必须避免将上游权限误当成下游授权。
参考解答
MCP 服务作为下游 API 客户端，使用专门签发给下游的受限凭据，并按当前主体与目的映射权限。入站 token 不原样透传，不放入模型上下文；必要委托通过受控授权机制实现。保存脱敏的调用身份和资源范围，不能把 OAuth scope 自动扩成下游管理员权。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
本地 stdio 服务
改变的条件：HTTP 网络授权变为宿主启动进程
延伸问题：没有 OAuth 就没有安全边界吗？
推导与参考解答
仍需限制可执行程序来源、环境凭据、文件范围和工具动作。stdio 可从环境获得凭据，但不应继承不必要的管理员密钥；宿主启动受控进程并区分日志与协议通道。HTTP 令牌规范不直接套用，最小权限和输入授权仍适用。
保持不变的原理：传输方式改变身份接入，业务权限与凭据范围仍需控制。
公众只读数据服务
改变的条件：私有写工具变为公开查询
延伸问题：是不是可以跳过所有生产检查？
推导与参考解答
可以不要求私人资源授权，但仍检查参数、资源消耗、结果大小、服务器身份和不可信内容。公开数据可能被污染，工具文本仍不能给 Agent 新指令；限流和超时保护宿主。放宽的是公开数据访问规则，不是全部执行边界。
保持不变的原理：互通和可读性不等于任意输入、无限资源或可信指令。
易错点
- 认为 MCP 连接成功意味着完成业务授权
- 只验 token 签名，不检查其目标受众
- 把工具返回内容当作新的系统指令或审批证明
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 知道 MCP 解决协议互通，不直接提供全部业务控制。
- 中高级信号
- 区分 Host、Client、Server 的责任及身份、授权与回执。
- 资深信号
- 覆盖外部工具声明不可信、协议版本和供应链变化验证。
巩固练习 按需完成 · 建议 15 分钟
画出模型通过 MCP 查询和修改工单的信任边界。
展开验收要求与检查点
- 协议与业务权限分开
- 写工具有策略控制
- 服务端错误可追踪
重点检查
- 解释主机、客户端、服务器的责任
- 能识别工具注解与强制策略的差异
- 说明 audience 验证和禁止 token passthrough 的原因