AI 智能体技术栈中的安全定位

随着 AI 智能体的能力不断增强并能在更长的时间跨度内运行，在其驱动的应用中建立安全性和信任变得越来越重要。基于与 NVIDIA OpenShell、智能体开发者、开源项目以及整个生态系统中合作伙伴的合作，NVIDIA 的 AI 安全与保障团队提供了他们对新兴智能体技术栈的看法 —— 包括每一层的作用以及安全应在何处实施。

最近的报告强调了为什么安全管理的位置至关重要。在今年夏天的几周内，OpenAI、Anthropic 和英国 AI 安全研究所都报告称前沿智能体的运行超出了预期边界。报告的行为包括：开辟一条意外路径逃出实验室环境进入开放互联网、未经授权访问其他公司的系统、以及采取涉及人员和基础设施的未经批准的行动。这些案例涉及降低模型安全防护情况下运行的长程智能体。但它们指出了同样的设计挑战：让智能体能够创造性地解决问题并追求复杂目标的能力，也有助于它们找到原始指令无法预见的路径。

NVIDIA 最近的研究强调了智能体技术栈中 Harness 层的重要性。借助智能体变异算子 (AVO)，研究人员在 ARC-AGI-3 上获得了 100% 的分数。ARC-AGI-3 是一种交互式推理基准测试，将智能体放置在没有指令、明确规则或既定目标的陌生环境中。了解更多 AVO 研究的信息。

本文梳理了新兴智能体技术栈的主要层级 —— 模型、Harness、Meta-Harness、安全运行时 (如 OpenShell) 和推理基础设施 —— 并解释了每一层如何帮助降低风险。您还将了解到，随着这些层的功能变得更加强大、可组合性越来越强，哪些安全属性变得至关重要，包括权限应位于何处、访问应如何设定范围，以及运行时如何限制和记录智能体的操作。

AI 智能体的行为和基础设施管理

保护智能体的安全不需要重塑安全性。数十年的系统安全性提供了持久的原则，包括最小权限、纵深防御、隔离、显式授权和可审计性。挑战在于确定其在智能体技术栈中的应用位置。

提示词、模型安全防护和 Harness 逻辑共同塑造了智能体可能要做的事情，但它们不会围绕智能体的功能构建硬边界。这种区分导致了两种不同类型的管理方式：引导智能体的行为管理和限制其权限的基础设施管理。

行为管理影响智能体的行动

模型和智能体提出行动建议，Harness 引导它们。模型、智能体和 Harness 共同解释目标、解决歧义问题并提出行动建议。Harness 是自然的管理点：它拥有循环、上下文、工具和会话，并且可以根据运行人员的意图来引导行为。这种引导很有价值，但在这一层实施的每项管理仍然取决于模型将如何表现。

基础设施管理决定智能体能做什么

最终权限属于智能体运行所在的环境。该环境会持有身份认证、执行策略、限制故障、记录发生的情况，在给定相同的已批准策略和经过验证的状态下，每次都能做出相同的授权决策。它不预估智能体可以做什么，它决定了智能体可以做什么。

Harness 引导智能体尝试做什么。基础设施管理智能体能做什么。两者都是必要的；但只有一个具有权威性。

基础设施层面的强制执行并非无错。这意味着经过批准的策略和经过验证的配置会产生可重复的结果，并且智能体无法选择是否遵守。策略可能仍然是错误的，外部结果也可能仍然是不确定的。

映射安全管理

此划分映射到了开源生态系统已经趋同的层级上：

表 1：AI 智能体技术栈的功能层、职责和代表性技术

这些层描述了功能角色。一个产品可以组合多个角色，一个部署也可能会将一个角色分割到多个服务中。在这里，每一层都会命名一种责任。安全边界由智能体无法绕过的效果路径定义。

模型提供智能；Harness 将该智能转化为智能体；运行时决定了该智能体被允许做什么。

Harness 层是一个频谱层，而非一个固定的类别。Codex 和 Claude Code 是有主见的 Harness，而 Pi 和 DeepSeek Harness (DSH) 则将更多 Harness 暴露为可编程基板。通过 Cordis，DSH 实现了可以组合和替换为插件的核心行为。这种可编程性使得 Harness 难以提供安全保障：一个被设计为可修改的层，无法可靠地对其自身修改实施管理。另一种选择 —— 依赖 Harness 逻辑来确保安全性 —— 是对有关模型行为的假设进行编码，而这些假设会随着模型的改进而过时。

范围狭窄的凭证可以限制潜在危害，但将原始凭证置于智能体无法触及的地方，则会创建一个由环境强制执行的更强大的边界。

在启动前建立 AI 智能体运行时边界

模型、Harness、运行时、策略和推理部署越来越多地被独立选择。只有当运行时的保障机制在不管其上方组件是什么都成立时，这种方法才有效。这意味着必须在智能体启动时建立安全边界。

