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, 上游代理, 压力测试, 多智能体系统, 大模型安全评估, 密钥泄露防护, 对抗测试, 开源框架, 持续集成, 攻击驱动, 暗工厂, 机器学习安全, 测试隔离, 行为缺陷检测, 请求拦截, 软件验证, 逆向工具