AI Agent 安全：OpenShell 与硬件控制层分别管什么

给自主 Agent 写上“不要访问项目外的文件”，不等于文件系统会拒绝它的越界请求。前者需要模型理解并遵守，后者需要执行环境真正拦截操作。

NVIDIA 的 Agent 安全参考架构提供了一个值得拆解的思路：除了讨论 Agent 应获得多少权限，还要追问，谁来执行限制，控制机制放在哪里，Agent 能不能修改它？

下面按这份参考架构解释各层职责。产品能力保留为厂商描述，设计审查建议属于架构分析，不代表该方案已经通过独立安全验证。

NVIDIA 将策略阻断、程序故障、缺少工具、指令含糊，以及长时间求解列为 Agent 可能偏离任务的情境。它据此提出：不能期待处于这些情境中的 Agent 完全自我约束。

这是一种厂商设计判断，不意味着每个 Agent 遇到阻碍都会越界。但它指出了一个工程问题：当执行计划失败时，系统不能只依赖模型自行判断下一步是否合规。

例如，可以用一个假设场景检查设计：Agent 无法调用获准工具后，尝试启动另一个进程。此时，“只能使用指定工具”的提示词能表达意图，却不能代替进程创建权限的检查。

两类机制承担的责任不同：

NVIDIA 提出的带外执行原则，是把控制机制放在 Agent 内部及其可触及范围之外。关键不只是另加一个检查模块，而是避免 Agent 能修改策略、停用检查，或绕过检查进入另一条执行路径。

因此，评估安全边界时，需要沿着实际操作链路检查，而不能只阅读系统提示词。

按 NVIDIA 的描述，OpenShell 为每个 Agent 提供沙箱，将操作者的要求转成可验证策略，并对文件、网络、工具、进程和凭证的访问设置限制。它既在运行前检查这些边界，也在执行过程中实施约束。

这里的 AI agent sandbox，重点是给执行环境划定边界。Agent 可以在边界内制定计划，但不应拥有自行扩大边界的权限。

所谓 agent policy enforcement，也就是策略强制执行，关注的是实际请求能否通过检查。例如，“只处理项目资料”还需要进一步明确：

这些是审查自身设计的问题，并非某个版本的配置说明。不能把“将要求转成策略”理解为写一句自然语言，就自动得到完整、正确的权限配置。

这一层的核心价值，是让限制不再完全依赖模型每次都作出正确判断。不过，沙箱也需要接受检查：策略文件、运行时配置和管理接口是否与 Agent 隔离？如果 Agent 能改掉限制，边界仍然不牢固。

运行时负责限制资源访问，硬件层则进一步回答：如果主机环境本身不再可信，观察和控制还能放在哪里？

先看职责，避免把几个产品名称理解成同一种防护：

按该参考架构的描述，DOCA 让 BlueField 的安全基础可编程，并将其与运行时策略连接。它关联 Agent 交互、策略决策，以及工具和数据访问，形成带有上下文的活动记录。

这种关联有助于审查“发生了什么，以及当时依据什么策略作出决定”。但记录能力与阻断能力不能混为一谈，日志本身不等于请求已经被拒绝。

硬件位置也有明确前提。在 NVIDIA 描述的特定 Vera Rubin POD 拓扑中，每个计算托盘包含一颗 BlueField-4 数据处理器，位于节点通向模型的唯一路径上。NVIDIA 将其描述为与主机隔离、处于 Agent 可触及范围之外，可持续观察行为并实时执行安全策略的基础设施层。

这里的“唯一路径”很重要：控制点只有覆盖相应路径，才有机会约束经过它的操作。不能据此推断其他硬件部署中的全部文件、工具或网络访问也受到同样覆盖。

NVIDIA 还将 Sentry 定位为可选附加层，而非 OpenShell 的必需组成部分。所供材料没有独立验证这些机制能降低多少风险，也不足以证明其优于其他方案。

对学习或开发自主 Agent 的人，更有用的做法，是画出一条真实调用链：模型作出决定后，请求经过哪些组件，最终由谁访问资源。再逐项检查：

如果你正在美国申请 AI/ML Engineer、Platform Engineer 或 Security Engineer 等相关岗位，也可以用这套问题解释项目设计：具体保护什么资源，检查发生在哪里，哪些限制经过测试。没有实施过的硬件层，应写成架构评估，而非部署经验。

最终应形成一张可检查的边界图：Agent 负责规划，运行时约束访问，独立控制层在其覆盖路径上观察和执行。每一层都要写清适用条件，尤其是它管不到什么。