前言

2024年11月，Anthropic发布了Model Context Protocol（MCP），将其描述为"AI应用的USB-C接口"——一个让大语言模型能够无缝连接外部工具和数据源的通用协议。这一协议的发布标志着AI系统从单纯的文本生成迈向真正的"行动者"角色。然而，仅仅6个月后，安全研究人员就在MCP生态中发现了超过30个严重漏洞，其中包括CVSS评分高达9.6的远程代码执行漏洞（CVE-2025-6514）

这并非孤例。根据OWASP Top 10 for LLM 2025的更新，Excessive Agency（过度授权）被列为LLM应用面临的核心风险之一。当AI Agent获得调用工具、执行代码、访问数据库的能力时，攻击者也获得了前所未有的攻击面。一个精心构造的提示词注入，就可能让Agent绕过安全限制，调用敏感工具，甚至在企业内网中横向移动

Lakera AI在2025年第四季度的威胁报告中指出，针对AI Agent的攻击活动呈现爆发式增长，攻击者正在积极探索工具调用、文档访问、外部输入处理等新的攻击路径。更令人担忧的是，研究表明100%的测试LLM在面对跨Agent信任攻击时都会执行恶意命令——即使同样的命令在来自用户或RAG文档时会被拒绝

本文将从攻击者的视角出发，系统性地剖析LLM Agent工具调用中的安全风险。我们将深入MCP协议的设计缺陷，分析工具投毒、间接提示词注入、跨Agent信任攻击等新型攻击手法，并提出一套完整的防御体系。文章将包含大量可复现的实验、真实CVE漏洞的技术分析，以及我们原创设计的MCPSecEval安全评估框架

一、Agent工具调用机制全景

1.1 从Function Calling到Tool Use的演进

为什么工具调用成为AI的核心能力

大语言模型（LLM）的能力边界一直受制于其"只能输出文本"的本质局限。无论模型参数量如何增长，它始终无法直接查询实时数据、执行计算、操作文件或与外部系统交互。这一局限催生了"工具调用"（Tool Use / Function Calling）技术的快速演进。

第一阶段：ReAct范式（2022-2023）

2022年，Yao等人提出的ReAct（Reasoning and Acting）框架开创了LLM与外部工具交互的先河。在这一范式下，模型通过"思考-行动-观察"的循环来完成复杂任务：

​

这种范式虽然有效，但存在明显的局限性：工具调用依赖于文本解析，格式不统一，容易出错，且难以扩展

第二阶段：原生Function Calling（2023-2024）

2023年6月，OpenAI在GPT-3.5和GPT-4中引入了原生的Function Calling能力。模型不再需要通过文本解析来调用工具，而是直接输出结构化的JSON格式调用请求：

​

这一改进显著提升了工具调用的可靠性和可扩展性，但每个应用仍需为每个工具编写定制的集成代码

第三阶段：MCP协议标准化（2024至今）

2024年11月，Anthropic发布了Model Context Protocol（MCP），试图解决工具集成的碎片化问题。MCP的核心理念是：

1 统一接口：所有工具通过标准化的MCP Server暴露能力

2 即插即用：MCP Client可以自动发现和使用任何符合协议的工具

3 跨平台兼容：同一个MCP Server可以被不同的AI应用使用

这种"USB-C式"的标准化愿景迅速获得了行业的广泛支持。截至2025年1月，已有超过50,000个MCP Server被发布到各大平台，涵盖数据库操作、文件管理、API调用、浏览器自动化等几乎所有领域

工具调用的市场驱动力

工具调用能力的爆发式增长背后有着强劲的市场驱动力：

然而，这种能力的扩展同时也带来了前所未有的安全风险。 传统的LLM安全主要关注输出内容的安全性（如拒绝生成有害内容），而工具调用安全则涉及到实际的系统操作——一个被攻击的Agent可能会删除文件、转账、泄露数据，甚至控制整个基础设施

1.2 MCP协议架构深度剖析

MCP的设计哲学与架构

Model Context Protocol的设计借鉴了传统软件工程中的客户端-服务器架构，但针对LLM的特性做了专门的优化。理解MCP的架构是分析其安全风险的基础

核心组件：

MCP 架构由一个上层宿主（MCP Host）和多个下层 MCP Server 组成。

在 MCP Host（例如 Claude Desktop、Cursor、VS Code 或自定义应用）内部，运行着 MCP Client。MCP Client 的职责是：同时维护与多个 MCP Server 的连接；把各个 Server 提供的工具列表汇总起来，供 LLM 进行选择；并在 LLM 做出决定后，实际执行对应的工具调用。

