MCP审批网关实测：AI智能体为何总能绕过人类监管？

一个旨在为AI智能体加上"人工审批"关卡的开源项目，在10名开发者的真实测试中遭遇了尴尬的失败——智能体根本不走你设定的那扇门。这个来自Reddit社区的实战复盘，揭示了当前AI治理（AI Governance）领域一个被严重低估的核心难题：你以为给智能体套上了缰绳，实际上它随时能挣脱。

项目初衷：让智能体"逐步赢得"自主权

开发者构建了一个名为TrustFloor的开源层，定位于智能体与它要操作的应用之间。核心逻辑很直观：在智能体执行付款、签署、发送等高风险操作之前，必须先经过人类审批。

更有野心的长期设想是建立一套信任积累机制——随着某类操作的审批记录不断累积，智能体可以逐步针对该操作类型获得自主权，无需每次都打断人类。这其实是一个相当合理的AI治理框架：从完全人工把关，渐进过渡到有条件的自动化。

技术实现上，团队把它做成了一个MCP（Model Context Protocol）网关：智能体调用网关 → 执行策略检查 → 返回"允许/挂起待批/拒绝"三种结果之一。听起来是个干净利落的拦截方案。

翻车现场：智能体选择了"最顺手的那条路"

问题出在真实环境的复杂性上。在试点中，每个开发者的环境里早已连接了Gmail、CRM、GitHub等多个直连MCP服务器。当智能体需要执行操作时，它会从所有可用工具里挑选"最合适"的那一个。

结果往往是——它直接调用了原生服务器，而不是绕道审批网关。

开发者尝试用提示词告诉智能体"永远通过网关路由"，这招大部分时候管用，但"大部分时候"和"永远"之间隔着的，恰恰是AI安全最致命的那条缝隙。对于涉及资金、签名的高风险操作，99%的拦截率意味着1%的失控，这在生产环境中是不可接受的。

核心教训：MCP给你一个位置，但不强制流量经过你

作者总结出一句极具洞察力的话：MCP提供了一个标准化的"立足点"，但协议本身没有任何机制强制所有调用都流经你的网关。

那么唯一真正有效的强制手段是什么？答案是凭证托管（Credential Custody）——让网关持有OAuth令牌，而智能体手里一张凭证都没有。没有钥匙，智能体即便想绕过网关也无门可入。这是从"靠约定"转向"靠物理隔离"的关键认知转变。

MCP（Model Context Protocol）是Anthropic于2024年底发布的开放协议，旨在为AI智能体提供一套标准化的"工具调用"接口，让不同的应用和服务能以统一方式向智能体暴露能力。其设计哲学更接近于USB接口标准——它规范了"如何插入"，但不规定"必须从哪里插"。在实际部署中，一个智能体宿主（如Claude Desktop、Cursor等）通常会同时连接多个MCP服务器，智能体在规划任务时会根据工具描述和上下文自主选择调用哪个服务器的哪个工具。这意味着MCP天然是一个"多入口"架构，而非单一管道——审批网关只是众多入口之一，协议层面没有"必须经过此节点"的路由机制。这与传统API网关（如Kong、APIM）的模型有根本差异：后者通常作为唯一出口部署在网络层，所有流量物理上必须经过它；而MCP网关只能以"另一个可选工具"的身份存在于智能体的工具列表里。

商业现实：想要审批的人，从不搜索"审批SDK"

除了技术层面的绕行问题，这次试点还暴露了产品定位上的深层错配。

开发者们表示喜欢这个工具，但团队受限于资金，无法构建一个完整的连接器目录。作者提到Nango是不错的选择，却也坦言"用不起"。这反映出中小开源项目在基础设施层竞争时的现实困境。

更关键的洞察在于目标用户错位：真正需要审批功能的，是业务拥有者（business owners），而不是开发者。但业务拥有者永远不会去搜索一个"审批SDK"——他们没有这个心智，也不说这套语言。工具再好，也触达不到真正愿意为它付费的人。

什么才是真正的护城河？

