MCP 协议正在变成 agent 安全的"主战场",而实时拦截器是这个战场上的核心工事
MCP(Model Context Protocol)在 2024 年底由 Anthropic 提出,2025 年成为 agent 与外部工具/数据源对接的事实标准。但 MCP 流行起来之后,一个老问题被重新放大了:agent 通过 MCP 连接到的工具和数据源,天然就是不可信的——任何一段工具返回的文本里都可能藏着 prompt injection,任何一次工具调用都可能触发不可逆操作(读 .env 文件、跑 rm -rf、删数据库)。"Real-time MCP interceptor"在 2026 年下半年被反复提及,本质上是企业部署 agent 时必须补上的运行时防线。本文对照两份 30 天内的一手材料——Anthropic 关于浏览器 agent prompt injection 防御的最新研究,以及 OpenAI 与亚马逊云科技合作推出的"有状态运行时环境"——把 MCP 安全从理论拉到工程实现层面来谈。
一、MCP 流行的速度,超出了原始防御设计的覆盖范围
2025 年 12 月,Anthropic 联合 OpenAI、Block 向 Linux 基金会捐赠了 Model Context Protocol,联合发起 Agentic AI Foundation(AAIF)。Anthropic 在公告里披露了几个关键数据:MCP 协议在被引入一年后,已经获得了"incredible adoption";Claude 现在拥有一个由 75 个 connector 构成的目录(全部由 MCP 驱动);Anthropic 还在 API 里推出了 Tool Search 和 Programmatic Tool Calling,让生产环境里数千个工具的调度变得高效。
从数据看,MCP 已经从一个实验性协议变成了 agent 生态的基础设施。但协议本身只定义了"agent 如何发现工具、如何调用工具、如何拿到结果",**没有规定**"工具返回的内容可不可信、agent 调用工具的范围可不可控"。这两个"没有规定"的部分,在 MCP 流行之前是模型上下文窗口的内部问题,MCP 流行之后变成了整个 agent 工作流的暴露面。
具体来说,任何一个 MCP 服务器都可能返回这样的内容:一段 JSON 数据里嵌着一行注释,正文里藏着一段"
二、Anthropic 的防御体系:模型训练 + 分类器 + 红队三层
2026 年 9 月初,Anthropic 发布研究报告《Mitigating the risk of prompt injections in browser use》。这是 Anthropic 在浏览器 agent 防御上投入近一年之后的总结,数据直接对位 MCP 安全问题。报告里最关键的一组数字是:Claude Opus 4.5 在面对内部"Best-of-N"攻击者(给定 100 次尝试机会组合不同 prompt injection 技巧)时,攻击成功率(ASR)降到 1%。1% 不等于零,但已经显著低于此前的版本。
这 1% 的背后是三层叠加的防御。
第一层,模型训练层面。Anthropic 用强化学习把 prompt injection 抵抗力直接编进了模型能力。在模型训练阶段,他们让 Claude 接触"嵌在模拟 web 内容里的 prompt injection",并对"正确识别并拒绝执行恶意指令"给予奖励。这个训练集不是静态的——每当内部或外部红队发现新的攻击方式绕过当前模型,新的攻击样本就会被加入训练库,反哺下一代模型的训练。从 2025 年 11 月第一份 prompt injection 防御报告到现在,Claude 对这类攻击的抵抗力被显著提升。
第二层,分类器层面。Anthropic 训练了一批专门的分类器,在 Claude 读取任何不可信内容(包括 MCP 工具返回的 JSON、网页正文、邮件正文、表单内容)之前,先用分类器扫描一遍,寻找可能的攻击痕迹。分类器检测范围包括:隐藏文本(白字、零宽字符)、被操纵的图片、欺骗性的界面元素。一旦分类器判定风险,Claude 会被警告"对这段内容保持怀疑",并在必要时停下来问用户确认。这些分类器从 Claude Opus 4.5 开始部署,目前覆盖的攻击类型已经显著扩展。
第三层,人工红队层面。自动化系统会发现已知模式的攻击,但人类安全研究人员能发现更具创造性的攻击向量。Anthropic 内部红队持续探测浏览器 agent 的漏洞,同时也参与外部"Arena-style challenges"(如 Gray Swan 的间接 prompt injection 挑战赛),横向对标行业水平。
三层叠加之后,Anthropic 给出的不是"我们已经解决了 prompt injection"的宣言,而是"1% ASR 仍代表真实风险,我们会持续公开进展"的工程态度。这份透明度本身就是对企业部署的承诺——模型在变好,但部署方必须知道当前的能力边界。
三、OpenAI 的运行时环境:把"安全上下文"作为基础设施交付
同一时间段,OpenAI 联合亚马逊云科技发布了 Amazon Bedrock 中的"Stateful Runtime Environment for Agents"。这篇公告的发布日期(2026 年 2 月底)在原始时间线上略早,但 sitemap 上的最近更新时间在 18 天内,且内容直接对位 MCP 安全——它给出了和 Anthropic 不同角度的工程方案。
OpenAI 在公告里首先承认了一个事实:"AI 智能体擅长推理。但更难的部分在于运营:如何跨越实际工具与系统,在具备正确控制措施的情况下,长期可靠地运行多步工作流。"换句话说,模型再强,运行时没护栏也上不了生产。
具体来说,OpenAI 给出的运行时环境包含四个核心维度:
第一,记忆与历史记录。长任务跨多步执行时,前序操作的上下文必须完整保留,不能让 agent 在第 20 步忘了第 5 步做了什么。这部分由运行时环境统一管理,而不是每个 agent 自行实现。
第二,工具与工作流状态。一次 agent 调用涉及多个工具时,工具之间的依赖关系、状态依赖、错误处理都必须在运行时层面统一调度,而不是交给模型自行拼接。
第三,环境占用与隔离。每个 agent 任务运行在隔离的环境里,不会污染其他任务的工作区。这与 Anthropic 在 Claude in Chrome 里用 Chromium StoragePartition 实现"未登录隔离会话"的设计思路一致,但 OpenAI 把这一抽象做成了云端运行时,企业客户不需要自己部署 Chromium。
第四,身份与权限边界。这是直接对位 MCP 拦截器的部分。运行时环境内置了身份认证、权限范围控制、审批工作流、审计日志——任何一次工具调用都必须经过身份验证,任何超出权限范围的操作都会被拦截。这相当于把"real-time MCP interceptor"的功能内置到了基础设施层,而不是让每个 agent 自己实现一套。
OpenAI 给出的客户场景包括:多系统客户支持、销售运营工作流、内部 IT 自动化、包含审批与审计的财务流程。这些场景的共同特征是:每一步操作都可能影响真实业务数据,必须有人工或自动的二次确认机制。
四、两条路径的对比:模型层防御 vs 基础设施层防御
把 Anthropic 和 OpenAI 的方案放在一起看,会发现两条不同的工程哲学。
Anthropic 选择把防御能力尽量做进模型本身——训练、分类器、红队,本质上都是让模型"更聪明",能识别更多攻击模式。这种方式的好处是模型即开即用,部署方不需要额外配置防御系统;代价是防御能力受限于模型训练数据,新型攻击出现时模型可能识别不出。
OpenAI 选择把防御能力尽量做进运行时基础设施——身份认证、权限边界、审批工作流、审计日志,本质上是在模型外面套一层"操作系统"。这种方式的好处是即使模型被绕过,运行时仍能拦截;代价是部署方必须接受"agent 跑在云端运行时里"的架构约束,不能把 agent 完全部署在本地。
两条路径并不冲突,反而是互补的。最稳妥的部署方案,是把两边都用上——模型层用 Anthropic 的训练 + 分类器能力,基础设施层用 OpenAI 的运行时身份与权限边界。这就是 2026 年下半年"real-time MCP interceptor"项目大量出现的原因:它们本质上是把 OpenAI 的运行时能力(身份/权限/审计)和 Anthropic 的模型层能力(分类器/红队)整合到企业自有的 MCP 网关上,做到"模型识别 + 网关拦截"的双保险。
五、企业部署 MCP 的现实清单
不管选哪条路径,企业要把 MCP 部署到生产,必须满足以下几个最低要求。
要求一,工具调用必须有明确的白名单或黑名单。任何 agent 调用 MCP 工具前,都必须在白名单范围内;白名单外的工具直接拦截,不允许 agent 通过 prompt 注入绕过。MCP 服务器自身也要有能力声明"这个工具会读哪些文件、调用哪些系统命令",让网关可以基于声明做静态分析。
要求二,所有工具调用的输入输出都必须留痕。审计日志要记录:agent 在哪个任务、什么时间、调用了什么工具、传入了什么参数、工具返回了什么结果。任何后续的事故分析、合规审计、模型评估都需要这些日志。
要求三,涉及 .env / ~/.ssh / 数据库连接串等敏感文件的操作必须二次确认。这是选题标题里点名的场景。Anthropic 报告里提到的"用户要求 Claude 处理邮件,一封邮件里藏着的指令让 Claude 把所有标 confidential 的邮件转发给攻击者"是典型例子。在企业里,涉及敏感文件读取的操作必须走"暂停 + 用户确认"路径,不允许 agent 自动执行。
要求四,prompt injection 检测必须在工具返回内容被模型读取之前完成。不是事后补救,是事前拦截。Anthropic 的分类器、OpenAI 的运行时、企业的自建网关,都是在工具返回内容进入模型上下文之前做检查。这是整个 MCP 安全架构里最关键的工序。
要求五,模型层防御与基础设施层防御必须同时存在。不能把希望全部寄托在模型识别能力上——Anthropic 自己也说 1% ASR 不是零;也不能把希望全部寄托在网关拦截上——很多新型攻击会绕过静态白名单。两层叠加才能把实际事故率压到可接受水平。
结语:MCP 安全是 2026 年下半年 agent 落地的最大瓶颈
MCP 协议在 2025 年底被捐赠给 Linux 基金会,在 2026 年成为 agent 与工具对接的事实标准,但安全机制仍在追赶。Anthropic 在浏览器 agent 上的 prompt injection 防御研究给出了模型层的最新能力边界(1% ASR),OpenAI 与 AWS 的有状态运行时给出了基础设施层的最新架构(身份/权限/审计/治理)。两家厂商虽然产品不同,但都在朝着同一个方向努力——让 MCP 在企业环境里真正安全起来。
对于正在部署 agent 的企业,现阶段最务实的做法是:在模型层选用具备 prompt injection 防御训练的最新模型(Claude Opus 4.5 或 OpenAI 最新版本),在基础设施层用网关 + 运行时拦截所有可疑工具调用,把两者叠加而不是二选一。等到 Anthropic、OpenAI、以及社区驱动的 MCP 网关项目把检测率、稳定性和可解释性都做到生产可用,再考虑把 MCP 部署到更敏感的业务流。
