云原生社区如何应对代理安全边界

云原生社区正在把“代理能做什么”从提示词和应用代码，向运行时、网络和凭据边界下沉。2026年11月10日，CNCF 公告提到 OpenShell 与 Agent Substrate 两个新的 Sandbox 项目：前者强调代理运行时的策略治理，后者强调大规模、零信任的沙箱执行。它们共同回答的不是“怎样让代理更聪明”，而是“代理需要能力时，怎样只给它被批准的那一小段能力”。

CNCF 公告：https://www.cncf.io/announcements/2026/11/10/cncf-hits-major-milestones-with-global-community-growth-record-industry-investment-and-a-new-generation-of-projects-to-build-ai-systems-in-production/

OpenShell 官方文档：https://docs.nvidia.com/openshell/

Agent Substrate 官方代码：https://github.com/agent-substrate/substrate

这条消息值得关注的地方，是安全边界开始从单个 Agent SDK 的“自觉遵守”变成基础设施的“强制执行”。不过，CNCF 页面仍将两个项目列为 Sandbox，公告也没有承诺所有场景的合规性、性能或生产适用性。实际采用时，应把它们看成安全能力的组成部分，而不是一张自动生效的安全证明。

这次公告把哪些能力放到了云原生层

OpenShell 的官方说明把风险拆成文件、网络、进程和模型供应商凭据四类控制面：文件访问受限于声明的路径，外联请求受网络策略约束，进程受到非特权身份与系统调用限制，凭据只在得到授权的端点上解析。它的关键变化是把策略写成可审查、可版本化的声明，而不是把一组密钥直接塞进 Agent 的环境变量。

Agent Substrate 处理的是另一种规模问题。它把每个 Actor 当成不可信工作负载，使用 gVisor 或微型虚拟机隔离计算、网络和存储，并用快照把大量处于等待状态的 Actor 映射到较小的 Worker 池。官方仓库还强调了每个 Actor 的短期身份、默认拒绝网络和“沙箱里没有凭据”的设计。换句话说，它将“能否安全运行”与“能否高密度调度”放进了同一个基础设施平面。

两者并不是简单的替代关系。OpenShell 更像围绕代理行为建立的策略与网关层，Agent Substrate 更像承载大量不可信 Actor 的隔离运行时。一个团队可以先按威胁模型选择隔离能力，再决定策略由哪一层执行；不要只因为项目名称中出现了“安全”就把所有风险归并给同一个组件。

先把代理调用设计成可审查的接口

如果调用方只提交“请访问这个工具”，策略层很难判断它要访问什么资源、以什么身份访问、结果要流向哪里。更稳妥的接口至少应把一次请求拆成五类字段：

这里最重要的取舍是“凭据引用不等于凭据内容”。调用方只传递一个经过授权的凭据引用，策略网关在确认目的地、动作和身份后，才把真实凭据注入到批准的出站请求中。这样即使 Agent 被提示词注入，沙箱内也没有一段可以直接打包带走的长期密钥。

错误模型要让调用方知道下一步怎么做

安全接口不能只返回一个模糊的 403。调用方至少要能区分三种结果：请求被批准，可以继续；请求被拒绝，必须修改资源或策略；请求需要审批，应该暂停并等待人工或控制面决策。无论最终采用 HTTP、gRPC 还是消息协议，都建议保持稳定的错误类别，让上层 Agent 不会把“策略拒绝”误判成“网络故障”而无限重试。

package policy

import "fmt"

type Decision struct {
	Allowed bool
	Pending bool
	Code    string
	Message string
}

func ContinueOrExplain(d Decision) error {
	// 只有明确允许才能执行外部动作；未知状态不能默认为允许。
	if d.Allowed {
		return nil
	}
	// 待审批不是普通失败，调用方应保存上下文并等待策略系统回调。
	if d.Pending {
		return fmt.Errorf("policy pending: %s", d.Message)
	}
	// 拒绝码要稳定，便于客户端区分策略问题与瞬时网络问题。
	return fmt.Errorf("policy denied (%s): %s", d.Code, d.Message)
}