在 Host 之外，可以并行连接多个 MCP Server。每个 MCP Server 面向不同能力或数据源，例如：

●MCP Server A：提供文件系统相关能力；

●MCP Server B：提供数据库相关能力；

●MCP Server C：提供 GitHub 相关能力。

每个 MCP Server 都可以对外提供三类内容：Tools、Resources和 Prompts。这些内容由MCP Client汇聚后交给LLM使用与调用。

MCP Server的三种能力：

1 Tools：可被LLM调用的函数，如read_file、query_database、send_email

2Resources：可被LLM读取的数据源，如文件内容、数据库记录

3Prompts：预定义的提示词模板，用于特定场景

典型的工具调用流程：

MCP协议的安全假设与现实差距

MCP协议的设计者做出了一系列安全假设，但这些假设在实际部署中往往不成立：

MCP规范中的关键安全声明：

根据MCP官方安全最佳实践文档，协议明确指出：

"For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations."

然而，这个"SHOULD"在实际实现中往往变成了"COULD"甚至被完全忽略。以Cursor、Claude Desktop等主流MCP Client为例，它们默认允许LLM自动执行工具调用，用户只有在事后才能看到执行日志

1.3 主流Agent框架工具调用机制对比

不同的Agent框架在工具调用的实现上存在显著差异，这些差异直接影响了它们的安全特性

框架对比分析

LangChain工具定义示例与风险

LangChain是目前最流行的LLM应用框架，其工具定义方式简洁但存在安全隐患：

风险分析：

1 无输入验证：工具直接执行LLM传入的参数，无任何过滤

2 权限过大：工具拥有数据库的完全访问权限

3 描述可被利用：工具描述会被LLM读取，攻击者可能利用描述注入指令

AutoGen多Agent协作的信任问题

AutoGen支持多个Agent协作完成任务，但Agent之间的信任传递存在严重问题：

研究数据：根据2025年ICLR发表的Agent Security Bench（ASB）论文，在测试的16个LLM Agent中：

● 没有任何Agent的安全评分超过60%

● 部分Agent的安全评分低至20%以下

●工具误用和隐性安全风险识别失败是最常见的问题

1.4 工具调用的信任模型与攻击面总览

工具调用的信任边界

在传统软件安全中，我们关注的是用户→应用→数据库的信任链。在Agent工具调用场景下，信任链变得更加复杂：

系统的整体流程是：用户输入进入 LLM，LLM 做出“是否以及调用什么工具”的选择决策，然后通过 MCP Client 调用 MCP Server，最终与外部系统交互

在这个过程中，LLM 的上下文不只来自用户输入，还可能混入多种外部来源：外部数据、RAG 检索结果，以及其他 Agent 传来的信息。这些来源都会影响 LLM 的工具选择与调用内容

关键风险在于：工具相关的信息（例如工具描述、可用参数、参数含义、返回值格式等）可能来自上述外部来源，而这些内容在某些情况下可能被攻击者注入或操控。一旦被操控，LLM 可能在工具选择决策时被误导，进而通过 MCP Client/Server 向外部系统发起不安全的调用或泄露数据

因此，“攻击面汇聚点”就是 LLM 进行工具选择决策并准备发起 MCP 调用的这个位置：它把用户输入与各种外部上下文汇合在一起，任何被污染的工具描述/参数/返回值都可能在这里产生放大效应，最终影响到对外部系统的实际操作

五大攻击面：

1 输入层攻击面：

○直接提示词注入（Direct Prompt Injection）

○间接提示词注入（Indirect Prompt Injection）

○跨Agent请求伪造

1 协议层攻击面：

○MCP协议实现漏洞

○OAuth流程缺陷

○传输层安全问题

1 工具定义层攻击面：

○工具描述投毒（Tool Poisoning）

○工具定义劫持（Rug Pull）

○工具重定义攻击

1 执行层攻击面：

○参数注入

○沙箱逃逸

○权限提升

1 数据层攻击面：

○敏感数据泄露

○凭证窃取

○上下文污染

攻击面的量化分析

根据我们对主流MCP Server的安全审计，攻击面分布如下：

核心发现：几乎所有的MCP Server都存在至少一种安全漏洞，而**85%**以上的Server缺乏基本的输入验证机制。这意味着攻击者只需找到一个薄弱环节，就可能突破整个Agent系统的安全边界

