大家读完觉得有帮助记得关注和点赞!!!
摘要
传统的集中式安全工具常常漏掉自适应的、多向量的攻击。我们提出了多智能体LLM网络防御框架(MALCDF),这是一个实用的设置,其中四个大语言模型(LLM)智能体——检测、情报、响应和分析——实时协同工作。智能体通过安全通信层(SCL)进行通信,使用加密的、本体对齐的消息,并生成便于审计的输出(例如,MITRE ATT&CK映射)。
为了评估,我们保持测试简单且一致:所有报告的指标均来自基于CICIDS2017 [cicids2007] 特征模式生成的同一50条记录的实时流。CICIDS2017用于配置(字段/模式)并训练一个实用的ML基线。ML-IDS基线是一个轻量级随机森林IDS(LRF-IDS),在CICIDS2017的一个子集上训练,并在50条记录流上进行测试,训练和测试记录之间没有重叠。
在实验中,MALCDF达到了90.0%的检测准确率,85.7%的F1分数,以及9.1%的误报率,平均每事件延迟为6.8秒。它在准确率上优于轻量级ML-IDS基线和单LLM设置,同时保持了端到端输出的一致性。总体而言,这个实践性的构建表明,通过安全、本体对齐的消息传递来协调简单的LLM智能体,可以改进实用的实时网络防御。
关键词: 多智能体系统;大语言模型;网络防御;威胁情报。
1 引言
现代网络发展迅速且变化多端。在这个领域,传统的集中式安全工具难以应对那些在事件过程中可能改变行为的自适应、多向量攻击。攻击者现在使用AI、自动化甚至生成式技术来产生多态恶意软件、利用零日漏洞并协调大规模攻击活动 [Loevenich2025AutonomousCD]。随着更多工作负载转移到云、物联网和边缘,攻击面不断扩大,简单的签名或固定规则已不够用。实时防御需要能够理解上下文并快速做出协调决策的系统。
像防病毒软件或静态防火墙这样的反应式工具在已知指标上表现良好,但它们常常漏掉那些变形或隐藏在正常流量中的攻击。经典的ML检测器(异常和监督模型)在数据集过时或缺乏上下文时也会遇到瓶颈,导致误报和嘈杂的警报分类 [He2025LLM-MAS-SoftwareEng]。集中式设计也难以跟上高速环境的需求。我们需要一种能够实时工作并能在组件间协作的系统。
我们提出了多智能体LLM网络防御框架(MALCDF),这是一种分布式设置,其中多个大语言模型(LLM)智能体协同工作,以实时检测、分析和缓解威胁。图1展示了高层布局。该框架遵循SOC风格的设计,包含四个角色:威胁检测智能体(TDA)、威胁情报智能体(TIA)、响应协调智能体(RCA)和分析师智能体(AA)。这些智能体通过安全通信层(SCL)共享信息,该层确保消息加密、与通用本体对齐且语义一致。这有助于智能体共同推理,减少混淆,并保护操作数据免受窃听或冒充。
一个简单的例子有助于理解。在我们的测试中,检测智能体标记了一个在端口18530上的高字节率UDP传输,看起来像是数据渗出。情报智能体将目的地与一个已知的活动关联起来,响应智能体建议进行遏制和出站阻断。分析师智能体编写了一份带有MITRE ATT&CK映射的简短报告,使得该事件易于后续审查。这正是我们在实践中期望的端到端工作流程。
我们的实现为每个智能体使用Groq的LLaMA 3.3 70B模型,一个用于消息传递的JADE [jade] 风格编排层,以及一个用于端到端运行系统的Streamlit仪表板。我们使用源自CICIDS的字段(特征模式和示例模式)来配置智能体,因此输出是结构化的且与本体对齐,然后我们在源自同一模式的独立50条记录实时流上评估整个流水线。这50条测试记录不用于提示设计或基线训练。在实验中,MALCDF达到了90.0%的准确率和85.7%的F1分数,误报率为9.1%,平均每事件延迟为6.8秒。与一个实用的ML基线(LRF-IDS,在CICIDS子集上训练并在50条记录上测试)和一个单LLM设置相比,MALCDF提高了检测准确率。
MALCDF架构图
贡献
本工作侧重于LLM之间实用的多智能体协作,以实现实时网络防御。我们围绕三个目标和指导性问题组织这项研究:
-
设计一个多智能体架构,使LLM能够为实时网络防御自主协调。
-
多个LLM智能体如何协作以实时检测、分析和缓解网络威胁?
-
-
为智能体间的知识交换开发安全、本体对齐的通信协议。
-
模拟和评估不同攻击场景下的检测准确率和系统行为。
-
与单模型系统相比,多智能体协作是否能提高检测准确率和适应性?
-
2 背景与文献综述
2.1 当前网络防御格局
现代攻击具有自适应性且通常是多向量的,这使得传统工具(防病毒软件、基于签名的IDS、固定防火墙)在应对智能威胁行为者时效果较差。当攻击者可以在事件中途改变行为时,静态方法就会遇到困难。为了提高覆盖率,研究人员已使用AI和ML来构建用于实时检测、分类和响应的系统。常见的基于ML的IDS方法包括用于已知模式的SVM、决策树和随机森林,以及用于新颖异常的K-Means、隔离森林和自动编码器 [Aminu2024AdaptiveDefense]。像CNN和RNN这样的深度模型有助于处理复杂网络数据中的特征提取,但许多部署仍然依赖于静态数据集(KDD Cup 1999, UNSW-NB15, CICIDS 2017),这些数据集无法捕捉快速变化的行为。这会导致概念漂移和上下文缺失,进而引发误报和反应迟缓 [Kholidy2021CPSMitigation]。SIEM、IDS和IPS平台也往往很僵化,因此难以应对零日威胁。为了反映人类SOC团队适应和协作的方式,未来的系统需要更加分布式、协作化,并能够实时调整。
2.2 网络安全中的多智能体系统
多智能体系统(MAS)提供了一种分布式的方法来检测、缓解和评估威胁。独立的智能体可以在部分信息的情况下进行通信和决策,从而提高了可扩展性、鲁棒性和容错性 [Ko2020CyberAutonomy]。这在大型混合环境(物联网、云数据中心)中很重要,因为即使某些节点出现故障,系统也必须持续工作。像JADE和SPADE [spade_readme_latest] 这样的框架使得在网络安全设置中建模智能体行为和消息传递变得更加容易。
在实践中,一个JADE智能体可能监控服务器和端点,并分享有关异常峰值警报,而基于Python的SPADE智能体则与AI模型集成,用于异步的、消息驱动的保护。先前的工作表明,MAS原型在检测准确率和鲁棒性上可以胜过单智能体系统,因为它们分布了角色并共享了能揭示更大攻击模式的局部异常信号 [Amro2023AutonomousShipsDefense]。例如,一个智能体可能标记出UDP流量的突发,而相邻的智能体将其与到可疑主机的出站流量相关联。
MAS的主要优势包括:
-
去中心化: 消除了集中式模型中的单点故障,有助于防御命令与控制接管攻击。
-
可扩展性: 随着网络增长添加新智能体,以适应不断变化的基础设施 [Tanikonda2022ProactiveAI]。
-
动态协作: 根据反馈和对等消息调整行为,以应对新出现的威胁。
-
并行处理: 跨层和流同时操作,以保持分析接近实时。
与此同时,传统的安全MAS存在局限性。基于规则的逻辑、浅层学习和受限的本体降低了对新攻击的适应性 [Mintoo2022NationalResilience]。没有更强的语义理解,智能体可能会误读复杂或上下文丰富的事件。同步和安全消息传递会增加开销,从而损害实时响应能力。虽然增加深度学习和强化学习可以提高适应性,但许多系统仍然缺乏解释多阶段威胁并采取行动所需的情境推理水平。这就是LLM可以发挥作用的地方:它们为MAS带来了自然语言理解和语义推理能力,从而支持情境感知协作。
2.3 安全应用中的LLM
像GPT-5、GPT-4、LLaMA-3、Claude和PaLM-2这样的大语言模型(LLM)通过在处理文本和日志时增加更好的上下文和类人理解,改进了我们处理安全数据的方式。它们可以读取非结构化来源——安全日志、威胁情报源、技术报告,甚至是暗网帖子——并将其转化为可操作的见解,用于自适应防御 [Falowo2024ImmuneSystems]。在SOC工作流中,LLM有助于决策支持、漏洞分类、事件报告和日志关联。
一个常见的用途是威胁情报:LLM可以将来自报告和CVE源的指标(IP、哈希值、域名)与正在进行的活动关联起来,减少人工工作量 [Zahid2024MultiAgentAI]。它们还连接结构化和非结构化数据——例如,通过上下文将企业日志中的恶意软件签名映射到地下论坛中看到的域名。LLM可以通过读取自然语言日志、指出异常并解释模式为何可疑来支持SIEM。它们通常能从少量示例中泛化,这在快速变化的环境中有帮助。在代码安全中,像Code-LLaMA和Codex这样的模型可以发现不安全模式、建议修复方法并概述潜在的利用路径 [Cruz2024MASOrganizations]。通过将漏洞警告与受影响的组件联系起来,这加快了DevSecOps的速度。
也存在挑战。LLM可能是不透明的“黑盒”,这使得可解释性和信任更加困难。像推理链提取和注意力可视化这样的技术有所帮助,但它们并不完善。幻觉可能错误标记恶意IP或漏洞,并导致中断 [Raza2025TRISM]。实时使用还面临GPU和延迟限制。最后,集成敏感数据会引入隐私和安全风险(例如,数据泄漏或提示注入)。更安全的部署需要模型水印、沙箱化和持续验证。
2.4 已识别的研究空白
尽管有这些进展,大多数基于LLM的安全解决方案都是作为单一模型部署的。它们扫描漏洞、分类恶意软件或检测网络钓鱼,但它们通常单独工作,缺乏支持模型间通信和集体推理的框架。在面对跨越分布式环境的多阶段攻击时,这就产生了空白。真实世界的入侵通常遵循链条——侦察、权限提升、横向移动和数据渗出——因此防御应该是集成的并实时协调。
当前的LLM设置很少共享通用的协议、推理结构或控制策略来交换知识、验证发现并决定响应。另一个问题是缺乏用于描述威胁的统一语义层或共享本体。一个模型可能将一个事件称为“恶意软件信标”,另一个则称为“命令与控制”。如果没有对齐,重要的情报就会被误读。安全的LLM到LLM链接在许多设计中也缺失(认证、加密、信任),这为冒充、泄漏或虚假信息打开了大门。
为了弥补这些空白,我们转向协作式、多智能体LLM生态系统。在这些系统中,具有网络安全技能的LLM共享上下文、协商决策并相互学习。一个编排器或元控制器可以监控响应、分配任务并检查通信完整性。协调机制(例如,奖励式反馈或简单的冲突解决规则)有助于减少重叠并加快达成一致。通过实时消息传递和分布式推理,目标是模仿人类分析师的协作方式,但具有自主AI系统的速度和规模。
评估范围。 在这项工作中,我们保持评估的实用性和端到端性:所有实验都在一个源自CICIDS特征模式的小型50条记录流上运行,并且我们与两个符合操作约束的基线进行比较:一个轻量级随机森林IDS(LRF-IDS)和一个单LLM防御(一个处理检测和响应的智能体)。这一选择强调流水线行为,而不是在大型数据集上进行静态的、完全优化的ML/DL训练。MALCDF框架提供了多智能体协调所需的安全API和结构化通信层,因此智能体可以共享观察结果、将威胁情境化并实时规划自适应响应。
3 方法论
本节解释了我们如何构建和测试多智能体LLM网络防御框架(MALCDF)。该框架遵循安全运营中心(SOC)风格的布局,让多个智能智能体协同工作,以实时检测、分析和响应威胁。我们创建了一个工作原型,使用Groq的LLaMA 3.3 70B模型(通过Groq API),以及用于实时模拟和批量分析的工具。
3.1 数据集与实验设置
我们使用一个实用的测试源进行所有端到端实验和指标计算:一个源自CICIDS2017特征模式的50条记录实时流。该流旨在与第4节相同的条件下测试完整流水线(智能体、安全消息传递和仪表板)。它包含17条攻击记录和33条良性记录(见第4节表I),并且与任何更大的静态数据集分割是分开的。
CICIDS2017用于配置和基线训练。 CICIDS2017(约283万个样本,78个特征)提供了特征模式和代表性示例(例如,DDoS、端口扫描、暴力破解、数据渗出)。我们删除了重复/不完整的行并对特征进行了归一化,以设置一致的智能体输入。
智能体配置(无测试泄漏)。 我们使用源自CICIDS的字段来配置提示和本体映射,以便智能体一致地产生结构化输出。这50条测试记录不用于提示设计、调整或示例选择。一个小的、独立的配置集(与50条测试记录不同)用于提示工程、少量示例、验证JSON模式和消息格式化。
基线训练(LRF-IDS,无测试泄漏)。 ML基线是一个轻量级随机森林IDS(LRF-IDS),在CICIDS2017的一个子集上训练,以在操作(非优化)设置下学习决策边界。这个训练子集排除了我们50条记录测试流中的所有记录。所有基线评估指标都是在用于MALCDF的同一50条记录流上计算的,而不是在CICIDS2017上。
原型在Python 3.8+中实现,使用Streamlit作为前端,Groq的API用于LLM推理。Pandas和NumPy处理预处理和特征工程;Plotly提供交互式可视化。一个JADE风格的智能体编排层管理消息传递。所有测试都在稳定的网络条件和充足的计算资源下运行;Groq推理路径通常每个分析周期在几秒钟内响应。
3.2 训练与适应
MALCDF使用四个与常见SOC角色对齐的智能体:威胁检测智能体(TDA)、威胁情报智能体(TIA)、响应协调智能体(RCA)和分析师智能体(AA)。每个智能体使用相同的基础LLaMA 3.3 70B模型。
我们不改变基础权重。相反,智能体通过结构化提示和模式对齐的输出进行适应,并使用简单的共识进行协调。TDA使用源自CICIDS的字段对事件进行分类并发出结构化记录。TIA添加上下文(例如,已知指标或公共技术参考)并将术语与共享本体对齐。RCA基于综合视图提出实际步骤(遏制、阻断、检查)。AA生成映射到MITRE ATT&CK框架的简短事件报告,以便后续审查。响应以JSON格式交换,因此解析和仪表板集成保持一致。
图2展示了整体流程:数据通过可视化/摄取层输入;智能体通过安全通信层(SCL)进行协调,该层保持消息加密和本体对齐;一个简单的协调器倾向于共识,以避免重复工作或冲突行动。

