NVISOsecurity/cyber-security-llm-agents：用 LLM 代理重塑网络安全自动化

一家欧洲安全公司的"疯狂实验"

2024 年 2 月，比利时安全公司 NVISO Security 在 GitHub 上开源了一个性质"危险"的项目：让大语言模型（LLM）自主执行网络安全任务——从分析 EDR（终端检测与响应）日志，到自动化红队对抗模拟，甚至生成可能绕过杀软的代码。这不是概念验证（POC），而是已在 RSAC 2024 大会上正式发布的真实演讲内容。

这个项目的名字就叫 cyber-security-llm-agents。它由 NVISO 安全研究员打造，基于微软的 AutoGen 多智能体框架构建，将 LLM 的推理能力与网络安全工具链深度结合。373 颗 GitHub Stars 背后，是一个正在快速演进的领域：LLM 驱动的安全自动化。

背景：安全团队的"数字疲劳"有多严重？

网络安全行业面临一个日益严峻的问题：警报疲劳（Alert Fatigue）。据 IBM《2023 年数据泄露成本报告》，企业平均每天处理数千条安全告警，其中绝大多数是误报，安全分析师需要在真伪之间做大量重复性判断。与此同时，红队和渗透测试高度依赖人工经验，无法规模化；检测工程（Detection Engineering）团队在编写 YARA 规则、Sigma 规则时反复造轮子。

传统解决方案是引入 SOAR（安全编排自动化与响应）平台，但 SOAR 的剧本（playbook）需要安全专家手工编写 DSL（领域特定语言），学习曲线陡峭，维护成本高。当 ChatGPT 等 LLM 出现后，安全社区开始思考：LLM 能否理解安全上下文、自主完成这些任务？

NVISO 的答案是：可以，但需要精心设计代理架构。原因是，LLM 本身不具备执行能力——它需要工具（tools）、记忆（memory）和任务编排（orchestration）来"行动"。而 AutoGen 恰好提供了这套多代理协作的基础设施。

核心技术解析：AutoGen 驱动的多代理安全系统

cyber-security-llm-agents 的架构遵循任务协调员模式（Task Coordinator Pattern），包含以下核心组件：

1. 代理类型（Agents）

项目定义了五类专业化代理，通过 AutoGen 的 register_tools() 机制注册工具函数：

代理类型	文件	职责
`task_coordinator_agent`	`coordinator_agents.py`	任务分发与协调，是用户交互的入口
`text_analyst_agent`	`text_agents.py`	文本分析、告警研判、日志摘要
`internet_agent`	`text_agents.py`	互联网情报搜集（OSINT）
`caldera_agent`	`caldera_agents.py`	对接 MITRE Caldera 框架执行对抗模拟
`cmd_exec_agent`	`code_agents.py`	代码生成与命令执行

代理之间通过消息传递进行通信，支持 LLM 与 LLM 或 LLM 与工具的混合模式。task_coordinator_agent 充当中央调度器，根据任务类型将请求路由到对应的专业代理。

2. 工具层（Tools）

每个代理配备专属工具集：