本文的攻防路线图

基于以上攻击面分析，本文将按照以下结构展开深入剖析：

攻击手法剖析
第二章：MCP协议层漏洞（CVE-2025-6514等）
第三章：工具定义投毒攻击
第四章：间接提示词注入与工具链劫持
第五章：跨Agent信任边界攻击
第六章：工具调用中的数据泄露
第七章：Agent权限与沙箱安全
防御体系构建
第八章：MCP安全评估框架设计
第九章：企业级Agent安全防御体系

在深入具体攻击手法之前，我们需要建立一个核心认知：Agent工具调用安全的本质是信任边界管理。LLM本身没有"恶意"的概念，它只是按照统计规律生成最可能的下一个token。当攻击者通过各种渠道向LLM注入指令时，LLM无法区分"合法用户的请求"和"攻击者的陷阱"。因此，安全防御的核心不是让LLM"变聪明"，而是在LLM周围建立严格的信任验证和权限控制机制

二、MCP协议层安全漏洞

2.1 MCP协议设计缺陷分析

协议设计的安全盲区

MCP协议的设计初衷是简化AI应用与外部工具的集成，但在追求便捷性的过程中，留下了多个安全盲区。这些盲区在2025年被安全研究人员逐一发现并利用

缺陷一：缺乏强制的Server认证机制

MCP协议允许Client连接到任何实现了协议接口的Server，但没有强制要求Server的身份验证。这意味着：

用户一旦被诱导添加恶意Server配置，该Server就能：

●获取所有工具调用的上下文

●伪装成合法工具接收敏感数据

●在工具响应中注入恶意指令

缺陷二：工具描述的隐式信任

MCP Server提供的工具描述会被直接传递给LLM作为决策依据。协议没有定义任何机制来验证描述的真实性或检测其中的恶意内容：

LLM会将{{SYSTEM: ...}}部分解释为系统指令，从而执行攻击者预设的操作

缺陷三：Sampling功能的信任反转

MCP协议中的Sampling功能允许Server向Client请求LLM补全。这一功能的设计初衷是让工具能够利用LLM的推理能力，但它同时创造了一个信任反转的攻击面：

恶意Server可以通过Sampling功能：

行业安全评估数据

2025年6月，安全研究机构对主流MCP实现进行了全面评估：

这一数据揭示了一个严峻的现实：MCP生态的安全成熟度远未达到企业级应用的要求。

2.2 CVE-2025-6514：mcp-remote命令注入漏洞剖析

漏洞背景

CVE-2025-6514是MCP生态中发现的第一个CVSS 9.6级别的严重漏洞，影响mcp-remote项目的0.0.5至0.1.15版本。mcp-remote是一个流行的OAuth代理工具，用于将本地MCP Client连接到远程MCP Server，被Cloudflare、Hugging Face、Auth0等知名组织的集成指南引用

截至漏洞披露时，mcp-remote已有超过437,000次下载，影响范围极其广泛

漏洞技术细节

漏洞的根本原因是mcp-remote在处理Server返回的OAuth回调URL时，未对URL参数进行充分的转义和验证，导致攻击者可以注入操作系统命令

漏洞代码位置：

攻击Payload构造：

在Windows系统上，攻击者可以构造如下恶意回调URL：

这会导致命令变成：

在Linux/macOS上，利用方式略有不同，但同样可以实现任意命令执行

攻击链路分析

完整的攻击链路如下：

攻击成功率分析：

漏洞修复与防御

官方修复方案（mcp-remote 0.1.16+）：

防御建议：

1 立即升级：将mcp-remote升级到0.1.16或更高版本

2 审查配置：检查所有MCP Server配置，移除不必要的远程连接

3 网络隔离：将MCP Server运行在隔离的网络环境中

4 监控异常：部署命令执行监控，检测异常进程创建

2.3 MCP Inspector远程代码执行漏洞

漏洞概述

MCP Inspector是Anthropic官方提供的开发调试工具，用于检查和测试MCP Server的行为。2025年4月，安全研究人员发现该工具存在未授权远程代码执行漏洞

漏洞特征：

●影响版本：MCP Inspector全部版本（截至披露时）

●CVSS评分：9.1

●攻击复杂度：低

●用户交互：需要（打开Inspector检查恶意Server）

漏洞机制

MCP Inspector的架构包含两个组件：

1 Inspector UI：运行在浏览器中的前端界面

2 Inspector Proxy：运行在本地的代理服务，处理与MCP Server的通信

