AI 智能体正在迅速超越聊天。它们检查代码、运行测试、阅读文档、搜索知识库、查询内部系统，并代表用户运行几个小时。这样不仅可以提高工作效率，还可以让智能体访问企业敏感数据，并能够跨业务系统完成任务和采取行动，从而打造一个安全、可控的环境。
NVIDIA 安全代理工作空间参考设计引入了一种清晰的架构转变：用户的笔记本电脑、浏览器、集成开发环境 (IDE) 或终端充当演示层，而非执行层。智能体执行发生在托管工作空间中，在此工作空间中，身份、网络访问、凭据、运行时策略、审核和人工审核都可以持续执行。
随着 AI 工厂实现企业 AI 的产业化，本参考设计概述了如何为自主智能体构建安全的环境，以便在组织规模上运营。
本文概述了实施安全智能体工作空间参考设计的步骤，以便企业能够为其全体员工提供始终在线的自主 AI 智能体。该架构创建了一个更安全的环境，用于控制智能体行为和网络访问。员工可以使用 AI 完成更高级、更复杂的任务，AI 的工作时间更长，并使用更多的企业工具。
开始使用安全代理工作空间
- 准备
识别智能体工作流所有者和利益相关者。这将为资源需求和访问策略提供依据。为了治理智能体，您需要定义预期行为的范围，并绘制边界以防止意外访问。
I 和 II 阶段的实施基于标准的企业托管 – VM 基准，其中包括配置管理、补丁和漏洞管理、图像治理、SOC 遥测以及重建/ 撤销功能。
- 保护虚拟机外部的边界
实施安全代理工作空间的第一阶段是控制周围的边界：允许哪些人进入、他们如何进入、他们获得的工作空间以及工作空间可以到达哪些服务。在此阶段，VM 充当主要隔离边界，目标是在引入更深层次的运行时控制之前使智能体活动具有可观测性、边界性和可撤销性。
- 调配托管工作空间：为每个用户提供他们自己的安全、由公司管理的虚拟机 (VM) 来执行任务。
- 强制登录: 使用公司的单点登录 (SSO) 控制访问；未经身份验证许可，任何人都不得打开工作空间。
- 锁定网络： 默认情况下，阻止所有互联网流量。仅允许连接到预先批准的特定内部和外部服务。
- 需要人工批准： 确保任何更改系统的智能体操作 (例如合并代码或更新工单) 都必须得到人工批准，而不仅仅是智能体。
- 集中日志记录： 将有关工作空间活动的所有日志发送到一个位置，以便安全团队可以监控可疑行为。
- 在虚拟机中添加运行时安全性
在实施的第二阶段，在工作空间内添加控制，以控制智能体的实际行为。这使得防护更接近工具调用边界：智能体可以读取哪些文件、可以运行哪些命令以及可以访问哪些服务。机密保留在代理之后，策略处于集中控制状态，智能体无法悄无声息地扩展自己的权限。
- 主动沙盒： 在专用运行时 (例如 NVIDIA OpenShell) 中运行智能体，实时观察每个动作。
- 经过签名的安全策略： 使用中央系统准确定义允许智能体执行的操作（例如，智能体可以读取哪些文件），并将这些规则作为经过签名的安全捆绑包发送到工作空间。
- 凭据保护： 请勿直接在工作空间中存储密码或密钥。使用安全代理在后台处理这些密钥，以便智能体永远不会看到原始机密。
- 持续验证： 在智能体执行每个操作之前，自动检查安全规则是否处于活动状态且有效。
图 2. 在安全代理工作空间内
为智能体工作空间设置智能体蓝图
Blueprint 是可重复的工作流模板，可在工作空间之上运行。每个蓝图都配置了目标、所需工具、允许的服务、数据范围、写入权限、审查门和日志记录预期。
他们使用更广泛的工具，并针对其目标用例提供最佳实践示例。之后，智能体开发者会尽可能少地进行修改，以根据需求缩小行为范围。
Blueprint 必须通过以下步骤集成到安全代理工作空间环境中：
- 定义智能体身份： 使用逻辑身份注册智能体，逻辑身份通过 SSO 关联到用户或赞助商。使用委托记录准确定义智能体允许执行的操作。
- 处理机密：切勿对机密进行硬编码。使用凭据代理，以便您的智能体使用短期能力令牌，而不是原始 API 密钥或密码。
- 配置推理： 网关层管理配额、基于角色的访问控制 (RBAC) 和动态速率限制，以确保提供安全且可扩展的推理服务。
- 锁定治理： 设置“爆炸半径”控制。定义哪些操作 (例如合并代码或更改工单状态) 需要在执行前进行人工审核，并确保以开放网络安全架构框架 (OCSF) 格式输出所有日志，以便随时进行审核。
在本地或云端部署安全智能体工作空间
设置工作空间的第一步是选择适用于本地环境的 Red Hat OpenShift 虚拟化，或选择适用于云原生部署的 Microsoft Azure。两者的核心模式相同。每个用户都会收到一个专用虚拟机，而本地端点仅连接到该工作空间。代理执行仍在具有集中式策略、访问控制和审核的受控边界内进行。
部署步骤如下：
1. 为每位用户配置一个工作空间 VM： 为每位用户创建专用的 Linux 或 Windows VM。
2. 建立访问路径：在工作空间前放置可信访问代理。用户应通过企业 SSO 和可审计的短期会话进行连接。端点应仅作为演示表面，不在本地运行自主智能体工作。
3. 定义网络边界: 从默认拒绝出口开始，仅允许已批准的目的地。在 OpenShift 上，使用`NetworkPolicy`、`EgressFirewall`、routes 和已批准的入口路径等基元。在 Azure 上，通过 Azure 防火墙高级版路由出站流量，禁用 BGP 路由传播，拒绝企业 CIDR 访问，并避免任何公共入站路径。
4. 集中管理镜像和 VM 配置文件：仅使用经批准的 VM 镜像。OpenShift 环境应通过 GitOps 管理 VM 配置文件和平台状态。Azure 环境应使用 Packer 构建黄金图像，并通过 Azure Compute Gallery 发布。
5. 使用 GitOps 实现策略意图： 在 Git 中存储 VM 配置文件、网络规则、策略元数据和发布信息。GitOps 应协调所需的平台状态，而签名的运行时策略包则通过受控的发布通道分发。
6. 保护机密和身份流：尽可能将原始机密排除在代理流程之外。Azure 部署应在智能体代码启动前使用工作负载身份联合进行无机密调配、VM 运行时访问的托管身份、私有端点上的 Azure Key Vault 以及窄运行时身份。
7. 集中审核和可观察性：捕获工作空间生命周期事件、代理会话、策略发布、网络允许/拒绝活动以及运行时/工具事件。将日志发送到企业 SIEM 或平台日志堆栈，例如 Azure Monitor、Log Analytics、Microsoft Sentinel 或与 OCSF 兼容的审核路径。
最终状态是一种实用的安全代理工作空间模式：单用户 VM 提供隔离，GitOps 提供可重复的操作，企业身份控制访问，网络策略限制可访问性，运行时执行为自主代理安全添加了更深层次的策略层。
开始在您的企业 AI 工厂中实施安全代理工作空间参考设计。
