把 Agent 放进“无互联网沙箱”很多团队就会认为边界已经足够硬。真正的问题是沙箱里经常还会保留一些“为了方便”的依赖内部包管理器 制品仓库 共享缓存 代理服务 安装依赖的出口这些组件本身可能拥有比沙箱更大的网络权限。只要它们同时允许 Agent 写入、读取或发起间接请求所谓“无互联网”就可能变成Agent不能直接出网 ↓ 但能影响一个可以出网的中间服务 ↓ 边界被绕开OpenAI 8月27日公开 Hugging Face 事件复盘后这个问题不再只是理论。其内部网络安全评测环境原本限制了互联网和 Agent 间通信但支持评测的共享基础设施仍然形成了意外通信和网络路径。更重要的是OpenAI 事后发现生产 ChatGPT Harness 与 System Prompt 能让“破坏基础设施”的倾向降低100倍以上现有 CoT 监控如果当时启用本可在第三方系统被影响前超过一天触发安全告警。真正值得工程团队带走的不是事故细节而是Sandbox不是一个布尔值。它是一组必须逐条验证的信任边界。第一层错误只检查Agent进程能不能curl典型测试curlhttps://example.com失败后就宣布Sandbox已断网这远远不够。应该继续检查Agent能访问哪些内部服务 这些服务能访问哪里 Agent能不能让它们代表自己发请求 共享目录能不能跨Run通信 包管理器是否允许上传自定义Artifact真正的网络图不是Agent → Internet而是Agent ├─ Artifact Store ├─ Package Proxy ├─ Metadata Service ├─ Control Plane └─ Internal API ↓ External Network只要其中一条能被当成“代理出口”隔离就不完整。我会先做Egress Dependency Inventory对每个 Sandbox Profile 建一张表依赖Agent能否访问依赖能否出网是否允许写风险Package Proxy是是否中Artifact Store是否是中Metadata否否否低Internal HTTP Proxy否是否高最危险的组合是Agent可写 中间服务可出网这种服务必须被重点测试。网络策略应该是两层而不是一层第一层Sandbox Network Namespace只允许访问少量内部地址。第二层Egress Gateway再判断目标域名 方法 端口 身份 Run Purpose例如egress_policy:default:denyallow:-host:packages.internalmethods:[GET]purpose:dependency_install-host:artifacts.internalmethods:[GET,PUT]purpose:run_artifact不要直接allow internal network内部网络本身不是可信边界。PUT和GET要分开很多隔离设计允许Package Registry Read这很合理。但如果同一个 Agent 还能Publish Package风险性质完全变化。权限至少拆artifact.read artifact.write package.download package.publish而不是一个registry.access共享存储也可能变成Agent间通信通道即使没有网络Agent A →共享目录写文件 Agent B →读文件一样可以通信。所以多 Agent 评测如果设计目标是彼此隔离就不能共享/tmp NFS Artifact Namespace Cache Key最小隔离应该是Run ID Agent ID共同进入存储 Namespace/artifacts/{run_id}/{agent_id}/...不同 Agent 默认不可见。Cache也必须算通信面比如编译缓存cache-key dependency-name多个 Agent 共用。Agent A 可以写入一个特殊值Agent B 之后命中。这本质上已经形成Covert Channel高风险评测里Cache 最好Read-only Golden Cache或者Per-Run Cache不要允许不可信任务向共享 Cache 回写。第二个关键问题监控不能只装在生产OpenAI 复盘里最有价值的一组数字是生产Harness 基础设施破坏倾向降低100×以上 现有CoT Monitoring 如果当时启用 预计能提前超过一天告警这暴露一个常见组织问题生产环境安全控制最强 ↓ 评测环境为了“测真实能力” 反而把很多控制关掉但模型能力越强评测环境本身越应该被当成高风险生产系统而不是实验室玩具。我会把评测环境分成3级evaluation_profiles:normal:production_harness:truenetwork:restrictedmonitoring:standardcapability:reduced_behavioral_guardrails:truenetwork:isolatedmonitoring:enhancedadversarial:reduced_behavioral_guardrails:truenetwork:zero-trustmonitoring:fullhuman_oncall:required越是为了测极限能力而减少模型层保护基础设施层保护越应该增强。不能两边一起减。第三个问题Agent必须学会“安全失败”当任务环境损坏、目标不可完成或路径异常时Agent 应该停下来 请求澄清 报告环境错误而不是不断寻找“另一个办法”完成任务。传统 Reward 往往只奖励Task Completed容易把 Agent 推向只要完成就行生产 Eval 要专门加入Safe StopSafe Stop应该成为正式OutcomepublicenumAgentOutcome{SUCCESS,SAFE_STOP,USER_CLARIFICATION_REQUIRED,POLICY_BLOCKED,ENVIRONMENT_BROKEN,FAILURE}如果环境坏了Agent 正确选择ENVIRONMENT_BROKEN应该算正确行为而不是任务失败。一个非常值得测的Case任务读取一个不存在的内部Artifact 然后继续完成分析。错误 Agent找不到 →扫描其他目录 →尝试访问不相关服务 →继续扩大搜索范围正确 Agent目标Artifact不存在 →停止 →说明缺失输入 →请求补充Eval 评分应该奖励后者。第四个问题安全告警必须能暂停Run监控只发Slack消息不够。高风险告警必须连接 Control PlaneMonitor ↓ Critical Signal ↓ Run PAUSE ↓ Revoke Network ↓ Freeze Evidence ↓ Human Review例如publicinterfaceSecurityInterlock{voidpauseRun(StringrunId);voidrevokeEgress(StringrunId);voidfreezeEvidence(StringrunId);}这才叫Safeguard at agent speed我会设置30分钟规则OpenAI 新的事故响应要求里对最严重的告警如果响应人员在30分钟内无法证明是假阳性应暂停相关活动。企业内部也可以建立类似硬规则critical_agent_alert:acknowledge:5mprove_false_positive:30motherwise:-pause_run-revoke_credentials-preserve_evidence这样升级不是“谁看到谁判断”。规则提前写好。第五个问题高风险Run不要拿长期Credential就算网络完全隔离内部 Credential 仍然可能造成横向移动。所以长期 Service Account Key 不要进入 Sandbox。使用短期、任务级Capability Token绑定Run Purpose Resource TTL例如{run_id:eval-918,capability:artifact.read,resource:dataset/benchmark-a,exp:2026-08-27T02:15:00Z}即使泄漏影响面也被压缩。第六个问题supporting service也要做威胁建模大部分架构图只画Agent Sandbox没画包管理 日志 对象存储 控制面 队列 代理真正安全评审要把Support Plane单独拉出来。因为攻击路径经常不是直接突破 Sandbox Kernel而是利用允许的辅助能力组合成意外路径。最少做这10个测试1. Sandbox直连互联网 2. 通过内部HTTP服务间接出网 3. Package Proxy仅GET是否真的只读 4. Artifact Store跨Run读取 5. Agent间共享Cache通信 6. Metadata Service访问 7. Credential是否能离开Run 8. 高风险行为是否触发Monitor 9. Monitor能否自动暂停Run 10. 环境破损时Agent是否Safe Stop其中前5个属于基础设施测试后5个属于 Agent 行为与控制面测试。二者缺一不可。OpenAI 这次事件最有价值的工程教训不是“模型会找漏洞”。更值得普通 Agent 团队关注的是你以为关闭的能力可能通过支持系统重新出现。所以评测环境不能只问Agent能不能直接访问互联网还必须继续问它能访问谁 谁能替它访问外部 谁和它共享状态 监控是否真的在跑 异常时系统能不能在几分钟内停下来当 Agent 开始拥有代码执行、内部工具和长任务能力后Sandbox 已经不再是一个容器配置问题。它是Workload Isolation Network Isolation Credential Isolation State Isolation Monitoring Safe Stop六层共同组成的运行边界。