AI Agent M365 集成被内部安全墙反复拦截。
M365 MCP → 连接失败
Chrome 中的 Claude → 无法使用
Notion MCP → 失效
作为大公司的一名"窗口位"管理者，我今天（2026 年 6 月 2 日）看到微软 Scout 的公告后，认真思考了这个问题。
Scout 从一开始就在围墙之内。
但今天最大的冲击是，个人信息政策墙比安全政策墙高得多。
注：本文是基于我个人工作环境的思考，不保证在其他公司或环境中也能成立（信息截至 2026 年 6 月 3 日）。
第一章：了解 Scout 与 OpenClaw
Scout 是一个基于 OpenClaw（开源 AI Agent）的企业级、始终在线的 M365 Agent。
OpenClaw 是奥地利开发者 Peter Steinberger 于 2026 年 1 月发布的一款个人 AI Agent。
OpenClaw 发布后迅速火爆。即使在开发者加入 OpenAI 后，该项目仍在社区主导的独立基金会下继续开发，到 2026 年 4 月已在 GitHub 上获得超过 30 万颗星。
我关注 OpenClaw 已经有一段时间了，并在家里测试一个名为 NemoClaw 的克隆环境。我原本预期它还需要六个月才能达到企业成熟度，计划在本财年下半年在工作环境中进行全面验证。目前只是在个人环境中做热身测试。
但从企业采用的角度来看，OpenClaw 面临三大挑战：
① 安全问题无法忽视。
虽然 OpenClaw 自由度很高，但在企业环境中使用令人担忧。安全问题一直备受质疑，这也是企业采用时犹豫的原因。
② 从实施到维护的门槛高。
安装、配置和运营的技术门槛较高，没有工程师资源的企业难以持续运行。在 X 上经常可以看到这样的评论："即使能安装，维护也太难了，根本没法用于实际工作。"
③ 与 M365 集成薄弱。
截至 2026 年 3 月，OpenClaw 的本地 M365 集成是社区最需要的功能，但尚未实现。相比之下，与 Google Workspace 的集成已经很成熟，而 Outlook、OneDrive 和 Teams 日历仍然只停留在基本的"日程安排功能"状态。
Scout 在很大程度上解决了 OpenClaw 面临的①安全和③M365 集成问题。其解决方案在于内置的企业安全控制、通过 Intune、Purview 和 Entra 实现的治理集成，以及与 Teams、Outlook、OneDrive 和 SharePoint 的原生连接。至于②实施和维护门槛，预计会有所改善，但从 X 上的观察来看，通过 Frontier 进行配置仍然复杂，因此尚未完全解决。
Scout 持续监控 Teams 消息和 Outlook 邮件，主动处理会议安排、截止日期检测和日历冲突。微软将其定位为"始终在线的个人 Agent"。它不等待提示，而是主动行动。
但目前它仅限于 Frontier 计划，需要 GitHub Copilot 许可证和 Intune 配置。大公司的普通用户还需要一段时间才能用上。
第二章：为什么 MCP 在大公司中会失效——结构性原因
因为它试图从外部连接，所以被干掉。这是 MCP 失效的唯一原因。
这就是我在引入 Claude Enterprise 时面临的墙。M365 MCP、Chrome 中的 Claude、Notion MCP——几乎所有我期待的外部集成功能都失效了。
无论我怎么检查设置，都无法连接。最后我才意识到原因是内部安全策略。
在企业网络环境中，对外部服务的 HTTPS 和 WebSocket 连接会受到安全工具的检查和限制。
MCP 所依赖的协议通信很常见地被阻断。
"试图从外部连接到 M365 外部的 MCP 服务器"这种设计，从根本上与企业安全策略冲突。
因为你试图从栅栏外面戳洞，所以守卫会拦住你。
MCP 失效的原因不是安全太强，而是设计本身的问题："从内部终端直接连接到外部 MCP 服务器"。
理解了这一点，下一章就容易理解了。
第三章：为什么 Scout 有可能突破 MCP 失效的困境
Scout 在 M365 内部运行。因此，它比外部 MCP 更有可能在内部网络存活下来。
连接到 Teams、Outlook、OneDrive 和 SharePoint 的结构与直接连接到外部 MCP 服务器不同。如果 Scout 作为官方 M365 功能提供，我相信它极有可能在内部网络存活下来。
因为它试图从外部连接，所以被干掉。
而 Scout 从一开始就在围墙之内。
这是这次公告最重要的一点。
一线人员一直在做的事情是"试图跨越内部安全墙连接到外部 MCP 服务器"。这在结构上很困难。既然 Scout 作为官方 M365 功能运行，"需要戳洞"这件事本身就可能消失。
此外，Copilot Studio 的远程服务器集成已经在推进，从 M365 端连接到工具的路径正在建立。一度因内部安全策略而失效的 MCP 有可能通过 M365 端的管理路径复活。但这只是"可能性"。我还不能确定它一定能存活。
第四章：但不能一味乐观。三个现实问题
这是今天最大的发现。在安全政策墙之外，还有一堵高得多的墙。
① 大公司的普通用户暂时还用不上
目前，Scout 仅限于 Frontier 计划的实验性发布。它需要 GitHub Copilot 许可证和 Intune 设置，因此无法立即在全公司部署。
此外，Scout 目前仅在美国提供测试（日本经济新闻 2026 年 6 月 2 日报道："在美国提供测试"）。Frontier 计划遵循"初始发布从英语/美国开始"的模式，因此部署到日语环境还需要更长时间。
在我们公司，即使是微软的 Copilot Cowork 在发布后两个多月也还没有部署。我们必须考虑到 Scout 到达普通用户需要相当长的时间。
② GitHub Copilot 许可证要求——以及 6 月 1 日起的按需付费问题
Scout 需要 GitHub Copilot 许可证。然而，从本月开始，GitHub Copilot 的定价结构发生了重大变化。
2026 年 6 月 1 日，GitHub 将所有 Copilot 计划转为按需付费模式（GitHub AI Credits，1 credit = $0.01）。每个计划包含与月费相等的信用额度，正常的代码补全仍然不受限制。但聊天和 Agent 操作会根据 Token 使用量消耗这个信用额度，超出部分会产生额外费用。
Scout 是一个"始终在线"的 Agent。它持续在后台运行，同时监控邮件、日历和 Teams。这种持续运行是否能在月度信用额度内完成，还是会大幅超额，只有试过才知道。
即使在正常使用 Copilot 时，也有报告称，在大量使用 Agent 模式的情况下，成本可能膨胀到包含信用额度的 10 到 50 倍。如果始终在线的 Scout 在数百人之间持续后台运行，极有可能大幅超出基本信用额度。
GitHub Copilot 许可证的要求不仅仅是"拿到许可证"的问题，而是另一堵墙：能否在预算提案中解释"是否在信用额度内，以及超出后成本是多少"。
在全面实施之前，必须通过小规模 PoC（概念验证）掌握实际的 AI Credits 消耗情况。
③ 真正的墙是"个人信息政策"
Intune 环境和 GitHub Copilot 路径。技术前提很可能已经具备。
那么，为什么即使是微软的 Copilot Cowork 在发布两个多月后仍然没有到来？
Scout 会自然地读取员工的邮件、日历和聊天记录来自动化任务。
这里需要确认的是，员工姓名和邮件地址也属于个人信息。任何可以识别个人的信息都是个人信息。Scout 读取的邮件、日历和聊天中包含大量此类个人信息。
技术上说，这是 Copilot 通过 Microsoft Graph 处理用户邮件、日程、聊天和文件的问题。但在内部规定下，我们无法回避"是否允许 AI 处理个人和机密信息"这一任务。
这不是技术问题，而是政策问题。这不是 IT 部门调整一下设置就能解决的。这是"公司是否认可 AI 读取员工邮件"的决策。只有达成共识，Scout 才会开始运行。
我在引入 Claude Enterprise 时也撞上了这堵墙。公司原本就没有能处理个人信息的 LLM 服务，所以我们以"可以输入机密信息，但不得输入个人信息"的约定引入。大多数大公司可能都有类似的墙。
技术上的墙可以通过改变设置来跨越。但政策上的墙需要人、时间和共识。
有一个案例可以说明这种困难。
2026 年 4 月，信息安全研究人员报告称，在日本法院的 Microsoft 365 环境中，至少 14 名工作人员的个人标识符处于可被外部获取的状态。
据报告，原因是 Teams 和 Outlook 中的"安全链接"功能在重写 URL 时会以明文嵌入人员信息，同时外部联系人搜索功能默认启用。如果报告属实，M365 的"贴心设计"反而导致了个人信息泄露。
据我观察，AI 圈似乎没有关注到这一事件。我认为在讨论 Scout 时不能忽略这个事实。
Scout 确实在围墙之内。但即使在围墙之内，信息也可能通过 M365 自身的其他路径泄露出去。
内部安全策略或许可以通过技术设置更改来克服。
但个人信息政策墙在 IT 部门、法务、合规和信息安全达成一致之前是无法移动的。
第五章：今天就可以开始的三项行动
① 在内部 Copilot 社区中发声
如果没有直接找到 IT 部门的途径，Copilot 社区是唯一可以发声的地方。传播一条信息："要使用 Scout，我们需要整理个人信息政策。" 作为 AI 推广负责人，提高声音是第一项行动。
② 确认公司内"Copilot 个人信息政策"的现状
Scout 能够工作的前提是，内部同意 Copilot 在 M365 中处理个人数据。确认当前公司内该政策是什么，如果没有整理好，找出需要接触的人。我打算立即检查这一点。
③ 保持对美国早期发布信息的关注
Scout 目前在美国开始测试提供。实际用户的使用经验、个人信息政策的整理方法、GitHub Copilot 按需付费额度的实际消耗等信息应该会在 X 和英语圈中出现。随着信息发布，整理这些内容如何适用于自己的环境。这是目前最现实可行的行动。
如果你也遇到了大公司中 MCP 失效的困境，请告诉我。
你所在的公司是如何创造机会跨越个人信息政策墙的？
感谢你阅读到这里。
作为大公司的一名"窗口位"管理者，我每天都在实际环境中投放 Claude Cowork，持续进行实验。
对于同样身为管理者、正在为"想用 Claude 但内部用不了"或"MCP 失效"而苦恼的人，我会在 X 上时不时分享实际工作示例和提示词。
