我不会推广 - 您在使用MCP时遇到了哪些跨服务器授权问题？
摘要
这篇文章探讨了当多个MCP服务器（例如Gmail、Github、Slack）在同一AI代理会话中一起使用时，所面临的跨服务器授权挑战，并提出是否需要除了每个服务器的OAuth之外的专用授权层。
研究一个真实问题而非假设性问题。并非推销任何东西。如果你的代理在一个会话中串联了多个MCP服务器，比如Gmail + Github + Slack。有哪些危险的组合？你如何约束你的代理？例如，一个可以访问Slack和Github MCP的代理。你如何确保代理不会将私有git仓库代码泄露到公共Slack频道？特别好奇：
* 单独安全但组合危险的工具组合
* 你现在如何划定权限（按用户、按会话、按工具、或不划定）
欢迎评论或私信。试图弄清楚MCP是否需要客户端和服务器之间的专用授权层，还是每个服务器的OAuth加上客户端侧的批准就足够了。
相似文章
GetMCP：AI 代理的零信任
GetMCP 是一个可自托管的开源工具，通过提供每请求审计、每代理撤销、策略执行和 API 调用的人工介入审批，为 AI 代理带来零信任安全。它根据 OpenAPI 规范生成 MCP 服务器，并作为具有防篡改审计日志的流式代理运行。
您如何处理MCP代理之间的跨客户端通信？
一位开发者讨论了协调多个使用MCP通信的AI代理（如Claude Code和Cursor）在同一项目上工作的挑战，分享了自己基于IRC的共享“房间”模型构建的开源解决方案，并询问社区的模式和意见。
MCP 欢迎页面
作者描述了一个 MCP 服务器的常见用户引导问题——用户在浏览器中访问端点时看到 401 错误——并分享了一个简单的技巧：返回一个 HTML 页面，解释如何正确地将服务器添加到 LLM 客户端，从而大幅减少了支持工单。
我询问了20位Agentic AI创始人如何处理智能体访问权限。17位表示依靠临时权宜之计。
作者调查了20位Agentic AI创始人，发现由于缺乏可验证的授权层，其中17位依靠临时权宜之计来处理智能体访问控制。这突显了处理敏感数据的AI智能体在安全性和审计方面存在显著差距。
使用 MCP 进行代码执行：构建更高效的智能体
本文来自 Anthropic，探讨了如何将代码执行与 Model Context Protocol (MCP) 相结合，以提升 AI 智能体的效率。文章分析了工具定义和中间结果导致的 token 过载等挑战，并提出代码执行作为降低延迟和成本的解决方案。