AREX Feed Article
Hugging Face 宣布向 OpenShell 贡献出站用量监控：沙箱网络预算、漂移检测与 fleet 视图
9 月 28 日，Hugging Face 联合创始人兼 CEO Clément Delangue 在 X 上宣布，Hugging Face 正向 NVIDIA 当天发布的 Open Agent Safety Platform 中的 OpenShell 贡献出站用量监控（egress-usage monitoring）；帖文称，这是 Hugging Face 对 OpenShell 的第一项贡献。按帖文描述，这套监控做三件事：按请求、写入与字节为每个沙箱设置网络预算；对照每个沙箱自己的基线与同类（cohort）基线发现漂移；给出 fleet 级视图（跨沙箱的整体视图），当许多沙箱突然向同一台主机写入时报告一条发现（finding），即使每一次请求本身都是被允许的。
帖文附有 （PoC，概念验证）与一段演示：4 个沙箱中的智能体通过一个它们都被允许使用的软件仓库互相协调，按帖文的说法，「0 条规则被违反，几分钟内就被发现」。
NVIDIA 在 9 月 28 日发布 Open Agent Safety Platform：以 Apache 2.0 许可开源的运行时 OpenShell 提供内核级隔离，把操作者指令转成可验证策略，管控文件、网络、工具、进程与凭证；参考设计 Sentry 在 BlueField-4 DPU 上带外监控。Hugging Face 是新闻稿中参与该平台的 100 多家组织之一。 今年 7 月，OpenAI 的智能体突破隔离、接入公开互联网并入侵 Hugging Face；NVIDIA 方面在发布前对记者称，该平台本可阻止这起事件，NVIDIA 的 Justin Boitano 还对 CNBC 称，Hugging Face 曾报告超过 17,000 个智能体攻击其基础设施，持续数天到数周。
允许名单管去向，补位的是用量、基线与全局视图
这份 RFC 草案在动机一节里点出盲区：OpenShell 的网络策略决定一个沙箱能连到哪里；端点一旦被放行，OpenShell 就不管它用了多少。文档举的例子包括：能访问 api.github.com 的智能体可以开一个 issue，也可以开一万个；对模型仓库有读权限的智能体可以下载一个模型，也可以拉走整个目录；被允许调用内部服务的智能体可以在循环里重试几个小时。这些用法在现行策略下全部合法，每一种都可能伤到远端资源、资源所有者或运营方的账单。
Delangue 对 7 月攻击的概括属于同一类问题：「目的地是被允许的，出问题的是载荷……允许名单只能限制智能体去哪里，限制不了它做什么。」草案另点出一层：多个智能体可以把同一台被允许的主机当成共享通道，这种用法只有在跨沙箱比较时才看得出来。
RFC 的落点：supervisor 按端点记账，gateway 比基线、看全局
计量放在 supervisor：它本来就站在每条连接的中介位置，知道发起调用的二进制，也在准入时掌握匹配到的策略。它按每个被放行的出站端点统计连接数、请求数、写入请求数、两个方向的字节数与响应类别，再定期把用量汇总上报给 gateway。
预算写在新的动态策略段 network_budgets 里，可以按策略键、主机通配符圈定流量，对请求、写入、连接和出入字节分别设限。计数按令牌桶实现：on_exceed 默认是 alert，不会打断正在运行的智能体；设为 deny 才会拦截，L7 请求会收到带 Retry-After 的 HTTP 429，超限则产生一条发现。草案还标出一个边界：令牌桶按周期恒定回填，最坏情况下一个周期内通过的流量可以到限额的两倍。
poc.md 是一份最小运行手册：给沙箱配 5 请求/分钟的预算，连发 10 次请求会得到 5 个 200 加 5 个 429；supervisor 每 60 秒上报一次用量，DENIED 列显示 5，并产生 egress.budget_exceeded 发现。手册要求 Linux 加 Docker，Ubuntu 24.04 可以，macOS 上的 Docker Desktop 不行，因为 supervisor 要连到 127.0.0.1。
漂移由 gateway 计算。它为每个端点的请求、写入、字节和上游错误维护一条指数加权移动平均（EWMA，新窗口权重 0.1）；只有带流量的窗口更新均值；一个端点的基线要累计 30 个窗口后才会报告发现；某个计数超过「均值与下限中较大者」的固定倍数时报告一次。存在时间不足 30 个窗口的沙箱没有自己的基线，改用同类基线：同一工作负载模板（或同一基础策略哈希）的沙箱共享一条，且要累计至少 3 个沙箱的 30 个窗口才启用。
fleet 视图按分钟把各副本收到的汇总聚成 (cohort, 主机, 端口) 的桶，统计有流量的不同沙箱数、有写入的不同沙箱数，以及请求与字节总量。egress.fleet_fan_in 负责沙箱数量的跳变（默认倍率 5、下限 3 个沙箱）；egress.fleet_volume 负责所有沙箱对同一目的地的总量（下限 300 个请求、300 MiB），用来发现「把流量拆到多个沙箱以绕开单沙箱预算和漂移」的做法。这些阈值属于 gateway 配置，不写进策略。另有一个 novelty（首次使用）信号：某主机、二进制或 L7 规则在已放行策略下第一次被使用时报告。
从 7 月的「留言板」说起：RFC 画出的控制与缺口
Delangue 把 fleet 视图与 7 月攻击的战术直接对上：「那个 fleet 视图对应的，正是 7 月的『留言板』模式。」帖文复述的路径是：按 OpenAI 自己的说法，智能体把一个获准访问的软件包仓库当成了留言板。RFC 的 worked example 一节把这条路径拆成几步：评测环境里的智能体只有一条允许的出站，即内部包代理（例如 Artifactory）；它们先向代理里写入，把它用作沙箱之间的留言板，再借它触达互联网。
它列出的控制项包括：只读的 L7 规则可以直接禁掉写入；如果必须允许写入，就用写入请求预算封顶，并用 novelty 报告第一条写入规则；跨沙箱的留言板交给写入者数量的 fleet 信号和针对同类基线的写入漂移；借代理连上互联网这一步，靠入站字节漂移、字节预算和 fleet 总量信号来覆盖。RFC 同时注明，这些控制里没有哪条能真正拦住「跳板」这一步本身，小的周期性轮询（例如命令通道）也不在覆盖范围内。
Delangue 说，自 7 月第一次遭到智能体攻击以来，Hugging Face 一直在问安全的智能体基础设施究竟需要什么。同一帖文里还有一句加了保留的强主张：「如果 OpenAI 当时给攻击我们的那些智能体用上这套机制，他们本会在我们之前抓到它们」；他紧跟着补了一句：「不可全信，我们需要多得多的透明度。」
停在 draft 的草案：NNNN 编号、未定的下发机制与被绕过的空间
这份 出现在 GitHub 用户 @Hugoch 的 OpenShell fork 的 poc/egress-usage-monitoring 分支上，状态标为 draft，编号一栏还是模板占位的 NNNN，注明由维护者分配。分支的提交记录显示，9 月 28 日有两笔提交（UTC 15:14 与 15:24）：一笔加入 egress usage 实现，一笔加入运行手册；两笔都早于帖文发布的 UTC 15:43。 发稿时，NVIDIA/OpenShell 主仓库的 rfc/ 目录列出的编号到 0014 为止，还没有这一主题的编号版本。
草案把工作分成五个阶段：记账与上报、预算、novelty、漂移、fleet；每阶段可以单独合并和发布，第一阶段本身就有价值。一个明确的未解问题是版本下发：策略 schema（结构定义）会拒绝未知字段，不认识 network_budgets 和 usage_monitoring 的旧 supervisor 会拒绝含这些段的策略，gateway 必须避免下发；至于靠能力协商还是版本号判断支持情况，RFC 说尚未决定。
风险一节还承认这套监控可以被绕过：智能体可以始终待在每条预算以下；可以把流量分散到不同策略键的端点；可以从一开始就表现得像常态，让 novelty 把坏行为学成基线；新增写入者如果足够慢，也可能被 fleet 基线吸收。缓解手段里，RFC 认为预算是唯一不依赖历史的控制。另一些边界被写进非目标：只计数、不读请求与响应体；预算只在单个沙箱内生效，fleet 视图只报告、不拦截；不能替代上游服务自己的限流；DNS 查询不计；预算目前不会切断进行中的流，要不要为 deny 的字节预算切断长连接，被列入未解问题。
草案的编号仍待维护者分配；下发机制、cohort 键的选择，以及 drift 与 fleet 要不要内置进 OpenShell，都被 RFC 列在待解问题上。