作者的判断相当清醒：一个单纯的"批准/拒绝"步骤太容易被复制，各大智能体宿主（host）和框架自己就能内建。真正有防御价值、能沉淀下来的，是那些随时间累积的资产：

• 信任历史：智能体过往行为的记录
• 自主权规则：动态演进的授权策略
• 审计轨迹：完整可追溯的操作日志

换句话说，拦截动作本身不值钱，拦截背后积累的治理数据才是壁垒。

浏览器智能体：网关彻底失效的盲区

还有一类场景让审批网关完全无能为力——浏览器智能体。

这类智能体虽然可以运行在MCP之上，但它们的实际操作是在用户自己的会话（session）下进行点击。网关面对一条"在坐标(x,y)处点击"的指令，既无法读懂背后的意图，手里也没有任何可以扣押的凭证。拦截在这里失去了所有抓手。

这个案例提醒我们，AI治理方案必须考虑智能体的多种行动模态，基于API调用的凭证托管思路，并不能覆盖基于GUI操作的智能体。

浏览器智能体（Browser Agent）是一类通过控制浏览器界面来执行任务的AI系统，代表性项目包括Playwright-based的Computer Use、Browser Use、Operator等。与调用结构化API不同，这类智能体的"操作原语"是像素级的UI交互：定位元素、点击按钮、填写表单、截图判断状态。由于操作目标是渲染后的界面而非后端接口，传统的凭证托管思路在此完全失效——用户本人已经登录浏览器，会话令牌由浏览器原生持有，智能体借用的是用户已有的身份，而非一个可被网关扣押的独立凭证。更棘手的是语义不透明问题：一条"点击坐标(320, 450)处的按钮"指令，网关无法判断这是在执行"确认转账1万元"还是"关闭弹窗"，意图识别需要视觉理解和业务上下文，远超简单规则引擎的能力边界。这也是为什么针对浏览器智能体的治理研究目前多聚焦于"任务级授权"而非"操作级拦截"。

走向可规模化：三层防护的组合拳

基于这些教训，作者提出了解锁规模化增长所需的三个要素：

1. 凭证托管 + 一键OAuth：这是最硬的强制层，智能体不持任何令牌。
2. 宿主层的工具调用前置钩子（pre-tool-call hooks）：作为第二道防线，在智能体宿主层面拦截。
3. 把审批送到业务拥有者本就在用的地方：WhatsApp、邮件、Slack，而不是让他们学习新工具。

这套组合的本质，是把"信任系统提示词"这种脆弱约定，替换为多层、不依赖智能体善意的硬性机制。

宿主层的工具调用前置钩子（pre-tool-call hooks）是指在智能体框架层面、在实际调用外部工具之前插入的拦截逻辑。以LangChain、LlamaIndex、Cursor等主流框架为例，它们通常提供回调（callback）或中间件机制，允许开发者在工具调用生命周期的特定节点注入自定义代码。与MCP网关方案相比，宿主层钩子的优势在于它更靠近"决策发生的地方"——在智能体选定工具、尚未发出实际请求之前就能介入，不依赖于智能体是否"选择"经过网关。但其局限同样明显：它与具体框架强耦合，跨宿主兼容性差；且若智能体运行在不受控的第三方宿主（如用户自行配置的客户端）上，企业侧根本无法植入钩子。因此这两种机制——凭证托管（基础设施层）与宿主钩子（框架层）——更多是互补而非替代关系，需要结合具体部署架构选择组合方式。

对AI治理从业者的启示

这篇复盘虽然来自一个尚未成熟的产品，但其价值恰恰在于诚实地暴露了行业共性问题。作者在文末向生产环境中运行智能体的同行抛出了一个值得深思的问题：

你们是如何在风险操作前强制执行审批的？是靠持有凭证的网关、宿主层钩子，还是仅仅信任系统提示词？

对于任何正在搭建AI智能体治理体系的团队，这里有几条可直接落地的结论：不要依赖提示词做安全边界，提示词是建议而非强制；把凭证作为控制点，谁持有令牌谁才有真正的否决权；以及治理的护城河在数据沉淀，而非拦截动作本身。随着智能体自主执行高风险操作的场景快速增多，这些认知的价值只会越来越高。