1. 恶意 MCP 服务器劫持 Cursor 内置浏览器到底怎么发生的MCP 服务器劫持 Cursor 内置浏览器指的是第三方 MCP 服务在工具描述里塞入对 AI 可见、对用户不可见的隐藏指令Cursor 的 Agent 解析后把这些指令当成正常任务执行最终把恶意 JS 注入到内置浏览器进程里。它能让攻击者在不改变地址栏 URL 的前提下替换页面内容、伪造登录框、读取 Cookie 与浏览历史甚至借 Cursor 的开发者权限执行系统命令。适合谁关注所有在 Cursor 里挂了第三方 MCP 服务、尤其是用 Cline MCP 做自动化浏览或多步 Agent 任务的开发者。我先把攻击链路拆成五步你对照自己的配置看卡在哪一环第一步你在~/.cursor/mcp.json里添加了一个来源不明的 MCP 服务器比如某个一键抓取网页并总结的开源服务。第二步Cursor 启动时向该服务器请求工具清单服务器在tools/list返回的工具描述里夹带隐藏指令常见手法是用[hidden-instruction]、HTML 注释或零宽字符包裹。第三步你在对话里让 Agent 调用这个工具Cursor 把工具描述整体喂给模型模型把隐藏指令当成用户意图的一部分。第四步恶意代码被拼进浏览器操作通过document.write或history.pushState完成页面替换且 URL 不变。第五步表单提交指向攻击者域名凭证、Cookie、历史记录被打包外发。关键漏洞点有三个理解它们才能对症下药。MCP 协议本身对工具描述没有强制完整性校验服务器返回什么客户端就信什么Cursor 没有对 MCP 返回的浏览器操作指令做安全过滤浏览器操作和普通工具调用走同一条信任路径内置浏览器基于 Electron和 IDE 共享权限上下文一旦浏览器被控文件系统和命令执行权限就一起暴露。这里要区分两类风险。一类是工具描述注入恶意内容藏在描述文本里靠模型解析触发另一类是返回值注入工具执行结果里带指令回传给模型时被当成新任务。前者在连接阶段就埋好后者在每次调用时都可能出现。防御要同时覆盖这两条路径只查mcp.json的来源白名单是不够的还得管住请求出口。我试过把 MCP 调用全部收敛到统一 API 通道再对出口做来源审计这样即使某个 MCP 服务器被污染异常外发请求也会在通道层暴露出来。下面几节就按白名单配置 → Base URL 校验 → 统一 Key 审计 → 排障的顺序给出可复制的做法。2. TaoToken 前置准备统一 Key 与 API 通道在动手配白名单之前先把请求出口统一掉。核心思路是不让每个 MCP 服务器各自持有五花八门的 Key 和 Base URL而是让它们统一走 TaoToken 的 API 通道这样所有出站请求的来源、模型、调用量都能在一处审计。一旦某个 MCP 服务器被污染、开始向陌生域名外发数据你在通道侧就能看到异常调用模式。你需要准备三样东西我把它叫三件套后面所有配置都围绕它展开Base URLhttps://taotoken.net/apiAPI Key在控制台创建建议按用途分 KeyMCP 专用一个Model ID按你实际使用的模型填写比如claude-sonnet-4-5这类标识以控制台展示为准创建 Key 的入口在控制台的 API Keys 页面地址是https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite。进去后新建一个 Key命名建议带mcp-前缀方便后续在审计日志里按 Key 过滤。创建完立刻复制保存页面刷新后不再完整显示。模型对话的调试入口在https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite你可以先用它验证 Key 和模型 ID 是否匹配再去配 MCP。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite里面有各客户端的字段对照配 Cline MCP 时对着看能少踩坑。为什么这一步对防御重要因为 MCP 劫持的最终目的是把数据送出去。如果每个 MCP 服务器都能自由指定 Base URL 和 Key你就失去了统一观测点。把出口收敛到 TaoToken 后你至少获得三个能力按 Key 区分调用来源、按时间线回看异常调用、在发现污染时一键吊销单个 Key 而不影响其他服务。这不是替代 Cursor 的安全机制而是在它之外加一层可观测的出口。如果你做长期编码或跑多步 Agent 任务建议用 Coding Plan 统一管理额度与 Key入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite。这样 MCP 调用和日常编码共用一套通道审计时不用在两个地方对账。3. 可复制配置MCP 白名单 Cursor Base URL 校验这一节给可直接粘贴的配置。先备份原文件再改。3.1 MCP 服务器白名单配置Cursor 的 MCP 配置在~/.cursor/mcp.json。不要直接删掉现有条目先重命名为mcp.json.bak留底然后写入下面这份带白名单注释的配置。注意JSON 不支持注释所以白名单靠命名约定和单独字段体现我在示例里用_allowlist字段记录审核信息实际生效的是mcpServers下的条目。{ mcpServers: { trusted-fetch: { command: npx, args: [-y, your-org/trusted-fetch-mcp1.2.3], env: { TAOTOKEN_BASE_URL: https://taotoken.net/api, TAOTOKEN_API_KEY: ${TAOTOKEN_MCP_KEY}, TAOTOKEN_MODEL_ID: claude-sonnet-4-5 }, _allowlist: { source: official, pinned_version: 1.2.3, reviewed_at: 2025-11-20, reviewer: self } } } }三个要点。第一args里锁定版本号不要用latest防止地毯式骗局——你审核时是干净版本下次启动拉到被污染的版本。第二Key 用环境变量引用${TAOTOKEN_MCP_KEY}不要把明文写进mcp.json这个文件容易被同步到云端或误提交。第三_allowlist字段是你的审核台账每次新增服务器都填团队协作时能看出谁在什么时候审过什么。如果你用 Cline MCP配置位置在 Cline 的 MCP 设置面板里字段名和上面一致同样要写全 Base URL、Key、Model ID 三件套。Cline 的配置界面会把env展开成表单逐项填即可别漏掉 Model ID否则调用会报模型不存在。3.2 Cursor Base URL 校验步骤Cursor 自身调用模型也有 Base URL 设置在设置里搜索OpenAI API Key或Base URL相关项。校验动作分三步第一步打开 Cursor 设置找到模型提供商配置区确认 Base URL 指向https://taotoken.net/api而不是某个陌生域名。第二步检查 API Key 是否为你刚创建的 MCP 专用 Key不要和编辑器主 Key 混用。第三步保存后重启 Cursor让 MCP 服务器重新握手。校验时重点看两处。一是mcp.json里每个服务器的env.TAOTOKEN_BASE_URL是否都是同一个值出现第二个不同域名就要警惕。二是 Cursor 设置里的 Base URL 是否和 MCP 配置一致不一致说明有请求绕过了统一通道。3.3 浏览器安全头补充配置在项目根目录创建.cursorrules加入基础安全头降低 XSS 和点击劫持面{ headers: { Content-Security-Policy: default-src self; script-src self https://trusted-domains.com, X-Frame-Options: DENY, X-XSS-Protection: 1; modeblock } }这份配置不能替代白名单它只影响页面渲染层的防护对工具描述注入无效。两者叠加用。4. 验证请求与成功结果配完要验证否则你不知道白名单是否真的生效。分三个验证动作。4.1 验证 MCP 服务器清单在终端执行cat ~/.cursor/mcp.json | python3 -m json.tool输出能正常解析说明 JSON 没写坏。再过滤出非白名单条目cat ~/.cursor/mcp.json | grep -vE trusted|official|known-service如果输出里出现你不认识的服务器名说明有未授权条目回到第 3 节清理。4.2 验证统一通道连通性用 curl 直接打 TaoToken 的 API确认 Key 和 Base URL 可用curl -sS https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_MCP_KEY \ -H Content-Type: application/json | head -c 500返回模型列表 JSON 说明通道正常。如果返回 401见第 5 节排障。这一步的意义是把 MCP 调用依赖的通道单独验证一遍排除是 MCP 配置问题还是 Key 问题的混淆。4.3 验证请求来源审计在 TaoToken 控制台的调用日志里按你创建的 MCP 专用 Key 过滤然后触发一次 Cline MCP 的浏览类工具调用。成功的结果是日志里出现一条来自该 Key 的调用记录模型 ID 与你配置的一致时间戳对得上你刚才的操作。如果触发后日志里没有新记录说明请求没走统一通道某个 MCP 服务器还在用自己内置的 Base URL回到第 3.1 节检查env。三个验证都通过后你的防御基线就建好了白名单控制入口统一通道控制出口审计日志提供可观测性。后续新增 MCP 服务器时重复第 3.1 节的审核流程即可。5. 本篇常见错排查这一节对照真实报错给处置方法。401 Unauthorized。最常见原因是 Key 没传对。检查三处mcp.json里${TAOTOKEN_MCP_KEY}对应的环境变量是否在当前 shell 会话里 export 了Key 是否被控制台吊销请求头是不是Authorization: Bearer格式。如果 curl 能通但 MCP 报 401说明 MCP 进程没继承到环境变量把 Key 写进 Cline 的 MCP 设置表单里再试。local proxy failed。这个报错通常出现在 MCP 服务器启动阶段说明本地代理或命令启动失败。先确认command和args里的包名、版本号拼写正确npx -y能否手动跑通。如果手动能跑、Cursor 里报错多半是 Cursor 的工作目录和环境变量与终端不同把绝对路径写进command。reading choices 报错。这是响应结构不符合预期常见于 Base URL 指向了不兼容的端点或者 Model ID 填错导致返回体里没有choices字段。核对 Base URL 是否为https://taotoken.net/apiModel ID 是否与控制台展示一致。用第 4.2 节的 curl 先确认通道返回结构正常再排查 MCP 侧。OAuth 相关报错。部分 MCP 服务器要求 OAuth 授权如果它同时又在工具描述里夹带指令风险更高。处置原则能不用 OAuth 类第三方 MCP 就不用必须用时确认授权回调域名是你认识的且该服务器的 Base URL 已收敛到统一通道。授权后回看审计日志确认没有向陌生域名发起的 token 交换请求。Codex auth.json 场景。如果你同时用 Codex 类客户端认证信息在auth.json里检查其中的 Base URL 字段是否也指向统一通道别让 Codex 成为绕过审计的第二个出口。三件套Base URL、Key、Model ID在 Codex 侧同样要写全。CC Switch 场景。用 CC Switch 切换配置时确认切换后的配置里 Base URL 和 Key 仍是统一通道的值切换动作容易把旧配置带回来。每次切换后跑一遍第 4.2 节的 curl 验证。排查的通用顺序是先 curl 验证通道再验证 MCP 配置解析最后看审计日志有没有记录。三步定位比盲目改配置快。6. 把防御动作固化下来最后给一份可执行的行动清单按优先级排立即做清理~/.cursor/mcp.json里所有非白名单服务器备份原文件给每个保留的服务器锁定版本号把 Key 改成环境变量引用。本周做把 MCP 调用出口收敛到 TaoToken 统一通道创建 MCP 专用 Key跑通第 4 节三个验证在控制台确认审计日志能看到 MCP 调用记录。持续做新增 MCP 服务器时填_allowlist台账每月回看一次审计日志里的异常调用模式关注 Cursor 和 MCP 协议的安全更新。需要复查配置时接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewriteKey 管理在https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite模型验证在https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite。长期跑 Agent 任务的话Coding Plan 入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite。防御的本质不是信任某个工具而是让每条出站请求都有据可查。白名单管住入口统一通道管住出口审计日志管住事后追溯三层叠起来MCP 劫持的路径就被切断了。 
长河君 · 2026/10/8 12:33:36 · 阅读 1.2k 恶意MCP服务器劫持Cursor内置浏览器：攻击链路拆解与TaoToken防御配置指南
1. 恶意 MCP 服务器劫持 Cursor 内置浏览器到底怎么发生的MCP 服务器劫持 Cursor 内置浏览器指的是第三方 MCP 服务在工具描述里塞入对 AI 可见、对用户不可见的隐藏指令Cursor 的 Agent 解析后把这些指令当成正常任务执行最终把恶意 JS 注入到内置浏览器进程里。它能让攻击者在不改变地址栏 URL 的前提下替换页面内容、伪造登录框、读取 Cookie 与浏览历史甚至借 Cursor 的开发者权限执行系统命令。适合谁关注所有在 Cursor 里挂了第三方 MCP 服务、尤其是用 Cline MCP 做自动化浏览或多步 Agent 任务的开发者。我先把攻击链路拆成五步你对照自己的配置看卡在哪一环第一步你在~/.cursor/mcp.json里添加了一个来源不明的 MCP 服务器比如某个一键抓取网页并总结的开源服务。第二步Cursor 启动时向该服务器请求工具清单服务器在tools/list返回的工具描述里夹带隐藏指令常见手法是用[hidden-instruction]、HTML 注释或零宽字符包裹。第三步你在对话里让 Agent 调用这个工具Cursor 把工具描述整体喂给模型模型把隐藏指令当成用户意图的一部分。第四步恶意代码被拼进浏览器操作通过document.write或history.pushState完成页面替换且 URL 不变。第五步表单提交指向攻击者域名凭证、Cookie、历史记录被打包外发。关键漏洞点有三个理解它们才能对症下药。MCP 协议本身对工具描述没有强制完整性校验服务器返回什么客户端就信什么Cursor 没有对 MCP 返回的浏览器操作指令做安全过滤浏览器操作和普通工具调用走同一条信任路径内置浏览器基于 Electron和 IDE 共享权限上下文一旦浏览器被控文件系统和命令执行权限就一起暴露。这里要区分两类风险。一类是工具描述注入恶意内容藏在描述文本里靠模型解析触发另一类是返回值注入工具执行结果里带指令回传给模型时被当成新任务。前者在连接阶段就埋好后者在每次调用时都可能出现。防御要同时覆盖这两条路径只查mcp.json的来源白名单是不够的还得管住请求出口。我试过把 MCP 调用全部收敛到统一 API 通道再对出口做来源审计这样即使某个 MCP 服务器被污染异常外发请求也会在通道层暴露出来。下面几节就按白名单配置 → Base URL 校验 → 统一 Key 审计 → 排障的顺序给出可复制的做法。2. TaoToken 前置准备统一 Key 与 API 通道在动手配白名单之前先把请求出口统一掉。核心思路是不让每个 MCP 服务器各自持有五花八门的 Key 和 Base URL而是让它们统一走 TaoToken 的 API 通道这样所有出站请求的来源、模型、调用量都能在一处审计。一旦某个 MCP 服务器被污染、开始向陌生域名外发数据你在通道侧就能看到异常调用模式。你需要准备三样东西我把它叫三件套后面所有配置都围绕它展开Base URLhttps://taotoken.net/apiAPI Key在控制台创建建议按用途分 KeyMCP 专用一个Model ID按你实际使用的模型填写比如claude-sonnet-4-5这类标识以控制台展示为准创建 Key 的入口在控制台的 API Keys 页面地址是https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite。进去后新建一个 Key命名建议带mcp-前缀方便后续在审计日志里按 Key 过滤。创建完立刻复制保存页面刷新后不再完整显示。模型对话的调试入口在https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite你可以先用它验证 Key 和模型 ID 是否匹配再去配 MCP。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite里面有各客户端的字段对照配 Cline MCP 时对着看能少踩坑。为什么这一步对防御重要因为 MCP 劫持的最终目的是把数据送出去。如果每个 MCP 服务器都能自由指定 Base URL 和 Key你就失去了统一观测点。把出口收敛到 TaoToken 后你至少获得三个能力按 Key 区分调用来源、按时间线回看异常调用、在发现污染时一键吊销单个 Key 而不影响其他服务。这不是替代 Cursor 的安全机制而是在它之外加一层可观测的出口。如果你做长期编码或跑多步 Agent 任务建议用 Coding Plan 统一管理额度与 Key入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite。这样 MCP 调用和日常编码共用一套通道审计时不用在两个地方对账。3. 可复制配置MCP 白名单 Cursor Base URL 校验这一节给可直接粘贴的配置。先备份原文件再改。3.1 MCP 服务器白名单配置Cursor 的 MCP 配置在~/.cursor/mcp.json。不要直接删掉现有条目先重命名为mcp.json.bak留底然后写入下面这份带白名单注释的配置。注意JSON 不支持注释所以白名单靠命名约定和单独字段体现我在示例里用_allowlist字段记录审核信息实际生效的是mcpServers下的条目。{ mcpServers: { trusted-fetch: { command: npx, args: [-y, your-org/trusted-fetch-mcp1.2.3], env: { TAOTOKEN_BASE_URL: https://taotoken.net/api, TAOTOKEN_API_KEY: ${TAOTOKEN_MCP_KEY}, TAOTOKEN_MODEL_ID: claude-sonnet-4-5 }, _allowlist: { source: official, pinned_version: 1.2.3, reviewed_at: 2025-11-20, reviewer: self } } } }三个要点。第一args里锁定版本号不要用latest防止地毯式骗局——你审核时是干净版本下次启动拉到被污染的版本。第二Key 用环境变量引用${TAOTOKEN_MCP_KEY}不要把明文写进mcp.json这个文件容易被同步到云端或误提交。第三_allowlist字段是你的审核台账每次新增服务器都填团队协作时能看出谁在什么时候审过什么。如果你用 Cline MCP配置位置在 Cline 的 MCP 设置面板里字段名和上面一致同样要写全 Base URL、Key、Model ID 三件套。Cline 的配置界面会把env展开成表单逐项填即可别漏掉 Model ID否则调用会报模型不存在。3.2 Cursor Base URL 校验步骤Cursor 自身调用模型也有 Base URL 设置在设置里搜索OpenAI API Key或Base URL相关项。校验动作分三步第一步打开 Cursor 设置找到模型提供商配置区确认 Base URL 指向https://taotoken.net/api而不是某个陌生域名。第二步检查 API Key 是否为你刚创建的 MCP 专用 Key不要和编辑器主 Key 混用。第三步保存后重启 Cursor让 MCP 服务器重新握手。校验时重点看两处。一是mcp.json里每个服务器的env.TAOTOKEN_BASE_URL是否都是同一个值出现第二个不同域名就要警惕。二是 Cursor 设置里的 Base URL 是否和 MCP 配置一致不一致说明有请求绕过了统一通道。3.3 浏览器安全头补充配置在项目根目录创建.cursorrules加入基础安全头降低 XSS 和点击劫持面{ headers: { Content-Security-Policy: default-src self; script-src self https://trusted-domains.com, X-Frame-Options: DENY, X-XSS-Protection: 1; modeblock } }这份配置不能替代白名单它只影响页面渲染层的防护对工具描述注入无效。两者叠加用。4. 验证请求与成功结果配完要验证否则你不知道白名单是否真的生效。分三个验证动作。4.1 验证 MCP 服务器清单在终端执行cat ~/.cursor/mcp.json | python3 -m json.tool输出能正常解析说明 JSON 没写坏。再过滤出非白名单条目cat ~/.cursor/mcp.json | grep -vE trusted|official|known-service如果输出里出现你不认识的服务器名说明有未授权条目回到第 3 节清理。4.2 验证统一通道连通性用 curl 直接打 TaoToken 的 API确认 Key 和 Base URL 可用curl -sS https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_MCP_KEY \ -H Content-Type: application/json | head -c 500返回模型列表 JSON 说明通道正常。如果返回 401见第 5 节排障。这一步的意义是把 MCP 调用依赖的通道单独验证一遍排除是 MCP 配置问题还是 Key 问题的混淆。4.3 验证请求来源审计在 TaoToken 控制台的调用日志里按你创建的 MCP 专用 Key 过滤然后触发一次 Cline MCP 的浏览类工具调用。成功的结果是日志里出现一条来自该 Key 的调用记录模型 ID 与你配置的一致时间戳对得上你刚才的操作。如果触发后日志里没有新记录说明请求没走统一通道某个 MCP 服务器还在用自己内置的 Base URL回到第 3.1 节检查env。三个验证都通过后你的防御基线就建好了白名单控制入口统一通道控制出口审计日志提供可观测性。后续新增 MCP 服务器时重复第 3.1 节的审核流程即可。5. 本篇常见错排查这一节对照真实报错给处置方法。401 Unauthorized。最常见原因是 Key 没传对。检查三处mcp.json里${TAOTOKEN_MCP_KEY}对应的环境变量是否在当前 shell 会话里 export 了Key 是否被控制台吊销请求头是不是Authorization: Bearer格式。如果 curl 能通但 MCP 报 401说明 MCP 进程没继承到环境变量把 Key 写进 Cline 的 MCP 设置表单里再试。local proxy failed。这个报错通常出现在 MCP 服务器启动阶段说明本地代理或命令启动失败。先确认command和args里的包名、版本号拼写正确npx -y能否手动跑通。如果手动能跑、Cursor 里报错多半是 Cursor 的工作目录和环境变量与终端不同把绝对路径写进command。reading choices 报错。这是响应结构不符合预期常见于 Base URL 指向了不兼容的端点或者 Model ID 填错导致返回体里没有choices字段。核对 Base URL 是否为https://taotoken.net/apiModel ID 是否与控制台展示一致。用第 4.2 节的 curl 先确认通道返回结构正常再排查 MCP 侧。OAuth 相关报错。部分 MCP 服务器要求 OAuth 授权如果它同时又在工具描述里夹带指令风险更高。处置原则能不用 OAuth 类第三方 MCP 就不用必须用时确认授权回调域名是你认识的且该服务器的 Base URL 已收敛到统一通道。授权后回看审计日志确认没有向陌生域名发起的 token 交换请求。Codex auth.json 场景。如果你同时用 Codex 类客户端认证信息在auth.json里检查其中的 Base URL 字段是否也指向统一通道别让 Codex 成为绕过审计的第二个出口。三件套Base URL、Key、Model ID在 Codex 侧同样要写全。CC Switch 场景。用 CC Switch 切换配置时确认切换后的配置里 Base URL 和 Key 仍是统一通道的值切换动作容易把旧配置带回来。每次切换后跑一遍第 4.2 节的 curl 验证。排查的通用顺序是先 curl 验证通道再验证 MCP 配置解析最后看审计日志有没有记录。三步定位比盲目改配置快。6. 把防御动作固化下来最后给一份可执行的行动清单按优先级排立即做清理~/.cursor/mcp.json里所有非白名单服务器备份原文件给每个保留的服务器锁定版本号把 Key 改成环境变量引用。本周做把 MCP 调用出口收敛到 TaoToken 统一通道创建 MCP 专用 Key跑通第 4 节三个验证在控制台确认审计日志能看到 MCP 调用记录。持续做新增 MCP 服务器时填_allowlist台账每月回看一次审计日志里的异常调用模式关注 Cursor 和 MCP 协议的安全更新。需要复查配置时接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewriteKey 管理在https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite模型验证在https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite。长期跑 Agent 任务的话Coding Plan 入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentdefense_guideutm_campaignrewrite。防御的本质不是信任某个工具而是让每条出站请求都有据可查。白名单管住入口统一通道管住出口审计日志管住事后追溯三层叠起来MCP 劫持的路径就被切断了。