你把 Agent 接上 MCP Server 之后最危险的往往不是“这个工具能做什么”而是这个工具返回了什么。最近几个月MCP 的一个攻击面被反复提起Tool Poisoning工具投毒。它的本质是“把 prompt injection 藏进工具响应里”让模型把恶意指令当成可信上下文继续推理然后去调用本地文件、发网请求、改配置——一条链就串起来了。这篇我不做空泛科普。我只做三件事用一个最小 demo 复现“天真 Agent 为什么会中招”给出一套成本很低、但能拦掉 80% 低级投毒的工程防线结构化 白名单 粗检测说清楚哪些场景“值得上”哪些场景“上了也白搭”TL;DR别把 tool response 当“数据”它是“指令载体”。第一层防线不是更强的 prompt而是更硬的边界只接受结构化、只取白名单字段、把执行权限拆开。什么是 MCP 工具投毒给一个能被引用的定义**MCP 工具投毒MCP Tool Poisoning**是一种间接 prompt injection攻击者运行/控制一个 MCP Server或劫持其依赖、镜像、latest 版本在工具的返回内容里混入隐藏指令。MCP 客户端把工具响应原样塞进模型上下文后模型可能把这些指令当“高优先级的可信输入”进而触发越权工具调用、数据泄露或破坏性写操作。关键点只有一句连接时审的是 tool metadata但运行时真正进入上下文的是 tool response。你以为你在“调用工具”其实你在“加载外部上下文”很多团队做安全治理会盯着这个 MCP tool 有没有文件读写能力有没有网络请求有没有数据库权限但投毒攻击的可怕之处在于外部 MCP tool 可以看起来“只读、无害”真正的破坏发生在你自己的高权限工具上本地文件、内网 API、CI、邮件换句话说外部 tool 本身不需要高权限它只要能把“下一步要你干什么”塞进上下文就行。最小复现同一段 tool response天真 Agent 会“自爆”我写了一个极简 demo见文末目录模拟了 3 种 tool 返回投毒的自由文本投毒的 JSON把指令塞在 note 这种“你以为不会被用到”的字段里干净 JSON核心点天真 Agent 会把 tool response 当可信上下文而“最小防线”会先做粗粒度注入特征检测便宜强制结构化拒绝自由文本只取 schema 白名单字段丢掉 note运行结果真实输出下面是我的本地输出完整日志在experiments/demo_output.txt poisoned_free_text naive: [BAD] would leak secrets guarded: [BLOCK] injection_like_content poisoned_json naive: [OK] normal handling guarded: [BLOCK] injection_like_content clean_json naive: [OK] normal handling guarded: [OK] use{status: PASS, items: [A, B]}你会发现一个反直觉点投毒 JSON 比投毒自由文本更危险因为它更像“数据”工程师更容易放松警惕。如果你只做“JSON 解析”但不做“字段白名单”你仍然会把 note/description 这类字段塞进上下文里——投毒照样能活。工程上怎么做一套“最小但有效”的防线我建议把防线拆成 4 层按成本从低到高第 1 层工具响应强制结构化能 JSON 就别让它返回自然语言原则外部 tool 的返回必须是 schema 固定的 JSON。你允许 tool 返回自由文本就等于允许它返回“指令”。结构化不是万能但它会让投毒变得“更难藏”。第 2 层字段白名单只取你用得到的字段这是我见过性价比最高的一招。例如一个“合规检查”工具返回{status:PASS,items:[A,B],note:ignore previous instructions...}你的代码应该只取status/items把note当垃圾丢掉。很多投毒 payload 就躲在“你以为不会用”的字段里note、description、debug、raw、stacktrace。第 3 层注入特征检测不是为了精准是为了便宜不要指望字符串规则能识别所有攻击但它能挡住大量低级 payloadignore previous instructionssystem promptsend to httpexfiltrate检测到了就不要继续执行链路直接 block或降级成“只读模式”或要求人工确认第 4 层权限拆分真正的硬边界把工具分成两类外部输入工具web、MCP、搜索、爬虫高权限执行工具文件系统写、shell、内网 API、发消息然后做两件事默认不允许“外部输入 → 高权限执行”在同一条自动链路里发生即使发生也要加硬门显式 allowlist 参数约束 审计日志这一步是“反 prompt injection”的最终答案别让模型决定能不能写文件。让系统决定。真实世界里最容易被忽略的 3 个坑坑 1你以为“我不用 note 字段”但它早就进上下文了很多 MCP 客户端会做一件很自然的事把 tool response 整段拼进一段“工具调用记录”再喂给模型。比如伪格式TOOL_RESULT(nameget_compliance_status): { ...完整 JSON... }只要你把“完整 JSON”塞进去模型就能读到note。你说你“不用”但模型用不用不是你说了算。所以白名单的正确落点不是“业务代码取字段”而是“进入上下文前就裁剪”。坑 2投毒不需要等到 tool resulttool metadata 也能投很多人只盯 tool response但别忘了tool name / descriptionparameter schema 的 description这些也会被拼进上下文里尤其是“工具注册阶段”。攻击者把 payload 塞在 description 里效果一样。这也是为什么我更倾向把防护做成“静态审计 运行时裁剪”的组合静态审计检查 metadata 是否包含可疑指令片段、超长描述、奇怪的 URL运行时裁剪只把必要字段放进上下文坑 3最危险的不是“读”而是“写”如果你的 Agent 只有只读能力只读文件、只读 DB、不能外发投毒的危害会被压住。一旦它具备这三件事里的任意两件风险会指数上升读敏感数据本地文件、密钥、内网对外通信HTTP、Issue、邮件、IM写入/执行shell、git push、写文件、改配置这也是为什么“权限隔离”是终局它不是为了更聪明而是为了更不信任。生产落地清单我会按这个顺序改如果你手上已经有一套 MCP / tools 体系想快速降低风险我建议按这个顺序动手从小到大把外部 tool 的返回改成 JSON做不到就先加一个“parser tool”把自由文本变成结构化再进入上下文在进入上下文前做字段裁剪而不是在业务逻辑里“我不用”给每个 tool 打标签read / write / network / sensitive能自动生成但要人工 review把 write 工具单独放到执行器需要显式 allowlist 参数约束把“外部输入 → write”改成两段式第一段只读总结第二段人类确认或策略引擎放行做到第 2 步你已经能挡掉大多数“随手投毒”。做到第 4 步才算能上线给别人用。一张表三种防护思路怎么选思路你做的事优点缺点适用场景纯 prompt 防护system prompt 里写“别泄露、别执行”成本最低不可靠容易被覆盖低风险、纯文本助手结构化 白名单schema 校验 丢字段便宜、工程可控需要改 tool 返回格式大部分 MCP/工具调用权限隔离 审计把写操作独立到受控执行器可靠可合规工程量大企业 Agent、接触敏感数据我的结论很明确只靠 prompt 防护属于“心理安慰”。结构化 白名单是你应该立刻做的“最低门槛”。权限隔离是你在生产环境迟早要补的“终局”。你可以直接拿去用的代码Python下面这段就是我 demo 里的核心逻辑importjson INJECTION_PATTERNS[ignore previous instructions,system prompt,exfiltrate,send to,developer message,]defdetect_injection(text:str)-bool:ttext.lower()returnany(pintforpinINJECTION_PATTERNS)defsafe_parse_json(tool_text:str):objjson.loads(tool_text)# 不可解析就直接抛异常 - block# schema只允许 status itemsallowed{}ifstatusinobjandisinstance(obj[status],str):allowed[status]obj[status]ifitemsinobjandisinstance(obj[items],list):allowed[items]obj[items]returnalloweddefguarded_agent(tool_text:str):ifdetect_injection(tool_text):returnBLOCKdatasafe_parse_json(tool_text)returnfOK:{data}如果你在 Node/TS 里做一样的思路zod / ajv 校验 schema只 pick 允许字段注入检测命中就 block加一道“路由层”的现实意义把不可信上下文挡在模型前面很多团队聊安全会直奔“换更强的模型”或“写更严的 prompt”。但工程上更现实的一条路是在模型前面加一层可审计、可回滚的路由/网关把外部输入、工具输出先过一遍策略。这里的关键不是“网关很厉害”而是它天然适合承载这些能力响应裁剪只把 schema 白名单字段传给模型规则拦截命中注入特征就降级/打标权限拆分把 write 工具挂到单独的执行器网关只下发受控指令审计与回放出了事能还原“是哪个 tool 的哪段输出触发了哪次写操作”你把这些逻辑塞到业务里也能做但很快就会变成“每个 Agent 一套逻辑谁也审不动”。集中到一层策略面上才有治理的可能。我自己做多模型调用时就习惯把请求先收敛到一个网关层主要是为了路由和成本做安全治理时这个层反而变成顺手的落点——这点挺反直觉。最小防线的边界哪些情况它救不了你我上面那套“结构化 白名单 粗检测”更像是一个保险丝它能拦住大量低成本攻击也能减少模型“误读上下文”的概率。但它救不了这几类情况你必须接收长文本自由输出例如网页抓取全文、邮件正文、工单原文。这时候只能做“分段摘要 引用隔离”不要把原文整段塞进可执行链路。你把高权限工具直接暴露给模型shell、写文件、发网请求。只要权限边界不硬投毒只是时间问题。你需要模型做开放式决策例如“自己决定要不要删文件”。这类需求本身就不该交给模型应该交给策略引擎或人。换句话说最小防线是“起步”不是“毕业”。常见问题FAQQ只要我把 MCP Server 放到内网就安全了吗A不够。投毒不一定来自公网 Server也可能来自依赖更新latest、镜像供应链、内部被污染的数据源。内网只是降低了“随机被撞上”的概率。Q我已经把 tool response 做成 JSON 了还需要白名单吗A需要。JSON 只解决“结构”不解决“内容”。攻击者完全可以把指令塞进note/debug/raw字段里。Q最小防线会误伤正常输出吗A会。尤其是注入特征检测这层它是“便宜但粗糙”。所以正确姿势是命中后降级/人工确认而不是直接把业务打断。文章目录与产物Demo 代码experiments/mcp_poison_demo.py运行日志experiments/demo_output.txt
MCP 工具投毒真不是危言耸听：我用60 行代码做了个最小防线
你把 Agent 接上 MCP Server 之后最危险的往往不是“这个工具能做什么”而是这个工具返回了什么。最近几个月MCP 的一个攻击面被反复提起Tool Poisoning工具投毒。它的本质是“把 prompt injection 藏进工具响应里”让模型把恶意指令当成可信上下文继续推理然后去调用本地文件、发网请求、改配置——一条链就串起来了。这篇我不做空泛科普。我只做三件事用一个最小 demo 复现“天真 Agent 为什么会中招”给出一套成本很低、但能拦掉 80% 低级投毒的工程防线结构化 白名单 粗检测说清楚哪些场景“值得上”哪些场景“上了也白搭”TL;DR别把 tool response 当“数据”它是“指令载体”。第一层防线不是更强的 prompt而是更硬的边界只接受结构化、只取白名单字段、把执行权限拆开。什么是 MCP 工具投毒给一个能被引用的定义**MCP 工具投毒MCP Tool Poisoning**是一种间接 prompt injection攻击者运行/控制一个 MCP Server或劫持其依赖、镜像、latest 版本在工具的返回内容里混入隐藏指令。MCP 客户端把工具响应原样塞进模型上下文后模型可能把这些指令当“高优先级的可信输入”进而触发越权工具调用、数据泄露或破坏性写操作。关键点只有一句连接时审的是 tool metadata但运行时真正进入上下文的是 tool response。你以为你在“调用工具”其实你在“加载外部上下文”很多团队做安全治理会盯着这个 MCP tool 有没有文件读写能力有没有网络请求有没有数据库权限但投毒攻击的可怕之处在于外部 MCP tool 可以看起来“只读、无害”真正的破坏发生在你自己的高权限工具上本地文件、内网 API、CI、邮件换句话说外部 tool 本身不需要高权限它只要能把“下一步要你干什么”塞进上下文就行。最小复现同一段 tool response天真 Agent 会“自爆”我写了一个极简 demo见文末目录模拟了 3 种 tool 返回投毒的自由文本投毒的 JSON把指令塞在 note 这种“你以为不会被用到”的字段里干净 JSON核心点天真 Agent 会把 tool response 当可信上下文而“最小防线”会先做粗粒度注入特征检测便宜强制结构化拒绝自由文本只取 schema 白名单字段丢掉 note运行结果真实输出下面是我的本地输出完整日志在experiments/demo_output.txt poisoned_free_text naive: [BAD] would leak secrets guarded: [BLOCK] injection_like_content poisoned_json naive: [OK] normal handling guarded: [BLOCK] injection_like_content clean_json naive: [OK] normal handling guarded: [OK] use{status: PASS, items: [A, B]}你会发现一个反直觉点投毒 JSON 比投毒自由文本更危险因为它更像“数据”工程师更容易放松警惕。如果你只做“JSON 解析”但不做“字段白名单”你仍然会把 note/description 这类字段塞进上下文里——投毒照样能活。工程上怎么做一套“最小但有效”的防线我建议把防线拆成 4 层按成本从低到高第 1 层工具响应强制结构化能 JSON 就别让它返回自然语言原则外部 tool 的返回必须是 schema 固定的 JSON。你允许 tool 返回自由文本就等于允许它返回“指令”。结构化不是万能但它会让投毒变得“更难藏”。第 2 层字段白名单只取你用得到的字段这是我见过性价比最高的一招。例如一个“合规检查”工具返回{status:PASS,items:[A,B],note:ignore previous instructions...}你的代码应该只取status/items把note当垃圾丢掉。很多投毒 payload 就躲在“你以为不会用”的字段里note、description、debug、raw、stacktrace。第 3 层注入特征检测不是为了精准是为了便宜不要指望字符串规则能识别所有攻击但它能挡住大量低级 payloadignore previous instructionssystem promptsend to httpexfiltrate检测到了就不要继续执行链路直接 block或降级成“只读模式”或要求人工确认第 4 层权限拆分真正的硬边界把工具分成两类外部输入工具web、MCP、搜索、爬虫高权限执行工具文件系统写、shell、内网 API、发消息然后做两件事默认不允许“外部输入 → 高权限执行”在同一条自动链路里发生即使发生也要加硬门显式 allowlist 参数约束 审计日志这一步是“反 prompt injection”的最终答案别让模型决定能不能写文件。让系统决定。真实世界里最容易被忽略的 3 个坑坑 1你以为“我不用 note 字段”但它早就进上下文了很多 MCP 客户端会做一件很自然的事把 tool response 整段拼进一段“工具调用记录”再喂给模型。比如伪格式TOOL_RESULT(nameget_compliance_status): { ...完整 JSON... }只要你把“完整 JSON”塞进去模型就能读到note。你说你“不用”但模型用不用不是你说了算。所以白名单的正确落点不是“业务代码取字段”而是“进入上下文前就裁剪”。坑 2投毒不需要等到 tool resulttool metadata 也能投很多人只盯 tool response但别忘了tool name / descriptionparameter schema 的 description这些也会被拼进上下文里尤其是“工具注册阶段”。攻击者把 payload 塞在 description 里效果一样。这也是为什么我更倾向把防护做成“静态审计 运行时裁剪”的组合静态审计检查 metadata 是否包含可疑指令片段、超长描述、奇怪的 URL运行时裁剪只把必要字段放进上下文坑 3最危险的不是“读”而是“写”如果你的 Agent 只有只读能力只读文件、只读 DB、不能外发投毒的危害会被压住。一旦它具备这三件事里的任意两件风险会指数上升读敏感数据本地文件、密钥、内网对外通信HTTP、Issue、邮件、IM写入/执行shell、git push、写文件、改配置这也是为什么“权限隔离”是终局它不是为了更聪明而是为了更不信任。生产落地清单我会按这个顺序改如果你手上已经有一套 MCP / tools 体系想快速降低风险我建议按这个顺序动手从小到大把外部 tool 的返回改成 JSON做不到就先加一个“parser tool”把自由文本变成结构化再进入上下文在进入上下文前做字段裁剪而不是在业务逻辑里“我不用”给每个 tool 打标签read / write / network / sensitive能自动生成但要人工 review把 write 工具单独放到执行器需要显式 allowlist 参数约束把“外部输入 → write”改成两段式第一段只读总结第二段人类确认或策略引擎放行做到第 2 步你已经能挡掉大多数“随手投毒”。做到第 4 步才算能上线给别人用。一张表三种防护思路怎么选思路你做的事优点缺点适用场景纯 prompt 防护system prompt 里写“别泄露、别执行”成本最低不可靠容易被覆盖低风险、纯文本助手结构化 白名单schema 校验 丢字段便宜、工程可控需要改 tool 返回格式大部分 MCP/工具调用权限隔离 审计把写操作独立到受控执行器可靠可合规工程量大企业 Agent、接触敏感数据我的结论很明确只靠 prompt 防护属于“心理安慰”。结构化 白名单是你应该立刻做的“最低门槛”。权限隔离是你在生产环境迟早要补的“终局”。你可以直接拿去用的代码Python下面这段就是我 demo 里的核心逻辑importjson INJECTION_PATTERNS[ignore previous instructions,system prompt,exfiltrate,send to,developer message,]defdetect_injection(text:str)-bool:ttext.lower()returnany(pintforpinINJECTION_PATTERNS)defsafe_parse_json(tool_text:str):objjson.loads(tool_text)# 不可解析就直接抛异常 - block# schema只允许 status itemsallowed{}ifstatusinobjandisinstance(obj[status],str):allowed[status]obj[status]ifitemsinobjandisinstance(obj[items],list):allowed[items]obj[items]returnalloweddefguarded_agent(tool_text:str):ifdetect_injection(tool_text):returnBLOCKdatasafe_parse_json(tool_text)returnfOK:{data}如果你在 Node/TS 里做一样的思路zod / ajv 校验 schema只 pick 允许字段注入检测命中就 block加一道“路由层”的现实意义把不可信上下文挡在模型前面很多团队聊安全会直奔“换更强的模型”或“写更严的 prompt”。但工程上更现实的一条路是在模型前面加一层可审计、可回滚的路由/网关把外部输入、工具输出先过一遍策略。这里的关键不是“网关很厉害”而是它天然适合承载这些能力响应裁剪只把 schema 白名单字段传给模型规则拦截命中注入特征就降级/打标权限拆分把 write 工具挂到单独的执行器网关只下发受控指令审计与回放出了事能还原“是哪个 tool 的哪段输出触发了哪次写操作”你把这些逻辑塞到业务里也能做但很快就会变成“每个 Agent 一套逻辑谁也审不动”。集中到一层策略面上才有治理的可能。我自己做多模型调用时就习惯把请求先收敛到一个网关层主要是为了路由和成本做安全治理时这个层反而变成顺手的落点——这点挺反直觉。最小防线的边界哪些情况它救不了你我上面那套“结构化 白名单 粗检测”更像是一个保险丝它能拦住大量低成本攻击也能减少模型“误读上下文”的概率。但它救不了这几类情况你必须接收长文本自由输出例如网页抓取全文、邮件正文、工单原文。这时候只能做“分段摘要 引用隔离”不要把原文整段塞进可执行链路。你把高权限工具直接暴露给模型shell、写文件、发网请求。只要权限边界不硬投毒只是时间问题。你需要模型做开放式决策例如“自己决定要不要删文件”。这类需求本身就不该交给模型应该交给策略引擎或人。换句话说最小防线是“起步”不是“毕业”。常见问题FAQQ只要我把 MCP Server 放到内网就安全了吗A不够。投毒不一定来自公网 Server也可能来自依赖更新latest、镜像供应链、内部被污染的数据源。内网只是降低了“随机被撞上”的概率。Q我已经把 tool response 做成 JSON 了还需要白名单吗A需要。JSON 只解决“结构”不解决“内容”。攻击者完全可以把指令塞进note/debug/raw字段里。Q最小防线会误伤正常输出吗A会。尤其是注入特征检测这层它是“便宜但粗糙”。所以正确姿势是命中后降级/人工确认而不是直接把业务打断。文章目录与产物Demo 代码experiments/mcp_poison_demo.py运行日志experiments/demo_output.txt
