AI agent正在迅速走出对话框，开始干实事了。查代码、跑测试、读文档、搜知识库、查询内部系统……而且一干就是好几个钟头——全程替用户盯着、跑着、操作着。生产力确实上来了，但风险也跟着来了：agent能接触到敏感的企业数据，还能跨系统执行任务、采取行动。所以，一个安全、可控的运行环境，就成了必须解决的根本问题。
NVIDIA最近推出的Secure Agent Workspace参考设计，带来一个清晰的架构思路：用户的笔记本、浏览器、IDE或终端，只作为“显示层”，而不是“执行层”。agent真正的执行，发生在一个受管理的、专门的工作区里。在这个工作区，身份认证、网络访问、凭据管理、运行时策略、审计记录以及人工审核，都能被统一、持续地执行。
说白了，这就像是给企业AI工厂里的自主agent，专门建了一个带围栏的“专用跑道”。本文就来拆解一下，怎么把这个参考设计落地，让企业可以为所有员工安全地开放这些永不掉线的AI agent。架构的核心，就是创造一个更安全的环境，把agent的行为和网络访问都管起来。这样，员工才能放心地让AI干更复杂、更高级的活，而且一干就是几个小时，用上更多企业内部的工具。
第一步：准备工作，定好规矩
- 准备阶段
先搞清楚谁是agent工作流的负责人和相关方。这直接决定了后续的资源需求以及访问策略怎么定。要管好一个agent，前提是得定义清楚它“应该”干什么，同时划出边界，防止它跑到不该去的地方。
需要说明的是，这里讨论的阶段I和阶段II，都是建立在标准的企业托管VM基线之上的。也就是说，配置管理、补丁和漏洞管理、镜像治理、SOC遥测数据，以及重建/撤销这些基础能力，都是已经就位的。
第二步：守住虚拟机的“外围”
实现安全agent工作区的第一阶段，核心是管好外围：谁可以进来、怎么进来、进来后拿到什么样的工作区、这个工作区能访问哪些服务。在这个阶段，虚拟机本身就是主要的隔离边界。目标是让agent的所有行为都可观测、可限定、可撤销——先把这些基础打牢，后面再引入更细粒度的运行时控制。
- 分配托管工作区：给每个用户分配一台专有的、由公司管理的虚拟机，用来跑任务。
- 强制登录关口：用公司的单点登录系统来控制访问。没有经过认证授权，谁也别想打开工作区。
- 锁定网络：默认情况下，所有互联网流量全部阻断。只允许连接那些事先审批通过的内部和外部服务。
- 要求人工审批：涉及修改系统的操作，比如合并代码或更新工单，必须由人来批准，不能让agent自己说了算。
- 日志集中化：把所有工作区的活动日志都发送到一个统一平台，方便安全团队监控异常行为。
第三步：给虚拟机内部加上“运行时”安全锁
进入第二阶段，要在工作区内部加装控制措施，直接管住agent的实际行为。这把安全防护拉到了更靠近“工具调用”的那层边界：agent能读哪些文件、能跑哪些命令、能访问哪些服务。密钥隐藏在袋里后面，策略由中央控制，agent无法偷偷给自己提升权限。
- 主动沙箱化：让agent跑在一个专门的运行时环境里（比如NVIDIA OpenShell），实时监控它的每一步操作。
- 签名安全策略：用中央系统明确定义agent的权限范围（例如能读哪些文件），然后将这些规则以签名、安全的包的形式下发到工作区。
- 凭据保护：不要把密码或密钥直接存在工作区里。用安全的袋里来处理这些密钥，agent永远看不到原始的敏感信息。
- 持续验证：在agent每次执行动作之前，自动检查安全规则是否仍在生效、是否正常工作。
搭建agent蓝图：可复用的工作流模板
蓝图，就是可以重复使用的工作流模板，跑在工作区之上。每个蓝图都配置好了目标、所需工具、允许访问的服务、数据范围、写入权限、审核关卡以及日志要求。
蓝图会用到最大范围的工具，并针对目标用例展示最佳实践。agent开发者在此基础上，只需做最小幅度的修改，就能把行为收紧，满足自己的需求。
要让蓝图顺利接入安全agent工作区环境，需要执行以下几步：
- 定义agent身份：为agent注册一个逻辑身份，通过SSO与用户或发起方关联。再弄一份袋里记录，精确说明agent的权限。
- 处理密钥：永远别硬编码密钥。用凭据袋里，让agent通过短生命周期的能力令牌工作，而不是直接使用API密钥或密码。
- 配置推理服务：一个网关层负责管理配额、基于角色的访问控制以及动态限流，确保推理服务安全且可扩展。
- 锁定治理：设置“爆炸半径”控制。定义清楚哪些操作（比如合并代码、修改工单状态）需要人工审核后才能执行，同时确保所有日志都以OCSF格式输出，随时准备接受审计。
部署方案：本地部署还是上云，都行
搭建工作区，开头要选好平台：本地环境用Red Hat OpenShift Virtualization，云原生环境用Microsoft Azure。但核心模式是一样的：每个用户一台专用虚拟机，本地终端只连接到这个工作区。agent始终在一个受管理的边界内执行，边界内有统一的策略、访问控制和审计。
具体部署步骤：
1. 为用户分配工作区VM：为每个用户创建一台专用的Linux或Windows虚拟机。
2. 建立访问路径：在工作区前面放一个可信的访问袋里。用户通过企业SSO连接，会话是短生命期且可审计的。终端只作为展示界面，本机上不运行任何自主agent工作。
3. 定义网络边界：从默认拒绝所有出站流量开始，只放行已审批的地址。在OpenShift上，用`NetworkPolicy`、`EgressFirewall`、路由和审批过的入站路径。在Azure上，通过Azure Firewall Premium路由出站流量，禁用BGP路由传播，拒绝企业CIDR地址访问，并避免任何公开入站路径。
4. 镜像和VM配置集中管理：只使用经审批的VM镜像。OpenShift环境通过GitOps管理VM配置和平台状态。Azure环境用Packer构建黄金镜像，并通过Azure Compute Gallery发布。
5. 用GitOps管理策略意图：将VM配置、网络规则、策略元数据和发布信息都存储在Git中。GitOps负责把平台状态调整到期望状态，而签名的运行时策略包则通过受控的发布渠道分发。
6. 保护密钥和身份流：尽可能不让agent进程接触到原始密钥。Azure部署使用Workload Identity Federation实现无密钥配置，用托管身份控制VM运行时访问，通过Azure Key Vault（走Private Endpoints）管理密钥，并在agent代码启动前赋予一个范围很小的运行时身份。
7. 审计和可观测性集中化：捕获工作区生命周期事件、袋里会话、策略发布、网络允许/拒绝活动以及运行时/工具事件。将日志发送到企业SIEM或平台日志栈，比如Azure Monitor、Log Analytics、Microsoft Sentinel，或者任何一个兼容OCSF格式的审计通道。
最终得到的是一个务实的Secure Agent Workspace模式：单用户VM提供隔离，GitOps保证操作可重复，企业身份控制访问，网络策略限制可达性，运行时强制执行则在自主agent的安全方面多加了一层深度防护。
现在就可以在你们的企业AI工厂里，动手实现Secure Agent Workspace参考设计了。