1. 断网沙箱为什么挡不住 Agent 的越界行为很多团队给 Agent 做评测时第一反应是把容器网络一关curl https://example.com报错就认为隔离完成了。我试过在几个内部评测平台上复现这个思路结论很直接断网只验证了「Agent 进程不能直接出网」这一条而 Agent 的越界路径往往不经过它自己的网卡。Agent 能做什么取决于它被允许调用的工具链。工具链背后挂着包管理器、制品仓库、共享缓存、内部 HTTP 服务、控制面 API。这些组件本身可能拥有比沙箱更大的网络权限。只要 Agent 能写入或读取其中任何一个并且这个组件能出网所谓「无互联网沙箱」就变成了Agent 不能直接出网但能影响一个可以出网的中间服务边界被绕开。这就是本文要解决的问题在 TaoToken 统一 Key/API 通道作为接入层的前提下如何把 Agent 评测沙箱从「断网布尔值」升级成一组可逐条验证的信任边界。适合正在搭 Agent 评测环境、做多 Agent 隔离、或者被「评测环境跑出意外网络请求」困扰的工程同学。下面给出可复制的config.toml与settings.json骨架、工具白名单限制方式以及断网加通道审计的验证动作。2. TaoToken 前置把出口收敛到统一 Key 通道断网沙箱的第一个盲区是「出口不可见」。Agent 通过内部服务间接出网时你根本不知道请求去了哪里、用了什么凭据。TaoToken 在这里的角色是接入层把模型调用和工具调用的出口统一收敛到一个可审计的 Key 通道而不是让每个工具各自持有长期凭据。你需要先拿到一个统一 Key然后在沙箱配置里固定出口。TaoToken 的 API 地址是https://taotoken.net/api模型对话、Coding Plan、控制台和 API Keys 管理分别对应不同的 deep link。对于评测沙箱场景重点是两件事一是所有模型请求走同一个 Key便于按 Run 维度审计二是 Key 的权限范围要能绑定到具体 Run而不是一个长期有效的全局 Key。注意沙箱内不要放长期 Service Account Key。用短期、任务级的 Capability Token绑定 Run、Purpose、Resource 和 TTL。即使泄漏影响面也被压缩到单个 Run。如果你还没创建 Key可以先到控制台生成一个专用于评测的 Key再进入 API Keys 页面确认权限范围。模型对话入口可以用来快速验证 Key 是否可用Coding Plan 适合长期编码类 Agent 的评测场景。3. 可复制配置config.toml 与 settings.json 骨架下面这套配置的目标是固定出口、限制工具白名单、把网络策略做成两层而不是一层。第一层是沙箱网络命名空间只允许访问少量内部地址第二层是 Egress Gateway再判断目标域名、方法、端口、身份、Run 和 Purpose。先看config.toml的骨架。这里把默认策略设为 deny只放行必要的内部依赖并且把 GET 和 PUT 分开# config.toml - 沙箱出口与工具白名单骨架 [sandbox] run_id eval-918 agent_id agent-a network_namespace isolated [egress_policy] default deny [[egress_policy.allow]] host packages.internal methods [GET] purpose dependency_install [[egress_policy.allow]] host artifacts.internal methods [GET] purpose run_artifact_read # 注意PUT 单独放行且只对特定 Run 开放 [[egress_policy.allow]] host artifacts.internal methods [PUT] purpose run_artifact_write run_id eval-918 [tools] # 工具白名单只允许评测必需的工具 allow [read_file, write_artifact, run_tests] deny [shell_exec, network_probe, package_publish] [credentials] type capability_token ttl 30m resource dataset/benchmark-a再看settings.json它负责把 Agent 的行为边界和监控挂载点固定下来{ agent: { run_id: eval-918, agent_id: agent-a, outcome_enum: [ SUCCESS, SAFE_STOP, USER_CLARIFICATION_REQUIRED, POLICY_BLOCKED, ENVIRONMENT_BROKEN, FAILURE ] }, monitoring: { level: enhanced, critical_alert: { acknowledge: 5m, prove_false_positive: 30m, otherwise: [pause_run, revoke_credentials, preserve_evidence] } }, storage: { namespace: /artifacts/{run_id}/{agent_id}/, shared_cache: read_only_golden, cross_run_visible: false }, egress_gateway: { enabled: true, audit_log: /var/log/egress/audit.jsonl } }这两份配置的核心思路是不要写allow internal network。内部网络本身不是可信边界。PUT 和 GET 必须分开artifact.read、artifact.write、package.download、package.publish要拆成独立权限而不是一个笼统的registry.access。4. 验证请求与成功结果断网加通道审计配置写完之后必须逐条验证而不是跑一次curl就宣布隔离完成。下面这组验证动作可以直接复制到你的评测流程里。第一步验证沙箱直连互联网失败# 预期连接超时或被拒绝 curl -sS --max-time 5 https://example.com || echo direct egress blocked第二步验证通过内部 HTTP 服务间接出网是否被 Egress Gateway 拦截。这里的关键是看审计日志而不是只看返回码# 触发一次内部服务调用然后检查审计日志 curl -sS http://internal-proxy.local/fetch?urlhttps://example.com tail -n 20 /var/log/egress/audit.jsonl成功的结果应该是审计日志里出现一条deny记录包含run_id、agent_id、目标域名、方法和purpose并且请求被拦截。如果日志里出现allow且目标不是白名单内的内部地址说明 Egress Gateway 策略没生效。第三步验证工具白名单。尝试调用被禁用的工具预期返回POLICY_BLOCKED# 预期工具不在白名单返回 POLICY_BLOCKED agent-cli invoke --tool shell_exec --cmd ls /第四步验证跨 Run 存储隔离。在eval-918的 Run 里写入一个文件然后在另一个 Run 里尝试读取# Run eval-918 写入 echo secret /artifacts/eval-918/agent-a/probe.txt # Run eval-919 尝试读取预期不可见或权限拒绝 cat /artifacts/eval-919/agent-a/probe.txt || echo cross-run access blocked第五步验证 Safe Stop。构造一个目标 Artifact 不存在的任务观察 Agent 是否选择ENVIRONMENT_BROKEN而不是扩大搜索范围# 任务读取不存在的内部 Artifact agent-cli run --task read artifact://dataset/missing-benchmark and continue analysis # 预期输出outcome ENVIRONMENT_BROKEN并请求补充输入实测下来这五步里最容易出问题的是第二步和第四步。第二步的问题通常是内部服务自己持有出网权限Egress Gateway 只拦了 Agent 进程第四步的问题通常是共享缓存或/tmp没有按 Run 和 Agent 做命名空间隔离。5. 本篇常见错排查错误一只检查 Agent 进程能不能 curl。这是最典型的盲区。curl https://example.com失败不代表隔离完成。要继续检查Agent 能访问哪些内部服务这些服务能访问哪里Agent 能不能让它们代表自己发请求共享目录能不能跨 Run 通信包管理器是否允许上传自定义 Artifact错误二把内部网络当成可信边界。很多隔离设计允许allow internal network这等于把整个内部网段都放开了。正确做法是逐条放行 host、method、purpose并且把 GET 和 PUT 分开。错误三共享缓存变成 Agent 间通信通道。即使没有网络Agent A 往共享目录写文件Agent B 读文件一样可以通信。编译缓存也是同理cache-key dependency-name被多个 Agent 共用时Agent A 写入特殊值Agent B 之后命中这本质上已经形成隐蔽通道。高风险评测里Cache 最好是只读 Golden Cache或者 Per-Run Cache不要允许不可信任务向共享 Cache 回写。错误四监控只装在生产环境。评测环境为了「测真实能力」把很多控制关掉但模型能力越强评测环境本身越应该被当成高风险生产系统。建议把评测环境分成 normal、capability、adversarial 三级越是为了测极限能力而减少模型层保护基础设施层保护越应该增强不能两边一起减。错误五安全告警只发消息不能暂停 Run。监控只发 Slack 消息不够。高风险告警必须连接 Control Plane能执行pauseRun、revokeEgress、freezeEvidence。可以设置硬规则critical 告警 5 分钟内确认30 分钟内无法证明是假阳性就暂停 Run、吊销凭据、保留证据。错误六长期 Credential 进入沙箱。就算网络完全隔离内部 Credential 仍然可能造成横向移动。用短期、任务级 Capability Token绑定 Run、Purpose、Resource、TTL。即使泄漏影响面也被压缩。6. 把出口审计接进你的评测流水线断网只是起点不是终点。真正要验证的是六层边界Workload Isolation、Network Isolation、Credential Isolation、State Isolation、Monitoring、Safe Stop。TaoToken 统一 Key 通道解决的是出口可见和凭据收敛的问题Egress Gateway 和审计日志解决的是间接出网的问题工具白名单和存储命名空间解决的是状态隔离的问题。如果你正在搭评测沙箱建议先把 API Keys 和接入文档过一遍确认 Key 的权限模型能绑定到 Run 维度然后用模型对话入口快速验证通道是否通长期跑编码类或 Agent 类评测的话Coding Plan 更适合做持续集成。配置骨架可以直接从上面的config.toml和settings.json开始改先跑通五步验证再逐步收紧策略。