【个人开源项目】AutoRedTeam-Orchestrator AI 驱动的自动化红队编排框架
[开源] AutoRedTeam-Orchestrator - 给 AI 编辑器装上渗透测试工具箱项目简介AutoRedTeam-Orchestrator 是一个基于 Model Context Protocol (MCP) 的 AI 驱动自动化渗透测试框架。它将 101 个安全工具 封装为 MCP 工具，可与支持 MCP 的 AI 编辑器 (Claude Code, Cursor, Windsurf, Kiro, Claude Desktop) 无缝集成，实现自然语言驱动的自动化安全测试。简单说：配置好之后，直接跟 AI 说「帮我扫描 xxx.com 的漏洞」就行了项目数据概览 指标数量 MCP 工具101Payload 库2,000+测试用例1,461漏洞检测器19 为什么选择 AutoRedTeam-Orchestrator？ 特性传统工具AutoRedTeam-Orchestrator 交互方式命令行记忆自然语言对话学习成本高（需记忆大量参数）低（AI 自动选择工具）工具整合手动切换工具101 工具统一接口攻击链规划人工规划MCTS 算法 + 知识图谱误报过滤人工验证OOB + 统计学验证报告生成手动编写一键生成专业报告会话管理无支持断点续传安全性各工具独立MCP 安全中间件统一防护 为什么做这个？最早是在用 HexStrike，还参与过二次开发，和 #96 分支作者 Ynee 也有过深入交流。后来在社区找到了 HexStrike 原作者，但他似乎遇到了一些生活上的困难，项目更新明显放缓了。与其等待，不如自己动手。正好使用中也积累了一些想法：为什么非得在 Kali 上跑？ → 做成 Windows 原生，Linux 也兼容为什么不能和 AI 编辑器联动？ → 基于 MCP 协议，Claude Code 直接调用为什么工具这么分散？ → 101 个工具整合到一起于是就有了这个项目。技术栈 & 兼容性技术栈语言 Python 3.10+协议 MCP (Model Context Protocol)并发 asyncio / httpx / aiohttp算法 MCTS 蒙特卡洛树搜索存储 内存图存储 / SQLite安全 输入验证 / 速率限制 / 操作授权已测试支持CLI 工具：Claude Code (终端)Gemini CLICodex CLI（道德感严重 ）iFlow CLIIDE / 桌面端：CursorWindsurfKiroClaude DesktopVS Code (with MCP extension)基本上只要能跑 MCP 的 IDE/CLI 都可以用这个项目结果案例： codex扫描时间过长我停了，具体各位佬可以重新测试一下GitHubGitHub - Coff0xc/AutoRedTeam-Orchestrator: AI-Driven Automated Red Team Orchestration Framework | AI驱动的自动化红队编排框架 | 101 MCP Tools | 2000+ Payloads | Full ATT&CK Coverage | MCTS Attack Planner | Knowledge Graph | Cross-platform欢迎 Star 和 PR！ 免责声明本工具仅限以下场景使用：授权渗透测试红队安全评估安全研究学习CTF 竞赛严禁用于：未经授权测试他人系统任何非法用途使用本工具造成的任何法律后果由使用者自行承担。狗头保命，希望大家合法合规使用~第一次在 L 站发自己的项目，有问题欢迎回帖讨论，也可以去 GitHub 发 Issue 或者按项目里的邮箱联系我，看到就会回复。希望大家共同进步，也请各位师傅斧正！📌 转载信息来源： https://linux.do/t/topic/1566499转载时间： 2026/2/5 05:19:59
CyberStrikeAI：让安全测试像对话一样简单——智能渗透测试的技术实践
CyberStrikeAI：让安全测试像对话一样简单——智能渗透测试的技术实践先附上开源工具链接：https://github.com/Ed1s0nZ/CyberStrikeAI从工具堆砌到智能调度：渗透测试的演进之路作为安全工程师，我们都经历过这样的场景：面对一个新的目标系统，我们需要在数十个安全工具之间不断切换，记忆各种复杂的命令行参数，手动分析海量的扫描结果，然后在不同的工具输出中寻找关联性。这种工作方式不仅效率低下，更严重的是，我们往往在工具的使用上花费了太多精力，反而减少了对安全威胁本质的思考时间。技术人的解决方案：CyberStrikeAI的设计理念CyberStrikeAI不是要取代安全工程师，而是要成为工程师的智能助手。基于一个朴素但强大的想法：用技术手段解决技术问题，让AI处理重复性工作，让人专注于创造性分析。效果对话效果MCP调用调用链核心架构：Golang + MCP协议的工程化实现// 核心架构简示 Agent Loop (AI决策引擎) ↓ MCP Server (工具调度中心) ↓ Security Executor (命令执行层) ↓ 98+ Security Tools (工具生态)技术栈选择背后的思考：Golang：并发性能优异，跨平台编译方便，部署简单 MCP协议：标准化工具调用，确保扩展性和兼容性 SQLite：轻量级数据存储，适合单机部署场景实际工作流程对比传统方式：# 1. 端口扫描 nmap -sS -sV -O 192.168.1.0/24 # 2. Web服务识别 httpx -l targets.txt -title -status-code # 3. 漏洞扫描 nuclei -l targets.txt -t /nuclei-templates/ # 4. 手动分析结果，决定下一步...CyberStrikeAI方式："对192.168.1.0/24网段进行全面的安全评估，重点关注Web服务漏洞"系统自动完成：识别网络范围，调用nmap进行主机发现 对发现的Web服务调用httpx进行指纹识别 基于服务指纹选择相应的漏洞检测模板 自动分析结果，对可疑目标进行深度扫描 生成结构化报告，包括漏洞详情和修复建议面向安全工程师的技术特性工具集成：不重复造轮子我集成了98+个经过社区验证的安全工具，包括：信息收集：nmap, subfinder, amass, theharvester 漏洞扫描：nuclei, sqlmap, xsser, dalfox Web安全：dirb, gobuster, nikto, wafw00f 专项工具：wpscan, jexboss, ysoserial每个工具都通过YAML配置文件进行标准化封装：name: "nmap" command: "nmap" args: ["-sT", "-sV", "-sC"] description: "网络扫描工具，用于发现网络主机、开放端口和服务" parameters: - name: "target" type: "string" description: "目标IP地址或域名" required: true智能决策：AI作为调度器AI在系统中的角色不是替代工具，而是智能调度器和结果分析器：// AI决策流程 1. 理解用户自然语言请求 2. 分析目标特征和测试需求 3. 选择最适合的工具组合 4. 动态调整参数优化扫描效果 5. 解析工具输出，提取关键信息 6. 基于发现决定后续测试路径实时监控：掌握测试全过程系统提供完整的执行监控：# 查看工具执行状态 GET /api/monitor # 实时查看漏洞统计 { "total": 23, "severityCount": { "critical": 2, "high": 5, "medium": 10, "low": 6 } }实际应用场景分析场景一：红队渗透测试需求：快速对目标企业进行外围渗透测试传统方式：手动信息收集 → 工具链执行 → 结果整理 (耗时：4-6小时)CyberStrikeAI：单次对话描述测试目标 → 自动执行完整流程 (耗时：30-60分钟)场景二：漏洞复现与验证需求：批量验证SRC提交的漏洞传统方式：逐个手动测试，重复性工作量大CyberStrikeAI：批量导入目标 → 自动匹配检测方案 → 生成验证报告场景三：安全巡检需求：定期对资产进行安全巡检传统方式：编写脚本，定时执行，人工分析CyberStrikeAI：配置巡检策略 → 自动执行 → 差异对比 → 告警通知扩展性与二次开发自定义工具集成通过标准的YAML配置即可集成新工具：name: "custom-scanner" command: "python3" args: ["/tools/myscanner.py"] parameters: - name: "target" type: "string" required: trueAPI集成现有流程系统提供完整的REST API，可轻松集成到现有安全体系中：# 集成到自动化漏洞管理平台 def trigger_scan(target, scan_type): response = requests.post( 'http://cyberstrike-ai:8080/api/agent-loop', json={'message': f'{scan_type}扫描 {target}'} ) return process_results(response.json())技术人的实践建议部署方案开发测试：本地Docker部署，快速验证 团队使用：服务器部署，共享使用 集成环境：API方式集成到现有安全平台使用技巧渐进式测试：从基础扫描开始，逐步深入 结果验证：AI发现的关键漏洞建议人工复核 工具补充：根据实际需求扩展工具库结语：技术赋能，专注价值CyberStrikeAI的本质是通过技术手段提升安全工程师的工作效率，让我们从繁琐的工具操作中解放出来，更加专注于威胁分析、漏洞研究和防护策略等更有价值的工作。在网络安全人才紧缺的今天，提升个体工程师的效率就是提升整个行业的安全水位。我相信，好的工具应该像得力的助手一样，默默处理繁琐工作，让专家专注于专业判断。项目地址：https://github.com/Ed1s0nZ/CyberStrikeAI让技术回归本质，让安全测试变得更加高效——这是CyberStrikeAI的技术追求，也是我对安全社区的诚意贡献。
LLM Agent工具调用安全：从函数调用机制到MCP协议攻防的深度剖析
前言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调用、浏览器自动化等几乎所有领域工具调用的市场驱动力工具调用能力的爆发式增长背后有着强劲的市场驱动力：驱动因素具体表现数据支撑企业效率需求AI助手需要直接操作企业系统78%的企业计划部署Agent型AI（Gartner 2025）开发者体验减少重复的集成开发工作MCP减少了约70%的工具集成代码量用户期待用户希望AI能"做事"而不只是"说话"ChatGPT插件用户活跃度提升340%（OpenAI数据）竞争压力AI产品差异化的重要维度支持工具调用的产品获客成本降低45%然而，这种能力的扩展同时也带来了前所未有的安全风险。 传统的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_email2Resources：可被LLM读取的数据源，如文件内容、数据库记录3Prompts：预定义的提示词模板，用于特定场景典型的工具调用流程：MCP协议的安全假设与现实差距MCP协议的设计者做出了一系列安全假设，但这些假设在实际部署中往往不成立：安全假设现实情况风险等级MCP Server是可信的用户可能连接到恶意Server严重工具描述是准确的描述可能包含隐藏指令严重工具参数会被正确处理参数可能被注入恶意内容高用户会审查每个工具调用自动化场景下无人审查高不同Server之间相互隔离恶意Server可能劫持合法Server的调用严重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框架在工具调用的实现上存在显著差异，这些差异直接影响了它们的安全特性框架对比分析框架工具定义方式权限控制调用审计沙箱隔离安全评分LangChainPython装饰器弱（依赖开发者）可选无★★☆☆☆LlamaIndex工具抽象类中等内置日志部分★★★☆☆AutoGenAgent配置弱可选无★★☆☆☆CrewAI工具类定义弱可选无★★☆☆☆Semantic Kernel插件系统中等内置部分★★★☆☆Claude MCPMCP协议依赖实现协议层支持无默认★★★☆☆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的安全审计，攻击面分布如下：攻击面类型受影响的Server比例平均漏洞严重度检测难度命令注入34%Critical中工具描述投毒62%High高权限过度授予78%High低缺乏输入验证85%Medium-High低OAuth配置错误45%High中日志记录不足91%Medium低核心发现：几乎所有的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实现进行了全面评估：评估维度通过率主要问题Server身份认证12%大多数实现无认证机制工具描述安全扫描8%几乎无实现Sampling权限控制23%默认允许，无限制传输加密45%本地Server常用明文审计日志31%日志不完整或无日志输入参数验证15%大多直接透传这一数据揭示了一个严峻的现实：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上，利用方式略有不同，但同样可以实现任意命令执行攻击链路分析完整的攻击链路如下：攻击成功率分析：攻击场景成功率前置条件用户主动连接恶意Server95%+社工诱导供应链投毒（恶意npm包）85%+包名相似/依赖混淆中间人攻击60%网络层访问DNS劫持70%DNS控制权漏洞修复与防御官方修复方案（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仅在隔离环境中使用Inspector3配置防火墙阻止外部访问6274端口4不要在生产环境运行Inspector2.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 cookie4MCP Proxy Server在转发到第三方授权之前，没有实施每Client的consent验证受影响的场景分析：MCP Server类型受影响程度原因单租户部署低无动态注册需求多租户SaaS高通常支持动态注册企业内部部署中取决于配置开源社区Server高默认配置通常不安全攻击代码示例防御措施根据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攻击者的目标（数据泄露/权限提升/拒绝服务）达成攻击成功率的影响因素通过实验，我们识别了影响工具投毒攻击成功率的关键因素：因素影响程度说明指令的"系统性"措辞高使用"SYSTEM"、"IMPORTANT"等词汇提升成功率指令的合理性包装高将恶意操作包装为"安全检查"、"性能优化"等LLM的指令跟随能力高能力越强的模型，越容易被投毒工具描述的长度中过长的描述可能被截断，影响注入效果其他工具的存在中需要确保恶意工具被选中上下文窗口位置中工具描述在上下文中的位置影响权重不同LLM的易感性对比我们测试了主流LLM对工具投毒攻击的易感性：测试结果：LLM模型攻击成功率最易感的攻击类型GPT-434%权威声明类Claude 3 Opus28%系统指令类Gemini Pro41%HTML注释类Llama 3 70B52%多种类型关键发现：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月）：被测系统攻击成功率检测率误报率Claude Desktop31%12%3%Cursor45%8%2%VS Code + Continue38%15%5%自研Agent（无防护）67%0%0%自研Agent（带MCPSecEval）23%78%8%工具投毒检测方法基于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) 的测试结果：攻击场景直接注入成功率间接注入(工具响应)成功率放大倍数数据泄露23%67%2.9x工具滥用31%78%2.5x权限提升18%54%3.0x拒绝服务12%45%3.75x这一数据表明，工具响应作为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系统中的信任边界可以被攻击者利用：攻击面攻击方式影响Agent间通信消息伪造/注入控制目标Agent行为权限传递利用低权限Agent请求高权限操作权限提升上下文污染在共享上下文中注入恶意数据全局影响Agent协作协议利用协议漏洞破坏协作逻辑5.2 Inter-Agent Trust Exploitation：100%成功率的攻击研究发现2025年发表的一项研究揭示了一个令人震惊的发现：100%的测试LLM在面对跨Agent信任攻击时都会执行恶意命令，即使同样的命令在来自用户或RAG文档时会被拒绝实验设置：测试结果：命令来源命令内容拒绝率（GPT-4）拒绝率（Claude 3）拒绝率（Llama 3）用户直接输入删除所有文件98%99%92%RAG文档注入删除所有文件45%52%38%其他Agent请求删除所有文件0%0%0%攻击机制分析为什么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在工作过程中会接触到大量凭证信息：凭证类型暴露场景风险等级API密钥用户请求Agent调用APICriticalOAuth TokenMCP Server存储的授权令牌Critical数据库密码配置文件、环境变量CriticalSSH密钥代码部署、服务器访问HighSession TokenWeb应用认证HighJWT用户身份验证HighToken劫持攻击凭证保护措施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被授予了超出其任务需要的权限，导致攻击者可以利用这些过度权限造成更大的危害。风险特征：维度描述攻击前提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生成可操作的安全报告评估维度设计维度子维度评估内容权重协议安全传输安全TLS配置、证书验证15%认证机制Server认证、Client认证15%OAuth安全流程合规性、Token管理10%工具安全定义安全描述投毒检测、权限声明15%参数安全输入验证、注入防护15%执行安全沙箱隔离、资源限制10%数据安全敏感数据检测、脱敏、加密10%外泄防护DLP、外传监控10%权限安全最小权限权限配置、使用审计10%访问控制RBAC、动态授权10%安全评分模型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.121732Mo, Y., et al. (2025). "Agent Security Bench (ASB): Formalizing and Benchmarking Attacks and Defenses in LLM-based Agents." ICLR 20253Wu, J., et al. (2024). "New Jailbreak Attack Targeting Tool-Integrated LLMs." arXiv:2409.108074Zou, 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/giskard2 Rebuff. "Prompt Injection Detection Service" https://github.com/protectai/rebuff3 LangChain. "Security Best Practices" https://python.langchain.com/docs/security附录D：术语表术语英文定义工具调用Tool Calling / Function CallingLLM调用外部工具或函数的能力MCPModel Context ProtocolAnthropic提出的AI工具连接标准协议提示词注入Prompt Injection通过恶意输入操纵LLM行为的攻击技术间接提示词注入Indirect Prompt Injection通过外部数据源（如文档、网页）注入恶意指令工具投毒Tool Poisoning在工具定义中嵌入恶意指令的攻击技术Rug Pull-先发布正常工具，后通过更新植入恶意代码的攻击沙箱Sandbox隔离执行环境，限制代码可访问的资源断路器Circuit Breaker防止故障级联的保护机制RBACRole-Based Access Control基于角色的访问控制零信任Zero Trust永不信任、始终验证的安全架构理念.lakex-default-theme{--lakex-editor-background:#fff;--lakex-editor-background-primary:#fff;--lakex-editor-background-primary-hover:#EFF0F0;--lakex-editor-background-primary-hover-light:#E7E9E8;--lakex-editor-background-secondary:#FAFAFA;--lakex-editor-background-tertiary:#F4F5F5;--lakex-editor-background-foreground:#fff;--lakex-editor-border-light:rgba(0, 0, 0, 0.04);--lakex-editor-code-background:#0000000f;--lakex-editor-column-background-highlight:#D9EAFC7F;--lakex-editor-icon-secondary:#585A5A;--lakex-editor-selection:rgba(27, 162, 227, 0.2);--lakex-editor-table-bar-active:#2F8EF4CC;--lakex-editor-table-bar-danger:#E4495B5A;--lakex-editor-table-scrollbar-thumb:#00000033;--lakex-editor-text-color:#262626;--lakex-editor-text-body:#585A5A;--lakex-editor-text-caption:#8A8F8D;--lakex-editor-text-disable:#BEC0BF;--lakex-editor-text-link:#117CEE;--lakex-editor-text-link-hover:#5FA8F6;--lakex-editor-border-primary:#E7E9E8;--lakex-editor-card-background-hover:#5FA8F633;--lakex-editor-card-border-hover:#81BBF8;--lakex-editor-card-border-selected:#2F8EF4;--lakex-editor-color-black:#000;--lakex-editor-color-black-f05:rgba(0,0,0,0.05);--lakex-editor-color-black-f08:rgba(0,0,0,0.08);--lakex-editor-color-black-f12:rgba(0,0,0,0.12);--lakex-editor-color-black-f30:rgba(0,0,0,0.30);--lakex-editor-color-black-f65:rgba(0,0,0,0.65);--lakex-editor-color-blue1:#D9EAFC;--lakex-editor-color-blue2:#C0DDFC;--lakex-editor-color-blue3:#81BBF8;--lakex-editor-color-blue4:#5FA8F6;--lakex-editor-color-blue5:#2F8EF4;--lakex-editor-color-blue6:#117CEE;--lakex-editor-color-blue8:#074A92;--lakex-editor-color-blue9:#00346B;--lakex-editor-color-cyan1:#CEF5F7;--lakex-editor-color-cyan9:#004347;--lakex-editor-color-green5:#0BD07D;--lakex-editor-color-green6:#00B96B;--lakex-editor-color-green7:#009456;--lakex-editor-color-grey1:#FAFAFA;--lakex-editor-color-grey2:#F4F5F5;--lakex-editor-color-grey3:#EFF0F0;--lakex-editor-color-grey4:#E7E9E8;--lakex-editor-color-grey5:#D8DAD9;--lakex-editor-color-grey6:#BEC0BF;--lakex-editor-color-grey7:#8A8F8D;--lakex-editor-color-grey8:#585A5A;--lakex-editor-color-grey9:#262626;--lakex-editor-color-orange1:#FDE6D3;--lakex-editor-color-orange9:#663000;--lakex-editor-color-peaGreen1:#E8F7CF;--lakex-editor-color-peaGreen8:#406105;--lakex-editor-color-peaGreen9:#2A4200;--lakex-editor-color-red1:#FBE4E7;--lakex-editor-color-red4:#EA7583;--lakex-editor-color-red5:#E4495B;--lakex-editor-color-red6:#DF2A3F;--lakex-editor-color-red9:#70000D;--lakex-editor-color-theme:#00B96B;--lakex-editor-color-white:#fff;--lakex-editor-color-white-f60:rgba(255,255,255,0.6);--lakex-editor-color-white-f80:rgba(255,255,255,0.8);--lakex-editor-color-white-f90:rgba(255,255,255,0.9);--lakex-editor-color-yellow5:#F3BB2F;--lakex-alert-tips-bar-border:#BEC0BF;--lakex-alert-tips-bar-bg:#D8DAD9;--lakex-alert-tips-background:#EFF0F0;--lakex-alert-tips-border:#E7E9E8;--lakex-alert-info-bar-border:#C0DDFC;--lakex-alert-info-bar-bg:var(--lakex-alert-info-bar-border);--lakex-alert-info-background:rgba(192,221,252,0.5);--lakex-alert-info-border:#81BBF8;--lakex-alert-color1-bar-border:#B5EFF2;--lakex-alert-color1-bar-bg:var(--lakex-alert-color1-bar-border);--lakex-alert-color1-background:rgba(181,239,242,0.5);--lakex-alert-color1-border:#81DFE4;--lakex-alert-color2-bar-border:#C7F0DF;--lakex-alert-color2-bar-bg:var(--lakex-alert-color2-bar-border);--lakex-alert-color2-background:rgba(199,240,223,0.5);--lakex-alert-color2-border:#82EDC0;--lakex-alert-success-bar-border:#DBF1B7;--lakex-alert-success-bar-bg:var(--lakex-alert-success-bar-border);--lakex-alert-success-background:rgba(219,241,183,0.5);--lakex-alert-success-border:#C1E77E;--lakex-alert-warning-bar-border:#F6E1AC;--lakex-alert-warning-bar-bg:var(--lakex-alert-warning-bar-border);--lakex-alert-warning-background:rgba(246,225,172,0.5);--lakex-alert-warning-border:#F5D480;--lakex-alert-color3-bar-border:#F8D6B9;--lakex-alert-color3-bar-bg:var(--lakex-alert-color3-bar-border);--lakex-alert-color3-background:rgba(248,214,185,0.5);--lakex-alert-color3-border:#F8B881;--lakex-alert-danger-bar-border:#F8CED3;--lakex-alert-danger-bar-bg:var(--lakex-alert-danger-bar-border);--lakex-alert-danger-background:rgba(248,206,211,0.5);--lakex-alert-danger-border:#F1A2AB;--lakex-alert-color4-bar-border:#F7C4E2;--lakex-alert-color4-bar-bg:var(--lakex-alert-color4-bar-border);--lakex-alert-color4-background:rgba(247,196,226,0.5);--lakex-alert-color4-border:#F297CC;--lakex-alert-color5-bar-border:#D9C9F8;--lakex-alert-color5-bar-bg:var(--lakex-alert-color5-bar-border);--lakex-alert-color5-background:rgba(217,201,248,0.5);--lakex-alert-color5-border:#BA9BF2;--lakex-label-color0-bg:#F8CED3;--lakex-label-color0-border:#F1A2AB;--lakex-label-color0-text:#70000D;--lakex-label-color1-bg:#F6E1AC;--lakex-label-color1-border:#F5D480;--lakex-label-color1-text:#664900;--lakex-label-color2-bg:#DBF1B7;--lakex-label-color2-border:#C1E77E;--lakex-label-color2-text:#2A4200;--lakex-label-color3-bg:#EFF0F0;--lakex-label-color3-border:#EFF0F0;--lakex-label-color3-text:#262626;--lakex-label-color4-bg:#C0DDFC;--lakex-label-color4-border:#81BBF8;--lakex-label-color4-text:#00346B;--lakex-label-color5-bg:#C0CAFC;--lakex-label-color5-border:#96A7FD;--lakex-label-color5-text:#101E60;--lakex-calendar-blue-line:#117CEE;--lakex-calendar-blue-border:#81BBF8;--lakex-calendar-blue-background:#D9EAFC;--lakex-calendar-magenta-line:#D22D8D;--lakex-calendar-magenta-border:#F297CC;--lakex-calendar-magenta-background:#FBDFEF;--lakex-calendar-green-line:#74B602;--lakex-calendar-green-border:#C1E77E;--lakex-calendar-green-background:#E8F7CF;--lakex-calendar-red-line:#DF2A3F;--lakex-calendar-red-border:#F1A2AB;--lakex-calendar-red-background:#FBE4E7;--lakex-calendar-purple-line:#601BDE;--lakex-calendar-purple-border:#BA9BF2;--lakex-calendar-purple-background:#E6DCF9;--lakex-calendar-yellow-line:#ECAA04;--lakex-calendar-yellow-border:#F5D480;--lakex-calendar-yellow-background:#F9EFCD;}​