- NVIDIA 的新平台把 OpenShell 运行时与可选的 Sentry/BlueField-4 带外控制层分开：OpenShell 可脱离 BlueField-4 部署，Sentry 则被定位为宿主之外的参考系统设计。厂商所称毫秒级隔离尚无独立测试，Sentry 的价格、供货和正式采购时间也未披露。
- Baseten 宣布以 Blaxel Carbon 承载 OpenShell，但 Carbon 仍为私有预览，按地区和 workspace 逐步开放；其快照与分叉能力也被官方文档标为私有预览并明确不建议用于生产。
- DigitalOcean 把常驻凭据移出模型和沙箱，由 Action Gateway 在执行时代理；其策略被描述为面向 OpenShell schema 设计，这表明相似控制结构正进入云服务，但不能据此认定已经形成互认证或统一标准。
策略执行离开模型与提示词
9 月 28 日，NVIDIA 发布 Open Agent Safety Platform，将其描述为由 OpenShell 开源软件与 Sentry 参考系统设计构成的 Agent 安全架构。官方产品页把模型护栏与运行时控制分开：提示词、模型护栏和 Agent 框架影响系统试图做什么，而 OpenShell 在 Agent 进程之外执行允许或拒绝规则。OpenShell 可以在受支持的本地、企业机房、云和 Kubernetes 环境运行，不要求同时部署 BlueField-4，并支持开放模型、闭源模型和多种 Agent 工作流；仓库同时将 Kubernetes 部署路径标为实验性，仍可能出现不稳定与破坏性变更。
OpenShell 仓库采用 Apache-2.0 许可。项目说明其通过内核机制约束每个文件访问、系统调用和网络连接，并在策略变更应用前用形式化验证检查新增权限；真实凭据不暴露给 Agent，只在前往获准端点的请求上注入。仓库列出的支持范围包括 Linux、Apple Silicon macOS，以及仍属实验性的 Windows WSL2；容器或虚拟化路径包括 Docker、Podman 和宿主虚拟化。当天发布的 v0.1.2 还修复了网络 supervisor、sandbox orphan reaper 性能并更新文档。
对企业落地而言，安全验收对象由提示词规则扩展到可执行的文件、进程、网络、工具和凭据边界，使策略是否真正生效可以在模型之外被记录和检查。这仍是项目方公布的设计与实现范围；公开材料没有提供独立安全审计、完整运行开销、误报率或跨行业生产验证，因此不能把“进程外执行”直接等同于不可绕过或风险已经消除。
带外硬件形成可选的第二个信任域
NVIDIA 将 Sentry 定义为运行在 BlueField-4 DPU 上的实时看门狗：它位于 Agent 和宿主软件之外，观察活动并执行策略。官方称异常 Agent 可在毫秒级被隔离，这一数字来自厂商材料，尚不是独立测试结果。产品页同时确认 OpenShell 可不依赖 BlueField-4 运行，因此软件运行时和带外硬件控制层是两种不同的部署状态，不应合并成一项必选能力。
Arm 的同日说明把计算需求分为运行 Agent 和保护 Agent 两部分，并称 BlueField-4 由 NVIDIA Grace 与 64 个 Arm Neoverse V2 核心驱动，可在宿主之外形成独立基础设施环境。今天的材料没有给出 Sentry 参考系统的外形、功耗、内存容量与带宽、价格、供货、企业支持等级或正式可采购时间，也没有提供首 token 延迟、吞吐和并发数据；这些模型服务指标不能由核心数量或控制平面描述推导。
对企业落地而言，独立控制平面提供了一条在宿主或工作负载失陷时仍可能保留监测与隔离能力的架构路径，也会把安全评估扩展到 DPU、固件、遥测、证明链和故障处置。当前证据只能说明参考设计及其分层关系，不能把 Sentry 写成已经量产交付的新硬件，也不能把伙伴说明当作第三方安全基准。软件单独部署与硬件增强部署需要分别记录其可用性和验证状态。
云端沙箱采用同一结构，预览状态仍决定可用性
同日，Baseten 以发布伙伴身份宣布，最新一代 Blaxel sandbox 可承载 OpenShell。其 Carbon 基础设施采用 microVM、专用 IPv6，并提供更广的内核能力面与运行时执行控制；手动 snapshot 和 fork 用于保存环境状态与派生运行实例。Baseten 称从 snapshot 到生产的路径可在毫秒级完成，但这是厂商表述，公开材料没有给出可复核的硬件、负载、并发或样本条件。
Blaxel 文档给出了更严格的状态边界：Carbon 仍处于 private preview，按地区和 workspace 逐步开放，并非所有环境的默认选项；当前也不同时具备 Agent Drive、firewalling 和 dedicated egress IP。snapshot 与 fork 同样标为 private preview，文档明确不建议在生产中使用。功能存在、预览可申请和适合生产是三个不同结论。
对企业落地而言，把策略运行时、隔离沙箱与快照恢复结合，可以让任务状态和故障处置成为运行底座的一部分，而不是仅靠 Agent 自行恢复。不过预览覆盖范围、缺失的网络与存储控制、快照一致性和恢复时间仍会直接影响是否能进入生产验收；厂商所称毫秒级路径不能替代针对真实工作负载的稳定性与数据完整性证据。
凭据代理让密钥不进入 Agent 环境
DigitalOcean 当日公布 Managed Agents 的凭据架构：每个 Agent 运行在隔离的 harness session 中，模型、文件系统和 sandbox 不持有常驻 API key 或 token。需要访问受控文档、数据库或其他系统时，请求由 Action Gateway 代理，凭据只在执行时用于相应调用；刷新授权也由网关处理，而不是把 refresh token 交给 Agent。每个工具连接还可绑定 Agent 所代表的具体 actor。
同一材料描述了 VPC 层的零出站 microVM 防火墙、固定为非 root 的进程身份、默认拒绝的文件与工具规则，以及 allow/deny 决策审计。DigitalOcean 的准确表述是这些权限和网络控制面向 OpenShell 的开放策略 schema 设计，而不是已经通过 OpenShell 兼容认证。相似结构在多个平台出现，尚不能证明策略语义、审计字段、凭据生命周期和撤销行为可以跨供应商无损迁移。
对企业落地而言，凭据代理把模型推理权限、Agent 身份和业务系统授权拆成可分别约束的层次，能够减少长期密钥直接暴露在提示词、内存或工作目录中的机会。它仍依赖代理自身的身份映射、作用域、刷新、撤销、日志完整性和网络路径；“Agent 看不到密钥”也不代表经授权工具调用不会造成业务副作用或数据外泄。跨平台采用之前，互操作与故障边界仍需公开证据。
后续观察
- Sentry 是否会公布正式可采购时间、价格与供货范围，以及独立攻击测试、策略执行开销、误报率和隔离时延的完整条件。
- Carbon 何时从私有预览进入正式可用，并补齐 Agent Drive、firewalling、dedicated egress IP 及适合生产的 snapshot/fork 保证。
- OpenShell、云端沙箱和凭据代理之间能否形成可移植的策略、审计与凭据生命周期规范，而不只是采用相似的架构表述。
来源与核验
本文由英科铸数基于所列公开资料编辑撰写。事实与数据以原始来源为准；“对企业落地意味着什么”为英科铸数结合企业客户场景所作的编辑分析，不构成对第三方产品的背书。
← 返回每日观察