MALCDF框架架构图
3.3 评估指标
我们报告标准检测指标和一个时序指标,所有指标均在同一个50条记录流上计算:
-
准确率: 正确标记的记录(良性和攻击)所占的比例。
-
F1分数: 精确率和召回率的调和平均数。
-
误报率(FPR): FP / (FP + TN),即被标记为攻击的良性记录比例。
-
延迟(每事件): 处理一条记录的平均端到端时间,包括SCL加密和共识步骤。
-
置信度分数(平均): 共识后每个事件的智能体级平均置信度(范围 [0, 1])。
我们还记录基本的系统统计信息(例如,模型推理时间和令牌使用情况),以了解成本和开销。后续的专家评审会检查智能体报告的易读性和技术合理性,但这里的主要重点是测量流水线行为。
3.4 基线比较
为了与第4节保持一致并保持比较清晰,我们在同一50条记录流上评估两个基线:
-
ML-IDS(轻量级随机森林IDS,LRF-IDS): 我们在轻量级操作设置下筛选了常见的ML-IDS选项(随机森林、CNN、RNN),发现随机森林对于这个小型的混合流最稳定。因此,我们使用LRF-IDS作为实用的ML基线。LRF-IDS在CICIDS2017的一个子集上(仅训练)训练,并在与MALCDF相同的50条记录流上(仅测试)进行评估。
-
单LLM防御: 一个LLM智能体处理检测和响应,没有多智能体协调(无共享本体或共识)。
两个基线都进行端到端测试,以匹配MALCDF的条件(安全消息传递在适用时开启/关闭,相同的输入和相同的报告)。
3.5 实现工作流与系统操作
MALCDF支持三种模式:
-
实时模拟: 一个小的合成流馈送给TDA。当出现异常情况时(例如,到非标准端口的异常出站UDP),TIA添加上下文,RCA建议一个计划(遏制或阻断),AA记录该事件并附带ATT&CK映射。
-
批量分析: CSV上传允许用户使用相同的智能体流对历史日志进行顺序检查。
-
数据集上传: 归一化、带标签的数据(例如,CICIDS格式的子集)可以被加载用于受控测试和可重复性(仅配置;报告的指标来自50条记录流)。
SCL处理基于API的安全加密和本体对齐,以便智能体保持一致。我们包含简单的错误恢复(当外部调用失败时自动重试和回退规则传递),以便流水线持续运行。为了隐私,用户数据保留在本地,只有决策所需的推理输入/输出被发送到LLM API;系统不保存敏感记录的持久存储。
总体而言,快速推理、灵活的智能体布局和交互式仪表板的结合,使得将LLM模型连接到实用的、可解释的网络安全工作流变得简单直接。该原型具有可重复性,并可扩展到小型团队设置,这是大型SOC部署之前典型的起点。
4 结果与分析
4.1 实验结果概述
我们使用一个50条记录的实时流(源自CICIDS2017特征模式)对MALCDF进行了端到端测试,以在安全通信层(SCL)下运行完整流水线。智能体(TDA, TIA, RCA, AA)交换了本体对齐的、加密的消息,并产生了结构化输出。目标是测量所有组件开启时的实际行为(准确率、F1、误报和每事件延迟)。该流包含17条攻击记录和33条良性记录(见表I)。
基线说明。 ML-IDS基线指一个轻量级随机森林IDS(LRF-IDS),在CICIDS2017的一个子集上训练,并仅在相同的50条记录流上测试,训练和测试记录之间没有重叠。这保持了比较的公平性并避免了泄漏。
表I:基线模型与提出的MALCDF框架的威胁检测性能比较摘要
|
指标 |
MALCDF(提出的框架) |
ML-IDS(基线) |
单LLM防御 |
|---|---|---|---|
|
分析记录总数 |
50 |
50 |
50 |
|
真实攻击记录数 |
17 |
17 |
17 |
|
真正例(TP) |
15 |
12 |
10 |
|
假反例(FN) |
2 |
5 |
7 |
|
假正例(FP) |
3 |
6 |
4 |
|
真反例(TN) |
30 |
28 |
29 |
|
检测准确率 |
90.0% |
80.0% |
78.0% |
|
精确率(TP / (TP + FP)) |
83.33% |
70.6% |
71.4% |
|
召回率(TP / (TP + FN)) |
88.24% |
70.6% |
58.8% |
|
F1分数 |
85.7% |
70.6% |
64.4% |
|
误报率(FPR) |
9.1% |
15.2% |
10.8% |
|
置信度分数(平均) |
0.70 |
0.64 |
0.66 |
|
响应延迟(平均) |
6.8 s |
3.1 s |
5.7 s |
如表I所示,MALCDF在50条记录流上达到了90.0%的准确率和85.7%的F1分数,FPR为9.1%,平均每事件延迟为6.8秒。与基线相比,MALCDF的准确率比ML-IDS(80.0%)提高了+10.0个百分点,比单LLM设置(78.0%)提高了+12.0个百分点。FPR低于两个基线(9.1% vs. 15.2% 和 10.8%)。延迟高于单LLM(5.7秒)和ML-IDS(6.1秒),这是由于SCL加密和共识步骤所致,但对于实时审查来说是可以接受的。
4.2 威胁检测分布
在50条记录中,MALCDF将15个事件标记为攻击:8个中等严重性,5个低等严重性,2个高等严重性。数据渗出是最常见的(约占检测的60%),其次是恶意软件信标(25%)和未经授权的访问尝试(15%)。图3显示了所有样本的威胁严重性分布,表II列出了带有MITRE ATT&CK映射的样本事件。置信度值平均为0.70,来自智能体共识(无阈值调整),这有助于保持术语和报告的一致性。
表II:详细的AI检测事件
|
事件ID |
威胁类型 |
严重性 |
置信度 |
源IP |
目的IP |
端口 |
协议 |
发送字节数 |
MITRE技术 |
|---|---|---|---|---|---|---|---|---|---|
|
2 |
数据渗出 |
中等 |
0.70 |
192.168.1.199 |
10.0.0.57 |
18530 |
UDP |
162,548 |
T1041 |
|
5 |
数据渗出 |
中等 |
0.70 |
192.168.1.231 |
10.0.0.177 |
11355 |
HTTP |
98,426 |
T1041 |
|
7 |
数据渗出 |
中等 |
0.70 |
192.168.1.125 |
10.0.0.114 |
1828 |
UDP |
119,833 |
T1041 |
威胁严重性分布
4.3 威胁分析
为了说明工作流程,考虑事件ID 2:检测智能体标记了一个到10.0.0.57端口18530的高字节率UDP传输。情报智能体将目的地与先前的渗出活动联系起来。响应智能体建议进行遏制和出站阻断。分析师智能体使用ATT&CK技术T1041记录了该案例。这个序列展示了智能体如何从原始信号转变为实际行动和简短报告。
4.4 与基线模型的比较评估
在相同的50条记录流上与基线相比,MALCDF的检测准确率比ML-IDS提高了+10.0个百分点,比单LLM设置提高了+12.0个百分点(表I)。FPR比ML-IDS降低了6.1个百分点(15.2% → 9.1%),比单LLM降低了1.7个百分点(10.8% → 9.1%)。延迟比单LLM高+1.1秒,比ML-IDS高+3.7秒。这种开销来自安全消息传递和共识,考虑到准确性和一致性的提升,我们认为这是可以接受的。
4.5 可解释性与专家验证
专家评审发现智能体报告清晰且技术上合理,特别是当事件包含ATT&CK映射和具体字段(端口、字节、IP)时。总体而言,端到端运行表明,多智能体协调可以提高实际检测质量,同时为分析师保持简单的审查流程。
5 讨论
我们的测试显示了检测质量与协调成本之间的明显权衡。使用多个基于LLM的智能体(检测、情报、响应和分析)改善了从原始信号到实际行动的决策流程,但安全消息传递和达成一致的步骤增加了开销。安全通信层(SCL)保持智能体间消息的私密性并与共享本体对齐,这有助于一致性,但每条消息在使用前都经过检查和加密,这增加了时间 [Rani2025AURA]。在整个测试使用的同一50条记录流上,MALCDF达到了90.0%的准确率和85.7%的F1分数,FPR为9.1%,平均每事件延迟6.8秒。这高于单LLM(5.7秒)和远高于轻量级ML-IDS(3.1秒),但准确率的提升和更一致的输出有助于分析师审查。
操作协调与延迟。 在实践中,SCL增加了可预测的步骤:加密、与共享本体对齐、确认共识。这些检查解释了与单LLM和简单ML-IDS相比的延迟差距,但它们也减少了智能体之间的混淆,并使报告更易于审计。在运行中,共识使平均置信度保持在0.70左右,这与检测结果的记录和ATT&CK映射方式相匹配。对于日常使用,这种权衡是可以接受的,因为它使审查更简单(清晰的字段如端口、字节和IP),同时仍能捕获隐蔽的出站模式。
计算、同步与扩展。 运行多个智能体比单个模型更重,因为每个智能体都使用自己的推理路径,并且必须与共享术语保持同步。在高吞吐量或密集事件下,同步可能会减慢速度 [Mukherjee2024AgentSmith]。一个实用的扩展方法是将智能体分布到不同的节点或容器中,并让编排器根据工作负载或优先级增加副本。
跨攻击向量的适应性。 在测试流中,MALCDF通过结合信号(检测)、上下文(情报)和响应智能体的简单计划(遏制或阻断),处理了非标准端口和协议上的渗出模式。协调步骤有助于系统适应多态的或不断演变的行为 [Nunez2024AutoSafeCoder]。这在存在勒索软件、内部人员数据移动和网络钓鱼(在云、物联网和边缘开辟访问路径)的环境中非常重要。
安全与计算考量。 LLM驱动的多智能体防御引入了伦理和安全问题。幻觉可能错误标记指标;提示注入可能试图引导响应;敏感数据需要保护。为了降低风险,我们使用分层验证(智能体相互检查输出)、记录决策轨迹以供审计,并保持通信加密(AES/TLS)和严格的访问控制,以符合

被折叠的 条评论
为什么被折叠?