上面的 Go 片段只是说明调用方如何消费决策结果，不是 OpenShell 或 Agent Substrate 的官方 SDK 示例。真正落地时，拒绝信息不能包含令牌、内部文件路径或过多策略细节；审计系统可以保存更完整的事件，但返回给 Agent 的信息应足够它修正请求，又不会泄露防护规则。

默认拒绝、边缘执行和短期身份应当同时出现

代理安全边界通常不是一个开关，而是三层配合：

1. 沙箱层：限制文件、进程、系统调用和网络栈，阻止代理越过运行时边界。
2. 策略层：把资源、动作、目的地和凭据引用组合成可审查规则，并对未知请求默认拒绝。
3. 身份与出口层：为 Actor 提供短期身份，在沙箱外完成凭据注入、DLP 检查或出站授权。

OpenShell 文档把网络策略描述为可以在运行时热加载，而文件与进程限制在沙箱创建时锁定；Agent Substrate 则把出站网关放在不可信 Actor 之外。这种设计对兼容性很关键：应用不必把每个供应商的鉴权细节写进 Agent，只需要调用稳定的能力接口，策略系统负责把不同后端映射到允许的出口。

但边缘策略也带来新责任。网关不可用时，是让请求快速失败、排队，还是切换到只读能力，必须在接口契约中提前决定；策略更新期间，既有连接是否继续有效，也要有明确答案。没有这些约定，所谓“默认拒绝”可能只会演变成难以排障的间歇性故障。

用版本化策略处理兼容和回滚

社区项目进入 Sandbox 后，最值得工程团队借鉴的不是某个单一命令，而是把安全控制当作可演进的基础设施 API。建议为策略增加版本号和变更原因，审计事件记录 Actor 身份、资源、动作、目的地、决策结果与策略版本；新字段采用向后兼容的可选形式，未知字段由策略服务拒绝或忽略的规则要事先写清楚。

发布新策略时，可以先进入观察或待审批状态，只记录将被拒绝的请求，不立刻改变生产流量。确认误杀范围后再切换为强制拒绝，并保留上一版策略的快速回滚入口。对于凭据、网络和进程这三类高风险变化，回滚也应被审计，而不是由单个开发者在沙箱中临时修改。

不要把 Sandbox 误读成完整安全结论

当前公开资料至少留下了四个需要单独验证的边界。第一，Sandbox 是项目治理阶段，不等于所有组件都已达到相同成熟度；第二，运行时隔离能限制文件、网络和进程访问，但不能替你判断业务数据是否应该被模型看到；第三，默认拒绝并不能消除供应链、镜像、工具服务器和策略本身的风险；第四，沙箱外的出口网关仍需要监控、密钥轮换、数据分类和人工审批。

因此，团队在评估代理平台时，应该先画出“能力—边界—证据”三列清单：代理究竟要读写什么，哪一层强制限制，发生允许或拒绝时能留下什么证据。只有这三列都能回答，才值得继续比较隔离后端、调度密度和接口性能。

相关问题

OpenShell 和 Agent Substrate 是同一种产品吗？不是。前者重点是代理运行时的策略与治理，后者重点是大规模不可信 Actor 的隔离、身份、网络与生命周期调度；它们可以在不同层协同。

默认拒绝会不会让代理完全不能工作？不会，但需要把常用能力预先描述为资源、动作和目的地，并为确实需要扩展权限的请求设计审批或回滚路径。

沙箱里没有凭据后，代理如何访问模型或工具？由沙箱外的策略出口在确认授权后完成请求绑定和凭据注入，代理只获得调用结果，不直接持有长期密钥。

这两个项目现在就适合所有生产系统吗？不能这样推断。CNCF 公告和项目文档提供了设计方向与当前能力，具体生产适用性仍需结合威胁模型、隔离后端、合规要求、故障策略和组织运维能力评估。