nuclide-research/ai-llm-redteam-operator

GitHub: nuclide-research/ai-llm-redteam-operator

一款面向 AI/LLM 基础设施的授权红队评估工具,将暴露场景自动规划为结构化攻击链并在严格安全管控下执行验证。

Stars: 0 | Forks: 0

ai-llm-redteam-operator

规划 AI/LLM 红队场景,并针对单一授权目标运行。

release license python NuClide

快速开始工作原理安全机制用法关注维度数据包状态与限制适用范围

ai-llm-redteam-operator 是一个两阶段的授权 AI/LLM 评估工作流。 **`plan`** 将一个关注值(类别、平台或命名的攻击路径)转化为结构化的场景数据包:包含要发送的探测请求、确认每个步骤的弱信号、要执行的攻击链,以及相应的防御指南。它不会触碰网络。 **`run`** 将该数据包交给 agent,由其作为“感知-规划-行动”循环针对单一主机执行。agent 会发送数据包指定的探测请求,读取响应,仅在上一步确认后才推进攻击链,并返回一份证据账本:记录了发送了什么、返回了什么,以及证据实际支持了哪些假设。 agent 会发送真实的 HTTP,因此被设计为默认安全。它拒绝在没有授权参考的情况下发送;在你传入 `--live` 之前只进行规划而不发送;将每个请求都锁定在单一目标主机上;并且在未获你允许之前限制所有写操作。没有网络上的确凿证据,任何内容都不会被标记为 `confirmed`(已确认)。 它位于 NuClide 链的执行阶段。当 [aimap](https://github.com/nuclide-research/aimap) 回答“这是什么服务?”,而 [herald](https://github.com/nuclide-research/herald) 回答“它开放了吗?”时,ai-llm-redteam-operator 回答的是:“鉴于这种暴露类别,针对该主机走一遍完整的红蓝对抗计划,并向我展示证据。” ## 快速开始 ``` git clone https://github.com/nuclide-research/ai-llm-redteam-operator cd ai-llm-redteam-operator pip install -e . # installs the `ai-llm-redteam-operator` console command ``` 要求 Python 3.8 或更高版本。无需第三方包:运行时仅使用标准库中的 `dataclasses`、`argparse`、`sqlite3`、`json`、`urllib` 和 `ssl`,可选的 LLM 路径也保持在 `urllib` 上。 三个命令,风险从零递增到真实流量: ``` # 1. PLAN. No network. Write the scenario packet for a platform. ai-llm-redteam-operator plan platform LiteLLM # 2. DRY-RUN. Build every request for a target and send nothing. ai-llm-redteam-operator run platform LiteLLM \ --target https://10.0.0.5:4000 --authorize ENG-2026-014 # 3. LIVE. Send the planned read probes and report the evidence. ai-llm-redteam-operator run platform LiteLLM \ --target https://10.0.0.5:4000 --authorize ENG-2026-014 --live ``` `plan` 是默认的子命令,因此直接使用裸命令(`ai-llm-redteam-operator platform LiteLLM`)也是可以的。如果不想安装,可以从仓库根目录调用模块:`python -m ai_llm_redteam_operator.cli plan platform LiteLLM`。 ## 工作原理 ``` plan stage (no network) run stage (scoped, gated) ┌────────────────────────┐ ┌──────────────────────────────┐ │ focus value │ │ authorized target + scope ref │ │ category / │ │ │ │ platform / │ │ recon pre-pass: send each │ │ attack_path │ │ in-cap read probe once │ │ │ │ │ │ │ │ ▼ │ Scenario │ ▼ │ │ AegisLLM_Operator ───┼── Packet ──▶│ evaluate weak signals │ │ (planner / policy) │ (7 sections)│ against the responses │ │ │ │ │ │ │ │ ▼ │ │ ▼ │ │ playbook + 2 hand- │ │ walk each attack chain: │ │ authored scenarios │ │ advance a step only if the │ └────────────────────────┘ │ prior step confirmed │ │ │ │ │ ▼ │ │ Run Report: findings + │ │ chain outcomes + evidence │ │ ledger (md or json) │ └──────────────────────────────┘ ``` 这个循环是真实存在的,绝非摆设: - **感知。** agent 会对每一个能力内的探测请求运行一次,然后将每个测试用例的预期弱信号映射到具体的响应上。信号只能匹配真实的、已发送的观测结果,绝不是规划中的内容。 - **规划。** 默认情况下,攻击链按数据包顺序执行。提供一个 LLM endpoint,可选的策略器就会重新排列优先执行的攻击链;如果它执行失败或不存在,agent 将保持确定性的顺序。 - **行动。** 只有当前步骤被 `confirmed` 时,攻击链才会推进到下一步。一旦某一步的信号未能确认,攻击链就会停滞在那里。agent 不会执行前置条件无法满足的步骤。 只有在基于确凿的、已发送的证据时,发现结果才会是 `confirmed`:信号指定的 2xx 状态码且实际返回了 body,或者 2xx 响应上的 body token 或 header。在 403 响应体内回显的 token 不算数,而纯粹的 204 状态码也无法确认任何可窃取的内容。在 dry-run(试运行)模式下什么都不会发送,因此从构造机制上来说,每个发现都保持未确认状态。 ## 安全机制 agent 会发送真实的 HTTP。共有四道关卡,全部默认安全,每道关卡只能通过显式的 flag 解锁: ``` ┌─ authorization ── no --authorize → refuse, send nothing ├─ mode ────────── default dry-run → plan requests, send nothing ├─ scope ───────── every URL = target host + packet path; redirects captured, │ not followed; responding host re-checked → cannot leave host └─ two probe gates ├─ noise cap (--max-aggressiveness): filters READ probes by rated noise └─ mutation gate (--allow-writes): blocks ALL write methods until set, no matter how the packet rated them ``` 噪音上限和突变关卡是故意独立设计的。规划器将许多突变探测请求的噪音评级为 `medium`(中),因此仅靠噪音上限是允许它们触发的。提高 `--max-aggressiveness` 绝不意味着允许写操作。只有在设置了 `--allow-writes` 时,写操作(POST、PUT、PATCH、DELETE)才会发出;此外,无法识别的噪音标签会被视为最高级别,这样即使出现拼写错误也会自动拒绝执行。 范围经过了两次强制检查。根据约定,数据包路径必须是主机相对路径(绝对路径或带有 scheme 的相对路径会被拒绝);并且自定义重定向处理程序从不跟随 3xx 响应,而是将其作为终止性观测结果返回,以便操作员能看到 `Location` 并自行决定。作为纵深防御措施,在记录任何响应体之前,系统会再次根据目标检查响应 URL 的主机名。 克制原则也体现在循环中:每一步只获取一个证明 artifact 然后停止,对每个响应样本设置字节上限(`--max-body-bytes`),并设有全局请求预算(`--max-requests`),耗尽时即结束运行。 ## 用法 ### `run` flags | Flag | Default | Effect | |------|---------|--------| | `--target` | (必填) | 目标 base URL;每个请求都保持在此 scheme 和 host 下 | | `--authorize` | (必填) | 授权/范围参考;没有它就无法发送 | | `--dry-run` / `--live` | `--dry-run` | 仅规划,或实际发送 | | `--max-aggressiveness` | `medium` | 要发送的最高读取探测噪音级别 (`low_noise`, `medium`, `high`) | | `--allow-writes` | off | 允许 POST/PUT/PATCH/DELETE 探测,独立于噪音上限 | | `--max-requests` | `60` | 本次运行的全局请求预算 | | `--max-body-bytes` | `4096` | 响应 body 样本上限 | | `--delay` | `0.5` | 每次实际请求前的暂停时间(秒) | | `--timeout` | `8.0` | 单次请求超时时间(秒) | | `--verify-tls` | off | 验证目标证书(默认关闭,范围内的自签名证书很常见) | | `--llm-endpoint` / `--llm-model` / `--llm-api-key-env` | off | 可选的策略器 endpoint、模型和 key 环境变量 | | `--format` | `md` | 报告格式,`md` 或 `json` | | `--out` | stdout | 将报告写入文件 | 两个阶段共享 `--format` (`md` 或 `json`) 和 `--out`。`plan` 还增加了 `--min-severity`、`--sectors`、`--limit` 和 `--list-values ` 以枚举有效值。 一个包含允许突变和策略器排列攻击链的实战运行示例: ``` ai-llm-redteam-operator run attack_path open_gateway_llmjacking \ --target https://10.0.0.5:4000 --authorize ENG-2026-014 \ --live --allow-writes --max-aggressiveness high \ --llm-endpoint http://127.0.0.1:11434/v1/chat/completions ``` ### 作为库使用 ``` from ai_llm_redteam_operator import AegisLLM_Operator, RunConfig, build_agent, render_run_report_markdown op = AegisLLM_Operator(db_path="nuclide.db", coords_path="coords.json", details_path="details.json") packet = op.generate_scenario_packet("platform", "LiteLLM") cfg = RunConfig(target="https://10.0.0.5:4000", authorization="ENG-2026-014", dry_run=False) report = build_agent(cfg).run(packet) print(render_run_report_markdown(report)) # report.to_dict() for machine use ``` ## 关注维度 可以将任一阶段指向三种关注类型之一。注册表位于 `models.py` 中。 **`category`** 是八种 AI/LLM 暴露类别之一: ``` exposed_model_runtimes open_gateways notebooks chat_uis leaky_data_stores key_abuse observability agent_surfaces ``` **`platform`** 是特定的产品,通过 `PLATFORM_MAP` 解析为其所属类别: ``` Ollama, vLLM -> exposed_model_runtimes LiteLLM, One-API, Kong, PortKey.ai -> open_gateways JupyterHub -> notebooks Open WebUI, Streamlit -> chat_uis Elasticsearch, Weaviate, Qdrant, Milvus -> leaky_data_stores MLflow, Langfuse -> observability Flowise, Langflow -> agent_surfaces ``` **`attack_path`** 是一条命名的端到端攻击链: ``` open_gateway_llmjacking ollama_11434_host_takeover flowise_to_weaviate_pii_dump open_webui_open_signup_rag_seat open_jupyter_gpu_rce ``` ## plan 生成的内容 场景数据包分为七个部分,定义为 `models.py` 中的 dataclass。规划器会填充全部七个部分;agent 在运行时读取其中的三个(`recon_mapping` 对应要发送的内容,`test_cases` 对应确认步骤的信号,`attack_chains` 对应执行的顺序)。 | Section | Contents | |---------|----------| | `target_profile` | 主机摘要(严重程度/行业/认证姿态统计)、典型平台、显著模式 | | `recon_mapping` | 表面元素、HTTP 探测模式(方法、路径、headers、激进度)、分阶段的侦察计划 | | `threat_model` | 按关键性排名的资产、带有置信度和影响的可证伪假设 | | `test_cases` | 目标、前置条件、步骤、弱信号、确认后的严重程度 (severity-if-confirmed)、噪音级别、检测重点 | | `attack_chains` | 有序的测试用例序列,包含噪音特征和防御者学习目标 | | `detection_telemetry` | 日志建议、检测思路(模式 + 严重程度)、隐蔽性说明 | | `hardening` | 速赢方案、架构变更、检测工程行动、各平台专属模板 | 映射目标的数据包同时也在加固目标:每个测试用例都带有其 `severity_if_confirmed` 和 `noise_level`,每条攻击链也都带有其 `defender_learning_goals`。 ## run 生成的内容 运行报告即为证据记录。在 Markdown 中,它是一个标题下的三个表格: ``` # Agent run report: platform / LiteLLM - mode: live - target: https://10.0.0.5:4000 - authorization: ENG-2026-014 - requests: 6 sent, 0 planned, 2 skipped ## Findings | test case | confirmed | severity | evidence | note | | open_models_list | yes | high | #3 | confirmed: 1 signal(s) backed by sent evidence | | spend_logs_leak | no | high | - | no expected weak signals observed | ## Attack chains ### LLMjacking via open gateway (open_gateway_llmjacking) - stalled - reached step: spend_logs_leak - confirmed steps: open_models_list - defender learning goals: ... ## Evidence ledger | # | probe | method | path | status | sent | note | | 3 | models_probe | GET | /v1/models | 200 | yes | | | 5 | write_probe | POST | /v1/keys | - | no | write method POST blocked (pass --allow-writes to permit) | ``` `--format json` 会输出与 `RunReport.to_dict()` 对象相同的数据:模式、请求计数、每次观测、每个发现及其支撑证据的序列号、攻击链结果以及运行备注。账本会一并列出计划的、跳过的和已发送的请求,因此审查者可以确切地看到每个发现依赖于什么,以及保留了什么内容未执行。 ## 状态与限制 功能性发布版本,`0.2.0`。两个阶段均能实现端到端工作。全部八个类别、全部十七个平台和全部五条攻击路径都能规划出完整的数据包并针对目标执行。授权关卡、dry-run 默认设置、范围锁定、噪音上限、突变关卡、信号评估器和攻击链推进机制,均在循环测试中针对本地 stub 服务器进行了演练。 有两个子系统是刻意受限的,并且它们都会在输出中原样说明,而不是加以隐藏: - **规划器中的实时主机摘要计数。** `_query_host_summary` 会返回零,等待真实的 `nuclide.db`;该方法记录了假定的 schema,而两个手工编写的场景则展示了说明性的计数。数据包中的其他内容均为实时生成。 - **信号评估在本质上是启发式的。** 它将状态码、header 存在情况和 body token 与数据包的弱信号进行匹配,并且仅在基于确凿的、已发送的证据时才予以确认。它被刻意设计得很保守,并记录了每次匹配背后的确切观测结果,因此它只是对 agent 所见的内容进行分类筛选,而不是取代操作员的判断。 包结构布局: ``` ai_llm_redteam_operator/ cli.py plan / run subcommands, focus dispatch, output routing operator.py AegisLLM_Operator: builds the packet (planner) playbook.py tactical knowledge base, one entry per focus value models.py dataclasses for every packet node + registries render.py ScenarioPacket dict -> Markdown agent.py RedTeamAgent: the sense-plan-act loop (executor) + run report ``` 要扩展计划:在 `models.py` 的相关注册表中添加值,然后在 `playbook.py` 的相应字典中添加匹配条目。适配器会自动识别它。如果需要定制的、全深度的场景,请在 `operator.py` 中添加一个专门的构建器。agent 会运行规划器发出的任何内容,而无需对 agent 进行任何更改。 ## 适用范围 授权评估工具。agent 在设计上会执行网络活动,因此受到相应的门控限制:它需要明确的授权参考和目标,默认为 dry-run 模式,锁定在单一主机,在被告知之前阻止突变操作,并对每次运行设定界限。每个场景都假定已获得范围内目标的明确书面授权。 可选的 LLM 策略器会将侦察摘要(每次实际观测对应一行 `METHOD path -> status`,无响应 body)传输到配置的 endpoint。除非提供了 `--llm-endpoint`,否则它是关闭的;运行报告会记录该出口流量;当 endpoint 是远程或明文时,它会发出警告。任何策略器故障都会被静默处理,并且 agent 会回退到确定性顺序,因此该顾问永远不会自行破坏或引导运行。 数据包和循环编码了评估伦理:步骤在获取一个证明 artifact 后即终止,而非进行批量提取;PII 场景从 schema 和最小样本中确认数据类别;威胁假设是可证伪的;而且一项发现永远只与账本中的证据一样确凿有力。 ## 许可证 MIT。NuClide 工具链的一部分。联系方式:[nuclide-research.com](https://nuclide-research.com)
标签:AI安全, Chat Copilot, CISA项目, LLM基础设施, 威胁建模, 红队评估, 自动化渗透测试, 逆向工具