漏洞存在于Inspector Proxy中。当开发者使用Inspector检查一个MCP Server时，Proxy会在本地监听端口（默认0.0.0.0:6274），但没有实现任何认证机制。

攻击场景

场景一：本地网络攻击

如果开发者在公司网络中使用MCP Inspector，同一网络中的攻击者可以直接发送请求：

场景二：恶意MCP Server触发

更隐蔽的攻击方式是通过恶意MCP Server触发。当开发者使用Inspector检查恶意Server时：

场景三：浏览器驱动攻击

由于Inspector UI运行在浏览器中，攻击者可以通过恶意网页触发攻击：

影响范围与修复

受影响用户：所有使用MCP Inspector的开发者，尤其是：

●AI应用开发团队

●MCP Server开发者

●安全研究人员（讽刺的是，检查恶意Server时反而被攻击）

修复建议：

1升级到包含修复的版本

2仅在隔离环境中使用Inspector

3配置防火墙阻止外部访问6274端口

4不要在生产环境运行Inspector

2.4 OAuth流程中的Confused Deputy攻击

OAuth在MCP中的应用

许多MCP Server需要访问第三方服务（如GitHub、Google Drive、Slack），这通常通过OAuth授权流程实现。MCP协议定义了一套OAuth集成规范，但这套规范存在被滥用的风险。

Confused Deputy攻击原理

Confused Deputy（困惑的代理）攻击是一种经典的权限提升攻击，在MCP OAuth场景下的表现形式如下：

攻击条件

该攻击需要以下条件同时满足：

1MCP Proxy Server使用静态client_id与第三方授权服务器通信

2MCP Proxy Server允许MCP Client动态注册（每个Client获得自己的client_id）

3第三方授权服务器在首次授权后设置consent cookie

4MCP Proxy Server在转发到第三方授权之前，没有实施每Client的consent验证

受影响的场景分析：

攻击代码示例

防御措施

根据MCP安全最佳实践，防御Confused Deputy攻击需要：

1. Per-Client Consent验证

MCP Proxy Server必须为每个动态注册的Client维护独立的consent状态：

2. Redirect URI严格验证

3. State参数的正确实现

2.5 协议层防御：安全MCP实现规范

基于以上漏洞分析，我们提出一套安全MCP实现规范，供开发者参考

安全MCP Server实现检查清单

MCP安全配置最佳实践

协议层安全的核心原则

总结本章的分析，MCP协议层安全需要遵循以下核心原则：

1 永不信任，始终验证：不要假设任何输入是安全的，包括来自"可信"Server的数据

2 最小权限原则：工具只应获得完成任务所需的最小权限

3 深度防御：在多个层次实施安全控制，任何单点失败不应导致完全妥协

4 可审计性：所有操作都应被记录，便于事后分析和取证

5 安全默认：安全选项应该是默认开启的，而非需要显式配置

三、工具定义投毒攻击

3.1 工具描述注入：隐藏指令的艺术

攻击原理

工具描述投毒（Tool Poisoning）是一种针对LLM Agent的新型攻击手法。其核心原理是利用LLM会将工具描述作为上下文的一部分进行处理这一特性，在看似正常的工具描述中嵌入恶意指令。

当MCP Client从Server获取工具列表时，会收到如下结构的数据：

这个描述会被原封不动地传递给LLM。攻击者可以在描述中嵌入隐藏指令：

隐藏指令的注入技术

攻击者使用多种技术来隐藏恶意指令，使其既能被LLM解析执行，又不易被人工审查发现：

技术一：HTML/Markdown注释

LLM通常会处理注释中的内容，尤其是当注释被框架解析为"系统级指令"时

技术二：Unicode隐写

利用零宽字符（Zero-Width Characters）嵌入不可见的指令：

技术三：同形字符替换

使用视觉上相同但Unicode编码不同的字符：

技术四：Base64/编码混淆

真实案例：GitHub MCP Server提示词注入

2025年3月，Invariant Labs发现了一个针对官方GitHub MCP Server的提示词注入攻击。攻击者利用公开的GitHub Issue作为注入载体：

攻击流程：

1攻击者在目标仓库创建一个看似正常的Issue：

1当用户使用AI助手分析这个Issue时，助手会读取Issue内容

2LLM将隐藏的指令解释为系统消息，执行恶意操作

3私有仓库信息和敏感文件被泄露到攻击者控制的仓库

攻击影响：

●私有仓库内容泄露

●环境变量和密钥泄露

●敏感项目信息外泄