编排器要求 OpenShell 创建运行时并执行策略和治理。选定的 Harness 在该运行时内部启动，其插件、模型上下文协议 (MCP) 进程、工具和其他模型导向代码均在同一边界内运行。子智能体会接收受委托的子运行时，并受限于它们无法超越的权限上限，而编排器则会在受自身策略约束的运行时内运行。

这种方法不同于将运行时视为 Harness 在运行后即可调用的另一种工具。智能体可以拒绝调用的管理并不是有效的安全管理。

智能体技术栈中常见的安全漏洞

许多智能体技术栈都有同样的缺陷：授权决策可能会受到智能体或其读取的不可信数据的影响。

1. 边界不清。规则分散在提示词、模型、智能体、Harness、运行时和基础设施中，因此很难找到权威版本。
2. 过度访问。智能体接收的是长期的、通常是长效的凭证或超出了当前任务的需求的权限。
3. 不可信数据作为管理手段。文档、消息、工具结果和内存可以重定向操作，而无需作为指令授权。
4. 不受控的外部影响。允许的 API 可以移动数据、创建计算或触发超出预期管理范围的影响。
5. 复合故障。智能体会进行委托、共享内存和调用对等节点，因此一个错误可以快速级联。

审计证据不完整。审批模糊不清，访问权限撤销缓慢，记录不足以解释事件或支持恢复。

可执行的智能体安全性设计规则

五项设计规则有助于将安全决策排除在智能体的管理之外。

1. 上层建议；下层决定。任何模型、智能体、Harness、工具或内存系统都不能授予自己权限。
2. 权威策略位置。将策略保持在基准线以下。基准线上方的策略感知规划是有用的，但仅是建议。
3. 检查每个影响。管理每个文件、进程、网络请求、API 调用、数据操作、资源分配、通信和设备操作。
4. 即时访问。凭证和功能应范围窄、有效期短且易于删除。
5. 隔离和恢复。隔离每个智能体、快速撤销访问权限、进行恢复并保留记录。

适用于智能体的分层安全模型

与 OSI 模型类似，此智能体技术栈为每层分配一项作业和一个清晰的接口。较高的层可以改变，而无需重新定义其下方的管理层。

安全边界的工作原理

只有在每个请求都得到一致评估的情况下，边界才有效。三个条件使其成为可能。

1. 将边界上方的每个组件视为不可信组件。它可能是错误的、妥协的或对抗性的，其请求本身没有任何权限。
2. 使边界下方的管理具有权威性。这些层将每个请求与一个身份绑定，应用策略并强制执行决策。
3. 仅使用风险信号来降低权限。分数异常等信号可能会触发更严格的管理，但它们不能授予额外的访问权限。

每一个改变外部状态的操作都必须通过边界下方的策略和执行层。任何允许第 5-7 层绕过这些管理的路径都是架构缺陷。

适用于智能体工作负载的四个安全配置文件

这四个配置文件均使用相同的技术栈、边界和接口。每种配置文件都会根据授予的权限、潜在影响和对抗行为的可能性实施不同的管理。

表 2：适用于 AI 智能体工作负载及其所需管理的四个安全配置文件

重要提示。红队智能体的生产访问权限应该是特殊的，并且比普通生产智能体的访问权限更窄，而不是更宽。

智能体安全管理如何随着风险的增加而变化

随着智能体获得更多的权限，其行为的潜在影响的增加，应加强对五个方面的管理。

1. 更窄的权限。随着风险的增加，授权期限应该缩短。
2. 最新决策。在更接近每次操作时重新评估策略。
3. 更强的监督。为高影响力的工作增加实时监督。
4. 更快的恢复。为访问撤销、隔离和回滚制定计划。
5. 独立的证据。在安全边界下方保留不可变记录。

每个风险级别的安全要求

尽管随着风险的增加，管理变得更加严格，但以下安全要求应在每个配置文件中保持一致。

1. 智能体永远不能授予自己访问权限。在智能体流程之外且其无法把控的范围内实施管理。这在每一层都适用。
2. 每个范围内的高影响力效果都会经过一个执行点。检查发生在执行操作的系统中。
3. 系统安全失效：缺失或过时的管理选择预先批准的更安全状态。对于物理和可用性关键型系统，这种状态可能需要受控运行，而不是突然停止。
4. 安全声明保持在范围内。说明所涵盖的确切路径、作出的假设以及技术栈之外的排除项。

通过市场学习帮助塑造 AI

无论您是构建 AI 模型、部署 AI 系统、运行云基础设施、进行安全研究，还是制定治理和标准，您的观点都可以帮助塑造 AI 社区从事件中学习的方式。

探索 NVIDIA OpenShell 以了解安全的私有运行时如何隔离自主智能体并执行安全策略。

浏览并为开放安全 AI 联盟的共享 AI 发现交换 (SAFE) 提案做出贡献，该提案概述了一个社区框架，用于从 AI 事件和未遂事故中学习。