文档索引
获取完整文档索引： https://docs.crewai.com.cn/llms.txt
在深入了解之前，请使用此文件来浏览所有可用页面。
概述
将外部服务（如 MCP - 模型上下文协议服务器）集成到 CrewAI 智能体时，安全性至关重要。MCP 服务器可以执行代码、访问数据，或根据其公开的工具与其他系统进行交互。了解相关影响并遵循最佳实践以保护你的应用程序和数据至关重要。风险
- 在运行智能体的机器上执行任意代码（特别是使用
Stdio传输协议时，如果服务器可以控制所执行的命令）。 - 泄露来自你的智能体或其环境的敏感数据。
- 以非预期的方式操纵你的智能体行为，包括代表你进行未经授权的 API 调用。
- 通过复杂的提示词注入（Prompt Injection）技术劫持智能体的推理过程（详见下文）。
1. 信任 MCP 服务器
在配置MCPServerAdapter 以连接到 MCP 服务器之前，请确保你了解：
- 谁在运营该服务器？ 这是一个知名且信誉良好的服务，还是你控制下的内部服务器？
- 它公开了哪些工具？ 了解这些工具的功能。如果攻击者获得控制权，或者服务器本身是恶意的，这些工具是否会被滥用？
- 它访问或处理什么数据？ 注意可能发送给 MCP 服务器或由其处理的任何敏感信息。
2. 通过工具元数据进行的安全提示词注入：“模型控制协议”风险
一个重大且隐蔽的风险是通过工具元数据进行提示词注入的可能性。其原理如下：- 当你的 CrewAI 智能体连接到 MCP 服务器时，通常会请求可用工具列表。
- MCP 服务器会返回每个工具的元数据，包括名称、描述和参数说明。
- 智能体底层的语言模型（LLM）使用此元数据来理解如何以及何时使用这些工具。此元数据通常会被合并到 LLM 的系统提示词或上下文中。
- 恶意的 MCP 服务器可以精心构造其工具元数据（名称、描述），包含隐藏或明显的指令。这些指令可以作为提示词注入，实际上是在告诉你的 LLM 表现出某种特定的行为、泄露敏感信息或执行恶意操作。
- 对不受信任的服务器保持极度谨慎： 重申：不要连接到你不完全信任的 MCP 服务器。 元数据注入的风险使得这一点至关重要。
Stdio 传输安全性
Stdio（标准输入/输出）传输通常用于与 CrewAI 应用程序在同一台机器上运行的本地 MCP 服务器。- 进程隔离：虽然通常更安全，因为它默认不涉及网络暴露，但请确保由
StdioServerParameters运行的脚本或命令来自受信任的源，并具有适当的文件系统权限。恶意的 Stdio 服务器脚本仍然可能损害你的本地系统。 - 输入清理：如果你的 Stdio 服务器脚本接收来自智能体交互的复杂输入，请确保脚本本身会对这些输入进行清理，以防止脚本逻辑内发生命令注入或其他漏洞。
- 资源限制：请注意，本地 Stdio 服务器进程会消耗本地资源（CPU、内存）。确保其行为良好，不会耗尽系统资源。
混淆代理（Confused Deputy）攻击
混淆代理问题（Confused Deputy Problem）是一种经典的安全性漏洞，在 MCP 集成中可能会显现，特别是当 MCP 服务器充当第三方服务（如 Google Calendar、GitHub）使用 OAuth 2.0 进行授权的代理时。 场景：- 一个 MCP 服务器（称之为
MCP-Proxy）允许你的智能体与ThirdPartyAPI进行交互。 MCP-Proxy在与ThirdPartyAPI的授权服务器通信时，使用其自己唯一的静态client_id。- 作为用户，你合法地授权
MCP-Proxy代表你访问ThirdPartyAPI。在此过程中，ThirdPartyAPI的授权服务器可能会在你的浏览器中设置一个 cookie，表明你同意MCP-Proxy使用该client_id。 - 攻击者伪造了一个恶意链接。该链接启动了与
MCP-Proxy的 OAuth 流程，但旨在欺骗ThirdPartyAPI的授权服务器。 - 如果你点击此链接，且
ThirdPartyAPI的授权服务器看到你之前为MCP-Proxy的client_id设置的同意 cookie，它可能会跳过再次请求你的同意这一步骤。 MCP-Proxy可能会被诱骗将授权码（用于ThirdPartyAPI）转发给攻击者，或者诱骗其生成一个攻击者可以用来冒充你登录MCP-Proxy的 MCP 授权码。
- 对于下游服务使用静态客户端 ID 的 MCP 代理服务器，在启动与第三方服务的 OAuth 流程之前，必须针对每个连接的客户端应用程序或智能体获取明确的用户同意。这意味着
MCP-Proxy本身应该显示一个同意页面。
- 如果 MCP 服务器多次重定向你进行 OAuth 认证，请保持警惕，特别是当流程出乎意料或请求的权限过于宽泛时。
- 优先选择那些明确区分其自身身份与所代理的第三方服务身份的 MCP 服务器。
远程传输安全性（SSE 和流式 HTTP）
通过服务器发送事件（SSE）或流式 HTTP 连接到远程 MCP 服务器时，标准的 Web 安全实践至关重要。SSE 安全注意事项
a. DNS 重新绑定攻击（特别是针对 SSE）
DNS 重新绑定允许受攻击者控制的网站绕过同源策略，并对用户本地网络（如localhost）或内网中的服务器发出请求。如果你在本地运行 MCP 服务器（例如用于开发）而智能体在类似浏览器的环境中运行（虽然在典型的 CrewAI 后端设置中较少见），或者 MCP 服务器位于内部网络上，风险尤其大。 针对 MCP 服务器实现者的缓解策略：- 验证
Origin和Host请求头：MCP 服务器（特别是 SSE 服务器）应验证Origin和/或HostHTTP 请求头，以确保请求来自预期的域名/客户端。 - 绑定到
localhost(127.0.0.1)：在开发过程中本地运行 MCP 服务器时，将其绑定到127.0.0.1而不是0.0.0.0。这可以防止网络上的其他机器访问它。 - 认证：如果你的 MCP 服务器并非用于公共匿名访问，请要求对所有连接进行身份验证。
b. 使用 HTTPS
- 加密传输中的数据：远程 MCP 服务器的 URL 请始终使用 HTTPS（HTTP 安全协议）。这可以加密你的 CrewAI 应用程序与 MCP 服务器之间的通信，防止窃听和中间人攻击。
MCPServerAdapter将遵循 URL 中提供的协议方案（http或https）。
c. 令牌传递（反模式）
这主要涉及 MCP 服务器开发者，但了解它有助于选择安全的服务器。 “令牌传递”是指 MCP 服务器接受来自 CrewAI 智能体的访问令牌（该令牌可能是用于其他服务，例如ServiceA），并直接将其传递给下游的另一个 API（ServiceB），而无需进行适当的验证。具体而言，ServiceB（或 MCP 服务器本身）应仅接受明确为它们签发的令牌（即令牌中的“受众”声明与服务器/服务匹配）。 风险：- 绕过 MCP 服务器或下游 API 上的安全控制（如速率限制或细粒度权限）。
- 破坏审计追踪和问责制。
- 允许滥用被盗的令牌。
- MCP 服务器严禁接受非明确为其签发的令牌。它们必须验证令牌的受众（audience）声明。
- 虽然用户无法直接控制这一点，但这强调了连接到遵循安全最佳实践、设计良好的 MCP 服务器的重要性。
身份验证和授权
- 验证身份：如果 MCP 服务器提供敏感工具或访问私有数据，则必须实施强大的身份验证机制来验证客户端（你的 CrewAI 应用程序）的身份。这可能涉及 API 密钥、OAuth 令牌或其他标准方法。
- 最小权限原则：确保
MCPServerAdapter使用的凭据（如果有）仅具有访问所需工具的必要权限。
d. 输入验证和清理
- 输入验证至关重要：MCP 服务器必须在处理从智能体接收到的所有输入或将其传递给工具之前，对其进行严格验证。这是防范许多常见漏洞的主要手段：
- 命令注入： 如果工具根据输入构建 shell 命令、SQL 查询或其他解释型语言语句，服务器必须仔细清理这些输入，以防止注入恶意命令并被执行。
- 路径遍历： 如果工具根据输入参数访问文件，服务器必须验证并清理这些路径，以防止访问未经授权的文件或目录（例如通过拦截
../序列）。 - 数据类型和范围检查： 服务器必须确保输入数据符合预期的数据类型（如字符串、数字、布尔值），并落在可接受的范围内或符合定义的格式（如 URL 的正则匹配）。
- JSON 模式验证： 所有工具参数应根据其定义的 JSON 模式进行严格验证。这有助于及早发现格式错误的请求。
- 客户端感知：虽然服务器端验证至关重要，但作为 CrewAI 用户，请留意你的智能体被配置发送给 MCP 工具的数据，特别是在与不太受信任或新的 MCP 服务器交互时。
e. 速率限制和资源管理
- 防范滥用：MCP 服务器应实施速率限制以防范滥用，无论是故意的（拒绝服务攻击）还是非故意的（例如配置错误的智能体发起了过多请求）。
- 客户端重试：如果预计会出现暂时的网络问题或服务器速率限制，请在 CrewAI 任务中实施合理的重试逻辑，但要避免激进的重试，以免加重服务器负担。
4. 安全 MCP 服务器实施建议（针对开发者）
如果你正在开发 CrewAI 智能体可能连接的 MCP 服务器，除了上述几点，请考虑以下最佳实践：- 遵循安全编码实践：坚持为你选择的语言和框架应用标准的安全编码原则（例如 OWASP Top 10）。
- 最小权限原则：确保运行 MCP 服务器的进程（特别是针对
Stdio）仅具有所需的最低限度权限。工具本身也应以执行其功能所需的最小权限运行。 - 依赖管理：保持所有服务器端依赖项（包括操作系统软件包、语言运行时和第三方库）处于最新状态，以修补已知漏洞。使用工具扫描易受攻击的依赖项。
- 安全默认设置：设计服务器及其工具时，默认配置应是安全的。例如，可能有风险的功能应默认关闭，或者需要通过明确的选择（opt-in）并附带清晰的警告才能开启。
- 工具访问控制：实施稳健的机制来控制哪些经过身份验证和授权的智能体或用户可以访问特定工具，特别是那些功能强大、敏感或会产生费用的工具。
- 安全错误处理：服务器不应向客户端公开详细的内部错误消息、堆栈跟踪或调试信息，因为这些信息可能会泄露内部机制或潜在漏洞。应在服务器端对错误进行全面记录以进行诊断。
- 全面的日志记录和监控：实施对安全相关事件（如认证尝试、工具调用、错误、授权变更）的详细记录。监控这些日志以发现可疑活动或滥用模式。
- 遵守 MCP 授权规范：如果实施身份验证和授权，请严格遵循 MCP 授权规范 和相关的 OAuth 2.0 安全最佳实践。
- 定期安全审计：如果你的 MCP 服务器处理敏感数据、执行关键操作或向公众开放，请考虑由合格的专业人员进行定期安全审计。