●攻击者可持续获取更新（通过Issue订阅）

3.2 Tool Poisoning的形式化建模

为了更系统地理解和防御工具投毒攻击，我们提出一个形式化的攻击模型

攻击模型定义

定义1 - 工具定义：
一个工具T可以表示为四元组 T = (n, d, s, f)，其中：

●n: 工具名称

●d: 工具描述（自然语言）

●s: 输入模式（JSON Schema）

●f: 执行函数

定义2 - 投毒工具：
一个投毒工具T'可以表示为 T' = (n, d', s, f')，其中：

●d' = d ⊕ i（原始描述与恶意指令i的组合）

●f' 可能与f相同（仅描述投毒）或不同（功能投毒）

定义3 - 攻击成功条件：
给定LLM模型M、用户查询q、和工具集合{T1, T2, ..., Tn}，
攻击成功当且仅当：

1M选择调用包含投毒工具T'的操作序列

2T'的恶意指令i被M执行

3攻击者的目标（数据泄露/权限提升/拒绝服务）达成

攻击成功率的影响因素

通过实验，我们识别了影响工具投毒攻击成功率的关键因素：

不同LLM的易感性对比

我们测试了主流LLM对工具投毒攻击的易感性：

测试结果：

关键发现：

1所有测试的LLM都存在被工具投毒攻击的风险

2开源模型的易感性普遍高于闭源模型

3使用"SYSTEM"、"ADMIN"等权威词汇能显著提升攻击成功率

4将恶意操作包装为"安全操作"是最有效的攻击策略

3.3 Rug Pull攻击：工具定义的静默重定义

攻击原理

Rug Pull（抽地毯）攻击是一种延迟触发的工具投毒变体。攻击者首先发布一个完全正常的工具，在获得用户信任后，通过更新工具定义来植入恶意逻辑

MCP协议中的Rug Pull漏洞

MCP协议允许Server在运行时动态更新工具定义，这为Rug Pull攻击创造了条件：

检测Rug Pull攻击

检测Rug Pull攻击的关键是监控工具定义的变化：

3.4 MCPTox基准测试与检测方法

MCPTox基准测试介绍

MCPTox是2025年提出的工具投毒检测基准测试套件，用于评估MCP生态系统对工具投毒攻击的抵抗能力

基准测试结构：

基准测试结果（2025年1月）：

工具投毒检测方法

基于MCPTox的研究，我们提出以下检测方法：

方法一：语义一致性检测

检查工具描述与工具名称、参数之间的语义一致性：

方法二：LLM对抗性审计

使用另一个LLM来审计工具描述：

方法三：行为基线对比

监控工具调用的实际行为，与预期行为进行对比：

3.5 工具定义安全审计框架

综合以上检测方法，我们提出一个完整的工具定义安全审计框架：

四、间接提示词注入与工具链劫持

4.1 IPI攻击在工具调用场景的放大效应

间接提示词注入的定义与演进

间接提示词注入（Indirect Prompt Injection, IPI）是一种通过外部数据源向LLM注入恶意指令的攻击手法。与直接提示词注入（用户直接在输入中包含恶意指令）不同，IPI的恶意指令来自LLM处理的外部内容，如网页、文档、邮件、数据库记录等

IPI的演进：

工具调用放大IPI的机制

在工具调用场景下，IPI的危害被显著放大，原因如下：

1. 攻击向量倍增

每一个工具都是一个潜在的IPI注入点：

攻击者只需控制任一工具的响应，就能影响整个处理链路

2. 信任级别混淆

LLM通常对工具响应赋予较高的信任度——毕竟，这是"系统返回的数据"。这种隐式信任使IPI更容易成功：

3. 级联效应

一次成功的IPI可以触发后续的工具调用，形成攻击级联：

攻击成功率数据

根据Agent Security Bench (ASB) 的测试结果：

这一数据表明，工具响应作为IPI载体的成功率是直接注入的2.5-3.75倍。

4.2 GitHub MCP Server提示词注入案例

漏洞详情

2025年3月，Invariant Labs发现了针对官方GitHub MCP Server的严重提示词注入漏洞。该漏洞允许攻击者通过公开的GitHub内容（Issue、PR、README等）控制连接到该Server的AI助手的行为

攻击链路：

攻击Payload示例

Error: Cannot find module 'config'

漏洞复现

影响范围与修复

影响范围：

●所有使用GitHub MCP Server的AI应用

●估计影响用户数：50,000+

●潜在数据泄露：私有仓库内容、环境变量、API密钥

