coilysiren/gauntlet
GitHub: coilysiren/gauntlet
一个双智能体对抗循环系统,通过持续攻击观察代码行为来推断其正确性并提供概率化置信度。
Stars: 1 | Forks: 0
# ⚡🔄🛂 Gauntlet
Gauntlet 是一个双智能体对抗循环,通过观察代码在持续、有针对性的攻击下的行为来推断其正确性。它被设计为一个黑暗工厂环境中的质量控制系统——代码由机器人编写,由攻击进行验证。
这个名字来源于“跑过火网”:一个你必须承受来自四面八方的持续轰击的挑战。在这里,Inspector(检查员)推动被测试系统经历不断升级的对抗压力层级,直到隐藏的错误模式变得可检测——然后根据是否有信号通过来决定是否放行。
AI 编写的代码可能看起来正确——遵循惯例、通过 linting、读起来合理——但隐藏着只有在实际使用中才会暴露的行为错误。传统测试无法捕捉到这一点,因为编写代码的同一个智能体也编写了测试,共享相同的盲点。Gauntlet 为此而构建:Inspector 假设代码是 broken 的,并生成代码作者从未考虑过的计划,而每个 Weapon 中的 `blockers` 永远不会展示给 Attacker,从而保留了真实的训练/测试分割,防止智能体无意中编写出通过测试检查的代码。
## 快速开始
设置你的 LLM 凭证,然后将 Gauntlet 指向一个正在运行的 API:
```
export GAUNTLET_ATTACKER_TYPE=openai
export GAUNTLET_ATTACKER_KEY=sk-...
export GAUNTLET_INSPECTOR_TYPE=anthropic
export GAUNTLET_INSPECTOR_KEY=sk-ant-...
git clone git@github.com:coilysiren/gauntlet.git
cd gauntlet
docker compose run --rm demo
```
这将启动演示 API 并对其运行完整的对抗循环。
## 安装
```
pip install gauntlet
# 或: uv add gauntlet
```
## 用法
有关工作流指导(何时运行、如何集成、如何处理结果),请参见 [docs/usage.md](docs/usage.md)。
### LLM 配置
Gauntlet 需要为一个 Attacker 角色和一个 Inspector 角色各配置一个 LLM。使用一对环境变量分别配置每个角色:
| 变量 | 描述 |
|---|---|
| `GAUNTLET_ATTACKER_TYPE` | Attacker 的 LLM 提供者:`openai` 或 `anthropic` |
| `GAUNTLET_ATTACKER_KEY` | Attacker 提供者的 API 密钥 |
| `GAUNTLET_INSPECTOR_TYPE` | Inspector 的 LLM 提供者:`openai` 或 `anthropic` |
| `GAUNTLET_INSPECTOR_KEY` | Inspector 提供者的 API 密钥 |
默认模型为 OpenAI 的 `gpt-4o` 和 Anthropic 的 `claude-opus-4-5`。
为每个角色使用不同的提供者是刻意为之的——模型多样性可以减少盲点。
### CLI
```
gauntlet [url] [--config FILE] [--arsenal FILE] [--weapon FILE_OR_DIR] [--target FILE_OR_DIR] [--openapi FILE] [--users FILE] [--threshold N] [--no-fail-fast]
```
| 参数 | 默认值 | 描述 |
|---|---|---|
| `url` | 来自配置或必需 | 运行 API 的基础 URL |
| `--config` | `.gauntlet/config.yaml` | YAML 配置文件路径;CLI 标志覆盖配置值 |
| `--arsenal` | none | Arsenal YAML 文件路径(命名武器集合) |
| `--weapon` | `.gauntlet/weapons` | [Weapon YAML](#weapons) 文件路径,或 YAML 文件目录(每个文件一个武器) |
| `--target` | `.gauntlet/targets` | [Target YAML](#targets) 文件路径,或 YAML 文件目录(每个文件一个目标) |
| `--openapi` | none | OpenAPI 3.x YAML/JSON 规范路径;自动生成 Target 对象 |
| `--users` | `.gauntlet/users.yaml` | [users YAML](#user-authentication) 文件路径 |
| `--threshold` | `0.90` | 推荐合并所需的保持满足分数 |
| `--fail-fast` / `--no-fail-fast` | enabled | 遇到第一个关键发现时停止;使用 `--no-fail-fast` 运行所有迭代 |
```
gauntlet http://localhost:8000
gauntlet http://localhost:8000 --no-fail-fast
gauntlet http://localhost:8000 --openapi openapi.yaml
gauntlet http://localhost:8000 --arsenal .gauntlet/arsenal.yaml
gauntlet --config .gauntlet/config.yaml
```
输出为 YAML 格式:
```
risk_report:
confidence_score: 0.06
risk_level: critical
confirmed_failures:
- unauthorized_cross_user_modification # userB rewrote userA's task
coverage:
- GET /tasks/42
- PATCH /tasks/42
- POST /tasks
conclusion: >-
System fails under adversarial pressure and should not be promoted
without remediation.
```
### 项目配置目录
将 Gauntlet 配置文件放置在项目根目录下的 `.gauntlet/` 目录中。
CLI 会自动发现它们——在常见情况下无需标志:
```
your-project/
├── .gauntlet/
│ ├── weapons/ # one YAML file per Weapon — all loaded automatically
│ │ ├── task_ownership.yaml
│ │ └── task_read_isolation.yaml
│ ├── targets/ # one YAML file per Target — all loaded automatically
│ │ └── task_endpoints.yaml
│ └── users.yaml # User auth — loaded automatically if present
└── ...
```
使用 `--weapon FILE_OR_DIR`、`--target FILE_OR_DIR` 或 `--users FILE` 覆盖任意路径。
### 武器
一个 Weapon 定义了一个可重用的攻击策略。`blockers` 是该武器的 **生命体征**——关于预期系统行为的外部可观察事实,永远不会展示给 Attacker,从而保持训练/测试分离。
```
# .gauntlet/weapons/task_ownership.yaml
title: Users cannot modify each other's tasks
description: >
The task API must enforce resource ownership. A user who did not create
a task must not be able to modify or delete it.
blockers:
- A PATCH request by a non-owner is rejected with 403
- The task body is unchanged after an unauthorized PATCH attempt
- A GET by the owner after an unauthorized PATCH returns the original data
```
### 目标
一个 Target 定义了 Weapon 将被测试的 API 表面。每个 YAML 文件对应一个目标。
将多个目标指向同一武器,以针对不同 API 表面测试相同的攻击。
```
# .gauntlet/targets/task_endpoints.yaml
title: Task ownership endpoints
endpoints:
- POST /tasks
- PATCH /tasks/{id}
- GET /tasks/{id}
```
### 用户认证
创建 `.gauntlet/users.yaml` 以提供每个用户的凭证。敏感值永远不会存储在文件中——每个条目命名一个保存实际凭证的环境变量。未在文件中指定的用户会回退到默认的 `X-User: ` 头部。
支持的身份验证类型:
| 类型 | 字段 | 发送的头部 |
|---|---|---|
| `bearer` | `token_env` | `Authorization: Bearer <$token_env>` |
| `api_key` | `header`, `key_env` | `: <$key_env>` |
## 核心模型
Gauntlet 将代码变更的正确性视为在攻击下对行为观察的问题。
* 代码被认为是不受信任的,可能由人类编写——但设计为由机器人编写
* 测试是动态生成的
* 信心来自在对抗性探测下幸存的内容
它会问:“我们尝试破坏它的难度有多大,以及当我们尝试时发生了什么?”
## 两种角色
### 攻击者
探索执行空间
* 构建看似合理、生产环境类似的计划
* 模拟系统实际(和误用)的方式
* 探索工作流、边界情况和状态转换
* 根据已测试内容进行调整
攻击者并非试图证明正确性。它试图创造正确性可能失败的情境。
### 检查员
施加智能压力
* 分析执行结果中的弱点
* 识别可疑的通过和未测试的假设
* 形成关于隐藏错误模式的假设
* 强制下一轮计划朝向可能的断点
检查员假设“此系统已 broken。我只是尚未证明它。”
### 它们之间的动态
* 攻击者探索
* 检查员精炼
* 执行 grounding 两者
它们共同执行一种引导性的对抗搜索,覆盖可能的失败空间。
## 与众不同之处
Gauntlet 不是:
* 测试运行器
* 代码审查工具
* 模糊测试工具
它是一个用于软件正确性的对抗推理引擎。
它结合了:
* 动态计划生成(类似红队)
* 执行 grounding(类似 CI)
* 对抗性精炼(类似安全测试)
## 前人工作
这些项目处于同一领域——对运行服务进行对抗性测试。
### [RESTler](https://github.com/microsoft/restler-fuzzer)
来自微软研究的具有状态 REST API 模糊测试器。RESTler 生成并执行针对运行中服务的 HTTP 请求序列,从 OpenAPI 规范推断端点之间的生产者-消费者依赖关系,以探索深层服务状态。
共同基础:攻击一个 **运行中的 HTTP 服务器**,使用 **多步请求序列**,发现只有通过特定请求顺序才会暴露的 bug,并检查安全和可靠性错误。
架构差异:RESTler 使用源自 OpenAPI 规范的基于语法规则的模糊测试,而不是 LLM 推理。验证是硬编码的检查器(状态码、模式一致性),而不是会推理可疑之处的 Inspector。没有训练/测试分割——所有验证规则对生成逻辑可见。输出是每个序列的布尔值通过/失败,而不是概率置信度。
### [Schemathesis](https://github.com/schemathesis/schemathesis)
基于 Hypothesis 框架的属性测试 API 测试。生成数千个测试用例,从 OpenAPI/GraphQL 模式执行,并针对运行中的 API 查找崩溃、模式违规和状态工作流错误。
共同基础:测试一个 **运行中的 API**,支持 **状态化多步工作流**,其中前面的请求创建后续请求所消耗的资源,并且故意 **对抗性**——生成边界情况、边界条件和无效输入以破坏 API。
架构差异:生成是算法式的(属性测试),而非 LLM 驱动。没有 Attacker/Inspector 分离——生成和验证是统一的。没有隐藏 blockers 或训练/测试分割。结果是确定性的通过/失败,而不是概率置信度。
### [ToolFuzz](https://github.com/eth-sri/ToolFuzz)
ETH Zurich 提供的 LLM 驱动的模糊测试器,生成自然语言测试提示并针对 LLM 代理工具执行,检测运行时崩溃和语义正确性错误。
共同基础:**使用 LLM 生成对抗性输入**,并 **分离的生成和评估阶段**——提示被生成、执行针对目标,然后由 LLM 判断输出是否在语义上正确。这与 Attacker/Drone/Inspector 管道在架构上最为接近。
架构差异:目标是 LLM 代理工具(LangChain、Composio)而非任意 HTTP API。没有隐藏 blockers 或训练/测试分割,评估者看到所有上下文。攻击是单个提示,而不是多步链式 API 调用序列。没有概率置信度评分。
标签:AI安全, ASM汇编, C2, Chat Copilot, DevSecOps, Inspector-Attacker, LLM测试, PyRIT, 上游代理, 压力测试, 多智能体系统, 大模型安全评估, 密钥泄露防护, 对抗测试, 开源框架, 持续集成, 攻击驱动, 暗工厂, 机器学习安全, 测试隔离, 行为缺陷检测, 请求拦截, 软件验证, 逆向工具