NVIDIA Secure Agent Workspace Moves Agent Execution to Managed VMs

NVIDIA published the Secure Agent Workspace Reference Design on June 29, 2026, to govern autonomous agents in enterprise AI factories. The design moves agent execution from user devices into managed workspaces where identity, network access, credentials, runtime policy, audit, and human review are enforced consistently. The user's laptop, browser, IDE, or terminal becomes a presentation layer only.

Perimeter and Runtime Controls

Phase I secures the perimeter around the workspace. Each user gets a dedicated company-managed VM. Access is gated by enterprise single sign-on, so no one opens a workspace without authenticated permission. Network egress defaults to deny, with connections allowed only to pre-approved internal and external services. Any agent action that changes a system, such as merging code or updating tickets, requires human approval. All workspace activity logs go to a central location for security monitoring.

Phase II adds runtime controls inside the VM. The agent runs in an active sandbox, such as NVIDIA OpenShell, that watches every action in real time. A central system defines allowed behaviors, like which files the agent can read, and sends these rules as signed security bundles to the workspace. Credentials are not stored in the workspace; a secure proxy handles keys behind the scenes so the agent never sees raw secrets. Before every agent action, the system automatically checks that the security rules are active and working.

Blueprints and Deployment

Agent blueprints are repeatable workflow templates that run on top of the workspace. Each blueprint defines its goal, required tools, allowed services, data scope, write permissions, review gates, and logging expectations. Developers make minimal modifications to narrow behavior for their use case. Blueprints integrate through agent identity registration tied to the user via SSO, credential proxies that issue short-lived capability tokens, an inference gateway managing quotas and RBAC, and blast-radius governance with logs in Open Cybersecurity Schema Framework format.

Deployment follows the same core pattern on Red Hat OpenShift Virtualization for on-premises or Microsoft Azure for cloud. Each user gets a dedicated VM, and the local endpoint only attaches to that workspace. A trusted access broker sits in front of the workspace, with users connecting through enterprise SSO and short-lived auditable sessions. Network boundaries start with default-deny egress. On OpenShift, primitives include NetworkPolicy, EgressFirewall, routes, and approved ingress paths. On Azure, outbound traffic routes through Azure Firewall Premium, BGP route propagation is disabled, corporate CIDR access is denied, and no public inbound path exists.

Image and VM profiles are managed centrally. OpenShift environments use GitOps for VM profiles and platform state. Azure environments build golden images with Packer and publish them through Azure Compute Gallery. GitOps stores VM profiles, network rules, policy metadata, and release information, reconciling the desired platform state while signed runtime policy bundles distribute through a controlled release channel. Azure deployments use Workload Identity Federation for secretless provisioning, managed identities for VM runtime access, Azure Key Vault over Private Endpoints, and a narrow runtime identity before agent code starts. Audit logs capture workspace lifecycle events, broker sessions, policy releases, network allow or deny activity, and runtime or tool events, sent to the enterprise SIEM or platform logging stack such as Azure Monitor, Log Analytics, Microsoft Sentinel, or an OCSF-compatible audit path.

The end state is a pattern where single-user VMs provide isolation, GitOps provides repeatable operations, enterprise identity controls access, network policy limits reachability, and runtime enforcement adds a deeper policy layer for autonomous-agent safety.