官方修复：

1在返回Issue/PR内容前进行净化

2添加内容来源标记，让LLM知道这是用户生成内容

3实施输出长度限制，防止过长的注入

4.3 工具响应污染与级联攻击

攻击原理

工具响应污染是IPI的一个变体，攻击者通过控制工具的返回值来注入恶意指令。这种攻击特别危险，因为工具响应通常被LLM视为可信的系统数据

攻击场景：

级联攻击链路设计

复杂的级联攻击可以跨越多个工具，形成攻击链：

检测与防御

检测方法：上下文隔离检测

防御方法：响应净化管道

4.4 文件系统MCP的沙箱逃逸

漏洞背景

文件系统MCP Server是最常用的MCP Server之一，允许AI助手读写本地文件。然而，Cymulate的安全研究人员发现，Anthropic官方的Filesystem MCP Server存在沙箱逃逸和符号链接绕过漏洞

沙箱逃逸漏洞

漏洞原理：

Filesystem MCP Server允许配置一个"允许访问的目录"列表，理论上AI助手只能访问这些目录中的文件。然而，实现中存在缺陷：

攻击方式：

符号链接绕过漏洞

攻击场景：

漏洞复现代码：

修复建议

1 使用realpath解析：在检查路径权限前，使用os.path.realpath()解析符号链接

2 禁用符号链接跟随：使用O_NOFOLLOW标志打开文件

3 实施chroot/容器隔离：将文件系统操作限制在容器内

4 白名单文件类型：只允许访问特定类型的文件

4.5 输入净化与输出验证防御体系

防御架构设计

基于以上分析，我们提出一个完整的输入净化与输出验证防御体系：

首先，用户输入进入系统后，会先经过“输入净化层”，对内容进行清洗与风险控制，然后才交给 LLM 处理。LLM 在需要调用工具时，请求会先经过“工具调用验证层”，只有验证通过才允许实际调用工具

工具执行后返回“工具响应”。工具响应不会直接交给用户，而是先进入“响应净化层”进行清理与安全处理，再交给 LLM 继续生成答案。最后，LLM 生成的结果还要经过“输出过滤层”做最终检查与过滤，之后才作为“最终输出”返回给用户

四层防御实现

五、跨Agent信任边界攻击

5.1 Multi-Agent系统的信任传递模型

Multi-Agent架构的兴起

2024-2025年，Multi-Agent系统从研究概念走向生产应用。这类系统中，多个专业化的Agent协作完成复杂任务：

用户的请求先发送给 Orchestrator Agent。Orchestrator 负责拆解任务并把子任务分发给不同的专职Agent，包括：Research Agent 用于搜索与信息收集，Analysis Agent 用于数据分析，Writer Agent 用于内容生成，Reviewer Agent 用于质量审核。各个 Agent 完成各自部分后再由Orchestrator汇总输出结果给用户

信任传递的隐性假设

Multi-Agent系统中存在一个危险的隐性假设：Agent之间是相互信任的。

这一假设体现在：

1 消息传递无验证：Agent A发送给Agent B的消息被直接处理，无来源验证

2 权限传递：高权限Agent可能基于低权限Agent的请求执行敏感操作

3 上下文共享：Agent之间共享的上下文可能包含被污染的数据

信任边界攻击面

Multi-Agent系统中的信任边界可以被攻击者利用：

5.2 Inter-Agent Trust Exploitation：100%成功率的攻击

研究发现

2025年发表的一项研究揭示了一个令人震惊的发现：100%的测试LLM在面对跨Agent信任攻击时都会执行恶意命令，即使同样的命令在来自用户或RAG文档时会被拒绝

实验设置：

测试结果：

攻击机制分析

为什么Agent对peer Agent的请求如此"信任"？

原因一：训练数据偏差

LLM的安全训练主要针对用户输入，而非Agent间通信。在训练数据中，"系统级"的消息通常被视为可信的

原因二：角色扮演效应

当LLM被赋予"Agent"角色时，它倾向于"配合"其他Agent的请求，认为这是"协作"的一部分

原因三：缺乏上下文边界

大多数Multi-Agent框架没有明确区分"用户请求"和"Agent请求"，它们在LLM的上下文中看起来相似

攻击演示

5.3 Agent协作中的权限提升链路

权限提升攻击模式

在Multi-Agent系统中，权限提升攻击可以利用Agent之间的信任关系：

真实案例：ServiceNow Now Assist二阶注入