web_tools.py：提供 URL 内容抓取、威胁情报查询等互联网访问能力，LLM 可自主搜索 CVE 编号、恶意软件特征等。
code_tools.py：提供代码执行沙箱，LLM 生成的脚本在这里运行，配合 YARA、Sigma 等工具做进一步分析。
caldera_tools.py：对接 MITRE Caldera 的 agents/*.py 模块，执行 ATT&CK 框架驱动的红队对抗模拟。

3. 动作编排（Actions）

actions/agent_actions.py 定义了**场景（Scenarios）**这一核心概念。每个场景是一组有序的代理动作序列，例如：

scenarios = {
    "HELLO_AGENTS": ["text_analyst_agent/hello"],    # 健康检查
    "DETECT_EDR": ["caldera_agent/detect_edr"],     # EDR 检测
    "RSAC_EXAMPLE": ["..."],                          # RSAC 演示场景
}

这种设计让安全团队可以将自己的操作流程模板化，LLM 负责推理"在什么上下文调用哪个动作"，而非直接操作低层命令。

4. 依赖技术栈

openai               # OpenAI API 接口
langchain-openai     # LangChain 的 OpenAI 封装
pyautogen            # AutoGen 核心框架
pandas               # 数据分析
PyPDF2 / pypdf       # PDF 告警报告解析
requests             # HTTP 请求
pyftpdlib            # 内置 FTP 服务器（演示用）
notebook             # Jupyter 环境

值得注意的是，项目支持多种 LLM 后端：OpenAI GPT-4 或本地模型（通过兼容 OpenAI API 接口的本地部署）。这意味着机构可以在不发送敏感数据到云端的前提下使用该项目。

部署体验：上手容易，深入有门槛

快速启动（3 步）

# Step 1: 安装依赖
pip install -r requirements.txt

# Step 2: 配置 API Key
cp .env_template .env
# 编辑 .env，填入 OPENAI_API_KEY 等

# Step 3: 运行健康检查
python run_agents.py HELLO_AGENTS

如果看到 Agent 给你讲了一个笑话，说明环境配置成功。

进阶用法：Caldera 红队对抗

# 启动 Caldera 服务器（需提前安装 Caldera）
python run_servers.py

# 运行 EDR 检测场景
python run_agents.py DETECT_EDR

硬件与 API 要求

GPU：不需要（LLM 推理通过 API 调用完成，本地不消耗 GPU）
内存：4GB+（Python 进程 + Jupyter）
磁盘：2GB+（代码 + 依赖）
必须：有效的 OpenAI API Key 或兼容的本地 LLM 端点

部署痛点

无 Docker 支持：项目没有提供容器化部署，所有依赖需手动安装，不同操作系统环境差异可能导致兼容性问题。
API Key 管理：OPENAI_API_KEY 直接写在 .env 文件中，生产环境需要配合密钥管理服务（如 HashiCorp Vault）使用。
命令执行风险：README 明确警告——LLM 生成的代码和命令具有破坏宿主系统的能力，必须全程在隔离的虚拟或测试环境中运行。

争议与局限性

安全边界问题

这个项目最核心的争议在于LLM 执行命令的失控风险。即使在隔离环境中，LLM 也可能生成意外的有害指令（删除文件、修改系统配置）。当前项目依赖使用者自行负责环境隔离，并没有内置沙箱强制约束。

实际效果依赖 LLM 能力

在 RSAC 2024 的演讲中，NVISO 坦承：GPT-4 在 EDR 绕过场景中会生成可被检测的代码，并非所有生成结果都可用。LLM 的"创造力"与"可控性"之间的张力是当前阶段无法根本解决的问题。

无容器化 = 难以规模化

没有 Dockerfile 或 docker-compose，意味着在企业环境中难以标准化部署——不同团队的 Python 版本、依赖冲突问题会显著增加运维成本。

行业意义：安全运营的范式转变

cyber-security-llm-agents 代表了一个重要趋势：AI Agent 在网络安全领域的落地正在从实验走向生产。

从行业视角看，该项目的价值不只在于工具本身：

多代理协作范式的安全验证：AutoGen 框架在通用场景下表现良好，但安全领域有其特殊性（高精度要求、命令执行风险），该项目提供了第一个公开的、经过实战验证的多代理安全框架参考实现。
紫队（Purple Team）自动化桥梁：Caldera 是红队工具，SIEM/XDR 是蓝队工具，而 LLM 代理首次在代码层面将两者连接起来，支持自动化的对抗-检测协同循环。
推动 LLM 安全研究：该项目在 GitHub 上获得了安全社区的广泛关注，其 issue 区讨论了大量关于模型选择、提示工程、安全边界的实践问题。
低门槛实验平台：373 颗 Stars 中，相当一部分来自希望了解"LLM 在安全领域能做什么"的学习者和研究者——它降低了安全 AI 的入门门槛。

总结：cyber-security-llm-agents 是目前最完整的开源 LLM 安全代理框架之一，基于 AutoGen 构建，提供文本分析、红队对抗、代码执行等多代理协作能力，适合有 Python 和安全背景的研究人员使用。由于缺乏容器化支持、无 Web UI，部署需要一定的技术门槛。核心价值在于它代表了一种趋势：AI Agent 正在从通用对话走向垂直领域的深度专业化。