【免费下载链接】exploitgym
ExploitGym is a large-scale, realistic benchmark built from real-world vulnerabilities designed to evaluate AI agents' ability to develop exploits.
ExploitGym是一个基于真实漏洞的大规模 AI Agent 渗透能力评测基准,而它内置的LLM Proxy(大模型 API 代理)是整套评测体系中的"钱包 + 安检门":一方面为每个 AI Agent 任务发放带预算的临时 API Key,实现按任务的费用上限控制;另一方面默认阻断模型服务商侧的外网搜索与远程取数能力,确保 Agent 无法绕过容器防火墙"偷偷"访问互联网。本文带你快速看懂这套机制的设计思路与使用方法。
为什么需要一个 LLM Proxy?
在 ExploitGym 中,Agent 运行在隔离容器里完成漏洞利用任务。这里有两个现实问题:
- 💰费用失控:Agent 长任务可能持续调用 LLM API,一旦"死循环"或卡死,账单会像失控的循环一样增长。没有预算闸门,跑 869 个任务的成本完全不可控。
- 🛡️容器防火墙挡不住"服务商侧"外联:ExploitGym 的 Squid 防火墙 只能隔离容器出站流量,但 Web 搜索、网页抓取、深度研究等能力是在LLM 服务商自己的服务器上执行的——容器网络隔离对这些能力完全无效。如果放任不管,Agent 就可以"合法"地把题目信息发到外网搜索答案,评测结果将失去意义。
因此 ExploitGym 在 src/cybergym/llm_proxy/ 模块中实现了一个轻量代理:
| 能力 | 作用 |
|---|---|
| 按 Key 的预算记账 | 每个任务的 Key 有独立 USD 上限,超额自动拒绝 |
| 模型白名单 | Key 只能调用被允许的模型 |
| 外网搜索阻断 | 默认拒绝一切"服务商侧外联"请求 |
| 路由白名单 | 只放行无状态推理接口,管理/有状态接口一律 403 |
| 内存记账 | 无需 Postgres 等外部数据库,零依赖启动 |
核心设计一句话:让 Agent 花多少钱、能调什么模型、能不能上网搜,全部在代理层强制执行。
按任务预算控制的完整流程
预算机制的核心是 budget.py 中的BudgetManager,它为每个 API Key 维护一条KeyRecord(budget.py#L74-L101),记录字段包括:
max_budget/spend/remaining:预算上限、已花费、剩余input_tokens/output_tokens/reasoning_tokens:各类 token 计数cache_read_tokens/cache_creation_tokens:缓存命中与写入requests/total_latency:请求数与累计延迟per_model:按模型拆分的独立小账本——Agent CLI 内部偷偷调用的"辅助小模型"(如 Gemini CLI 的分类器调用 flash 模型)也会各自入账,一目了然
整个生命周期只有四步:
- 发放:评测运行器 run_agent.py 通过 manager.py 中的
ProxyKeyManager调用POST /budget/generate_key,按任务申请一个预算为--budget美元(默认 $20)的临时 Key; - 记账:每次成功请求后,
BudgetCallback(server.py#L212-L266)自动从响应中提取 token 用量,交给 litellm 计算成本并累加到该 Key 的账本; - 拦截:Key 一旦花超,后续请求直接返回HTTP 429
budget_exceeded,Agent 拿到的错误信息形如Budget exhausted: $20.00 / $20.00,从根源上止损; - 回收:任务结束时删除 Key(
DELETE /budget/key/{key}),最终花费写入输出目录的key_usage.json,长跑任务还会每 ~20 分钟在usage/目录落一份中间快照,方便实时盯成本。
这套"生成→记账→拦截→回收"的闭环,让预算成为评测的硬约束而不是事后统计。
模型白名单:Key 只能调允许的模型
生成 Key 时除了max_budget,还可以传入allowed_models。代理会在 server.py#L426-L448 处对每个请求体做精确匹配,调用白名单之外的模型会收到HTTP 403model_not_allowed。
在评测侧有两种用法(见 docs/eval.md):
# 显式列出允许的模型 uv run examples/run_agent.py --agent claude_code \ --proxy-url http://172.17.0.1:4000 \ --budget 5.00 --allowed-models claude-sonnet-4-6 # 或者不带值:自动把 Key 锁定到本次运行的 --model uv run examples/run_agent.py --agent claude_code \ --proxy-url http://172.17.0.1:4000 \ --budget 5.00 --model claude-sonnet-4-6 --allowed-models💡 小提醒:如果 Agent CLI 内部还会调用辅助模型(比如 Gemini 的分类器模型),记得把它一并加入白名单,否则会被 403 拦下。
外网搜索阻断:四层规则拦住所有"服务商侧外联"
检测逻辑独立成 websearch.py,采用fail-closed(默认拒绝)策略,核心函数是find_web_search()(websearch.py#L176-L217)。它按四层规则扫描请求体与路由路径:
| 规则 | 拦截对象 | 典型触发 |
|---|---|---|
| 规则 1:模型名 | 托管搜索/深度研究模型 | 模型名含*-search-preview、*-search-api、*-deep-research |
| 规则 2:顶层参数 | 请求级搜索开关 | 出现web_search_options(即使为空对象)、mcp_servers |
| 规则 3:工具声明 | 服务商托管工具 | web_search*、web_fetch*、code_execution*、mcp、code_interpreter、file_search,以及 Gemini 的google_search、url_context、enterprise_web_search |
| 规则 4:远程取数字段 | 指向外部资源的任意字段 | file_url、server_url、connector_id、file_uri、外链image_url、Anthropic 的 URL 文档源、带network_policy的托管 shell |
命中任何一条,请求即被HTTP 403web_search_blocked拒绝,错误信息会附带具体原因(如tool 'web_search'、'web_search_options')。
值得注意的两个"放行"边界,体现了设计的精确性:
- ✅内联
data:图片允许通过——它只携带数据本身,不触发任何外部拉取; - ✅Agent 自执行的客户端工具(
function工具、本地bash、text_editor等)不受影响——它们跑在防火墙后的容器里,网络出口已被 Squid 代理管住。
如果想显式放开(不推荐用于正式评测),启动代理时加--allow-web-search即可。
路由白名单与其他安全细节
除了预算和搜索,server.py 还埋了几处"防君子也防小人"的细节:
- 🔒路由白名单:只放行 LiteLLM 的无状态推理路由(
/v1/messages、/v1/responses、/v1beta/models/...:generateContent等)及厂商透传前缀;/v1/batches、/v1/files、MCP 端点等有状态或管理型接口一律 403forbidden_route,避免 Key 被拿去批量刷接口或触发远程代码执行面; - 🔑内部主 Key 不外泄:代理把外部 Key 在转发前统一替换为进程内部生成的 master key,外部调用者无法直接借用或伪造 LiteLLM 凭证(server.py#L450-L472);
- 🔐管理端点独立鉴权:
/budget/*必须携带x-admin-key请求头,与推理 Key 完全分离; - 🧹报错信息脱敏:
TracebackRedactionMiddleware会剥掉错误响应里 LiteLLM 拼入的 Python 堆栈,防止内部文件路径、版本号等细节泄露给容器里的 Agent。
启动与验证:三步跑通 LLM Proxy
启动命令很简单(详见 docs/eval.md 的 "Prepare local litellm proxy" 一节):
export PROXY_PORT=4000 export CYBERGYM_ADMIN_KEY=cgym-admin-$(openssl rand -hex 12) export ANTHROPIC_API_KEY=sk-ant-... # 按需加上 OPENAI_API_KEY 等 uv run -m cybergym.llm_proxy \ --host 172.17.0.1 \ --port $PROXY_PORT \ --admin-key $CYBERGYM_ADMIN_KEY \ --default-budget 20.0常用参数一览(入口main.py):
| 参数 | 说明 | 默认值 |
|---|---|---|
--host/--port | 监听地址 | 127.0.0.1/4000 |
--config | LiteLLM 模型配置 YAML | default_config.yaml |
--default-budget | 每个 Key 的默认预算(USD) | 20.0 |
--admin-key | /budget/*管理 Key,也可用环境变量CYBERGYM_ADMIN_KEY | 自动生成并打印 |
--allow-web-search | 关闭外网搜索阻断 | 默认开启阻断 |
验证是否跑通,可发起一轮"发 Key → 推理 → 查用量 → 吊销"(文档中附有完整 curl 示例):
# 1. 用管理 Key 申请一个 $0.01 的测试 Key curl -s -X POST http://172.17.0.1:4000/budget/generate_key \ -H "x-admin-key: $CYBERGYM_ADMIN_KEY" -H 'Content-Type: application/json' \ -d '{"max_budget": 0.01}' # 2. 用测试 Key 发起一次推理 curl -s -X POST http://172.17.0.1:4000/v1/messages \ -H "x-api-key: $KEY" -H 'content-type: application/json' \ -d '{"model": "claude-sonnet-4-6", "max_tokens": 16, "messages": [{"role": "user", "content": "hi"}]}' # 3. 查询该 Key 的花费与 token 明细,然后吊销 curl -s -H "x-admin-key: $CYBERGYM_ADMIN_KEY" \ http://172.17.0.1:4000/budget/usage/$KEY常见错误码速查表
跑评测时如果看到这些返回,对照下表即可快速定位:
| 状态码 | 类型 | 含义 | 处理建议 |
|---|---|---|---|
| 401 | auth_error | Key 不存在或管理 Key 错误 | 检查x-api-key/x-admin-key |
| 403 | budget_exceeded相关路径 /forbidden_route | 访问了白名单外的路由 | 只用推理接口 |
| 403 | web_search_blocked | 触发了服务商侧外联能力 | 属预期拦截,检查 Agent 为何开启搜索 |
| 403 | model_not_allowed | 调用了白名单外模型 | 把模型加入--allowed-models |
| 429 | budget_exceeded | 预算耗尽 | 属预期止损,适当调大--budget |
总结与相关文件
ExploitGym 的 LLM Proxy 用一个轻量组件同时解决了评测中的两个难题:用"每任务一把钥匙"的内存账本实现预算硬约束,用四层 fail-closed 规则堵住服务商侧的外网搜索通道,再配上路由白名单与报错脱敏,让 AI Agent 评测既算得清成本,也守得住隔离边界。
相关文件索引:
- 代理服务与中间件:server.py
- 预算记账核心:budget.py
- 外网搜索检测器:websearch.py
- 运行器侧 Key 管理客户端:manager.py
- 默认模型配置:default_config.yaml
- 评测全流程(含代理启动与验证命令):docs/eval.md
- 容器出站防火墙(与 LLM Proxy 互补的第二层防线):docs/firewall.md
- 代理行为测试:tests/llm_proxy/test_server.py
📌 一句话记忆:防火墙管"容器能不能上网",LLM Proxy 管"模型服务商帮不帮你上网",两者合力才是完整的外联隔离。
【免费下载链接】exploitgym
ExploitGym is a large-scale, realistic benchmark built from real-world vulnerabilities designed to evaluate AI agents' ability to develop exploits.
相关推荐
从微软实践到开源共享:gh_mirrors/ca/career-ladders背后的设计哲学
从微软实践到开源共享:gh_mirrors/ca/career ladders背后的设计哲学 在当今快速发展的科技行业中,职业发展路径的透明度和可预期性已成为吸
PowerJob批量任务处理终极指南:任务合并与并行度控制策略详解
PowerJob批量任务处理终极指南:任务合并与并行度控制策略详解 PowerJob作为新一代分布式调度与计算框架,在企业级批量任务处理领域展现出了卓越的性能优
任务调度后端FastAPI Contrib序列化器揭秘:ModelSerializers如何简化数据验证与数据库操作
FastAPI Contrib序列化器揭秘:ModelSerializers如何简化数据验证与数据库操作 FastAPI Contrib是一个基于FastAPI
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考