2025年末，ServiceNow的AI助手（Now Assist）被发现存在二阶提示词注入漏洞，这是一个典型的跨Agent权限提升案例

漏洞详情：

ServiceNow的Agent系统采用分层架构：

● 前端Agent：处理用户请求，权限较低

● 后端Agent：执行实际操作，权限较高

●前端Agent可以请求后端Agent执行特定任务

攻击流程：

攻击Payload：

防御：Agent间通信签名验证

5.4 跨Agent零信任架构设计

零信任原则在Multi-Agent中的应用

将零信任（Zero Trust）原则应用于Multi-Agent系统：

核心原则：

1 永不信任，始终验证：每个Agent的每个请求都需要验证

2 最小权限：Agent只能访问完成任务所需的最小资源

3 假设被攻破：设计时假设任何Agent都可能被攻击

零信任Multi-Agent架构

Policy Engine：定义 Agent 权限策略，验证请求合规性，并可动态调整权限。
所有Agent的通信统一经过 Request Gateway：负责认证、授权、审计，以及内容检查与净化。
网关将请求分发给各个沙箱内的 Agent 执行：Agent A（沙箱）、Agent B（沙箱）、Agent C（沙箱）。

实现代码

Agent隔离与沙箱

六、工具调用中的数据泄露风险

6.1 敏感数据在工具参数中的暴露

数据泄露的攻击面

当LLM Agent调用工具时，敏感数据可能通过多种途径泄露：

真实场景分析

场景一：密码在工具参数中暴露

场景二：个人信息在多轮对话中累积

数据泄露检测

6.2 WhatsApp MCP数据外泄攻击链

漏洞背景

2025年4月，Invariant Labs发现了一个针对WhatsApp MCP Server的数据外泄攻击链。攻击者可以通过工具投毒，静默地窃取用户的完整WhatsApp聊天历史

攻击链路

攻击代码示例

受害者视角

防御措施

1. 工具调用白名单

2. 敏感工具隔离

6.3 凭证窃取与Token劫持

攻击向量

AI Agent在工作过程中会接触到大量凭证信息：

Token劫持攻击

凭证保护措施

6.4 数据外泄检测与DLP集成

数据外泄检测架构

整个链路从用户输入开始，系统会在不同阶段做敏感信息与外传风险的检测与控制：

1用户输入

○用户提交文本/内容进入系统

1输入敏感数据检测

○系统首先对用户输入进行扫描与识别

○目的：检测输入内容中是否包含敏感信息（例如：密钥、身份证号、客户数据、内部文档片段等）

1LLM处理

○若通过输入检测，内容进入大模型（LLM）推理与生成阶段

○该阶段负责理解用户意图、生成回复、决定是否需要调用工具

1工具调用监控

○系统对 LLM 的工具调用行为进行监控与分类

○目的：判断敏感数据是否可能沿工具调用路径“流向外部”

1工具调用分流

○内部工具调用（允许）

■调用企业内部工具/内部服务，默认允许执行（仍可记录审计）

○外部 API 调用（需重点审查）

■一旦识别到将要调用外部 API，会进入“外传数据检测”环节

1外传数据检测（DLP 集成）

○对即将发送到外部 API 的请求数据进行 DLP（数据防泄漏）检测与策略评估

○输出决策：

■通过：允许外部 API 调用执行

■阻止：拦截请求并触发告警（可选：记录事件、通知安全团队、提示用户脱敏等）

DLP集成实现

6.5 敏感数据脱敏与加密传输

数据脱敏策略

七、Agent权限与沙箱安全

7.1 过度授权：Excessive Agency风险

OWASP对Excessive Agency的定义

OWASP Top 10 for LLM 2025将**Excessive Agency（过度授权）**列为LLM应用的核心风险之一。该风险指的是AI Agent被授予了超出其任务需要的权限，导致攻击者可以利用这些过度权限造成更大的危害。

风险特征：

过度授权的常见模式

模式一：工具数量过多

模式二：权限范围过大

模式三：缺乏操作确认

权限最小化框架

7.2 代码解释器的沙箱逃逸

代码执行工具的风险

许多AI Agent提供代码执行能力（如Python解释器），这是最高风险的工具之一。代码执行工具的沙箱逃逸可能导致完全的系统控制。

风险场景：

常见沙箱逃逸技术

技术一：利用pickle反序列化

技术二：利用eval/exec绕过

技术三：利用import机制

安全沙箱实现

7.3 Bash工具的命令注入攻击

命令注入风险

