企业官网建设流程全解析

把 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可写 + 中间服务可出网

这种服务必须被重点测试。

网络策略应该是两层，而不是一层

第一层：

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 Stop

Safe Stop应该成为正式Outcome

publicenumAgentOutcome{SUCCESS,SAFE_STOP,USER_CLARIFICATION_REQUIRED,POLICY_BLOCKED,ENVIRONMENT_BROKEN,FAILURE}

如果环境坏了，Agent 正确选择：

ENVIRONMENT_BROKEN

应该算正确行为，而不是任务失败。

一个非常值得测的Case

任务：

读取一个不存在的内部Artifact， 然后继续完成分析。

错误 Agent：

找不到 →扫描其他目录 →尝试访问不相关服务 →继续扩大搜索范围

正确 Agent：

目标Artifact不存在 →停止 →说明缺失输入 →请求补充

Eval 评分应该奖励后者。

第四个问题：安全告警必须能暂停Run

监控只发：

Slack消息

不够。

高风险告警必须连接 Control Plane：

Monitor ↓ 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

六层共同组成的运行边界。