当Agent拥有执行Shell命令的能力时，命令注入成为关键风险：

命令注入检测

安全命令执行

7.4 最小权限原则在Agent中的实践

最小权限实践框架

7.5 安全沙箱设计与实现

多层沙箱架构

综合沙箱实现

八、MCP安全评估框架设计

8.1 评估维度与指标体系

MCPSecEval框架概述

基于前文的攻击分析，我们提出MCPSecEval——一个专门针对MCP协议和Agent工具调用的安全评估框架。

框架目标：

1全面覆盖MCP相关的安全风险

2提供可量化的安全评估指标

3支持自动化安全测试

4生成可操作的安全报告

评估维度设计

安全评分模型

8.2 自动化安全测试套件架构

测试套件结构

8.3 红队测试方法论

红队测试框架

8.4 持续安全监控体系

监控架构

8.5 MCPSecEval框架实现

完整框架实现

九、企业级防御体系构建

9.1 纵深防御架构设计

防御体系总体架构

基于前文的攻击面分析，我们提出一套完整的企业级Agent工具调用安全防御体系。该体系遵循纵深防御（Defense in Depth）原则，在多个层次实施安全控制

企业级 Agent 工具调用安全防御体系分为五层，自外向内逐层加强防护，并在最底层提供审计与响应能力：

Layer 1：边界防护层
用于控制接入与通信安全，包括：MCP Server 准入控制、工具注册审核、协议级安全网关，以及流量加密与完整性验证

Layer 2：身份与访问控制层
用于确保“谁能用、能用到什么”，包括：统一身份认证、基于角色的访问控制（RBAC）、工具级细粒度授权，以及动态权限调整

Layer 3：内容安全层
用于降低提示词与数据层面的攻击风险，包括：提示词注入检测、工具描述净化、敏感数据识别与保护，以及输出过滤

Layer 4：运行时保护层
用于在执行阶段进行隔离与拦截，包括：工具调用沙箱、资源使用限制、异常行为检测，以及实时告警与阻断

Layer 5：审计与响应层
用于事后追踪与联动处置，包括：完整操作日志、安全事件关联分析、自动化响应编排，以及取证与溯源支持

各层防护能力详解

Layer 1: 边界防护层

边界防护层的核心目标是控制哪些MCP Server可以接入系统，以及确保传输过程的安全性。

Layer 2: 身份与访问控制层

Layer 3: 内容安全层

Layer 4: 运行时保护层

Layer 5: 审计与响应层

9.2 工具权限最小化框架

最小权限原则的应用

在Agent工具调用场景下，最小权限原则（Principle of Least Privilege）需要从多个维度实施：

实现方案

9.3 安全监控与告警体系

监控指标设计

9.4 安全配置基线

企业级MCP安全配置

禁止事项

禁止使用的词汇

●SYSTEM, ADMIN, OVERRIDE, IMPORTANT

●必须, 一定要, 首先, 同时, 另外

●调用, 执行, 发送, 访问 (引用其他工具时)

禁止的内容结构

● HTML/Markdown注释 <!-- -->

●隐藏的指令块

●Base64或其他编码内容

●外部URL（除文档链接外）

附录C：参考文献与延伸阅读

学术论文

1Greshake, K., et al. (2023). "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection." arXiv:2302.12173

2Mo, Y., et al. (2025). "Agent Security Bench (ASB): Formalizing and Benchmarking Attacks and Defenses in LLM-based Agents." ICLR 2025

3Wu, J., et al. (2024). "New Jailbreak Attack Targeting Tool-Integrated LLMs." arXiv:2409.10807

4Zou, A., et al. (2023). "Universal and Transferable Adversarial Attacks on Aligned Language Models." arXiv:2307.15043

技术报告

1OWASP. (2025). "OWASP Top 10 for LLM Applications 2025"

2Anthropic. (2024). "Model Context Protocol Specification"

3Lakera AI. (2025). "Q4 2025 AI Threat Landscape Report"

4Invariant Labs. (2025). "MCP Security Research Report"

标准与指南

1NIST. (2024). "AI Risk Management Framework"

2ISO/IEC. (2024). "ISO/IEC 42001 AI Management System"

工具与框架

1 Giskard AI. "LLM Security Testing Framework"
https://github.com/Giskard-AI/giskard

2 Rebuff. "Prompt Injection Detection Service"
https://github.com/protectai/rebuff

3 LangChain. "Security Best Practices"
https://python.langchain.com/docs/security

附录D：术语表