Reference architecture for secure agent workspaces in enterprise AI factories

The NVIDIA Secure Agent Workspace Reference Design recommends that AI agent execution run inside managed, enterprise workspaces rather than on user endpoints such as laptops, browsers, or IDEs. This approach enables consistent enforcement of identity, network access, credentials, runtime policy, auditing, and human review, while allowing employees to delegate longer-running, more complex tasks to autonomous agents.

Why this matters

Agents today do more than chat: they inspect code, run tests, read documents, query knowledge bases and internal systems, and operate for hours on a user’s behalf. That increases productivity but also creates risks—access to sensitive data or the ability to perform actions across business systems. The reference design defines how to structure a secure, governed runtime environment at organizational scale.

Steps to implement the Secure Agent Workspace

Preparation

• Identify agent workflow owners and stakeholders to define resource needs and access policies. Governing an agent requires predefining expected behaviors and boundaries.
• Implementations in phases I and II build on a standard enterprise managed-VM baseline that includes configuration management, patch and vulnerability management, image governance, SOC telemetry, and rebuild/revocation capabilities.

Secure the perimeter outside the VM (Phase I)

This phase focuses on controlling the perimeter around each workspace: who can enter, how they enter, which workspace they receive, and what services that workspace can reach. The VM acts as the primary isolation boundary; the aim is to make agent activity observable, bounded, and revocable before adding deeper runtime controls.

• Provision managed workspaces: provide every user with a company-managed virtual machine (VM).
• Enforce login gates: require enterprise single sign-on (SSO) for access; a workspace must be opened only with authenticated permission.
• Lock down the network: block internet traffic by default and allow connections only to specific, pre-approved internal or external services.
• Require human approval: any agent action that changes systems (for example merging code or updating tickets) must be approved by a human.
• Centralize logging: send all workspace activity logs to a single place for security monitoring.

Add runtime security inside the VM (Phase II)

Phase II adds controls inside the workspace to govern the agent’s actual behavior—what files it can read, which commands it can run, and which services it can access. Secrets remain behind a proxy, policy remains centrally controlled, and the agent cannot silently broaden its permissions.

• Active sandboxing: run the agent inside a dedicated runtime (such as NVIDIA OpenShell) that monitors every action in real time.
• Signed security policies: use a central system to define exactly what the agent may do and distribute those rules as signed bundles to the workspace.
• Credential protection: avoid storing passwords or raw keys in the workspace; use a secure proxy that issues short-lived capability tokens.
• Continuous verification: automatically validate that security rules are active and enforced before each agent action.

Create agent blueprints for the workspace

Blueprints are repeatable workflow templates that run on top of the workspace. Each blueprint is configured with its goal, required tools, allowed services, data scope, write permissions, review gates, and logging expectations. They represent best practices for a use case and are minimally customized by agent developers. Blueprint integration steps include:

• Define agent identity: register the agent with a logical identity tied to the user or sponsor via SSO; use a delegation record to specify allowed actions.
• Handle secrets: never hardcode secrets—use a credential proxy so agents operate with short-lived capability tokens instead of raw API keys or passwords.
• Configure inference: place a gateway layer to manage quotas, role-based access control (RBAC), and dynamic rate limiting for a secure, scalable inference service.
• Lockdown governance: implement blast-radius controls, require human review for sensitive actions, and export logs in Open Cybersecurity Schema Framework (OCSF) format for audit readiness.

Deploying on-premises or in the cloud

The reference design recommends Red Hat OpenShift Virtualization for on-premises deployments and Microsoft Azure for cloud-native deployments. The core pattern is the same: each user gets a dedicated VM and the local endpoint only attaches as a presentation surface; agent execution remains in a managed boundary with centralized policy, access control, and auditing. Deployment steps:

1. Provision one workspace VM per user: create a dedicated Linux or Windows VM for each user.
2. Establish the access path: put a trusted access broker in front of the workspace; users connect via enterprise SSO and short-lived, auditable sessions. The endpoint should act only as a presentation surface.
3. Define the network boundary: start with default-deny egress and allow only approved destinations. On OpenShift, use NetworkPolicy, EgressFirewall, routes and approved ingress paths. On Azure, route outbound traffic through Azure Firewall Premium, disable BGP route propagation, deny corporate CIDR access, and avoid public inbound paths.
4. Manage images and VM profiles centrally: use approved VM images only. OpenShift environments should manage VM profiles and platform state through GitOps; Azure environments should build golden images with Packer and publish them via Azure Compute Gallery.
5. Use GitOps for policy intent: store VM profiles, network rules, policy metadata, and release information in Git. GitOps reconciles desired platform state while signed runtime policy bundles are distributed through a controlled release channel.
6. Protect secrets and identity flows: keep raw secrets out of the agent process. Azure deployments should use Workload Identity Federation for secretless provisioning, managed identities for VM runtime access, Azure Key Vault over Private Endpoints, and a narrow runtime identity prior to agent code start.
7. Centralize audit and observability: capture workspace lifecycle events, broker sessions, policy releases, network allow/deny activity, and runtime/tool events; send logs to enterprise SIEM or platform logging stacks such as Azure Monitor, Log Analytics, Microsoft Sentinel, or an OCSF-compatible audit path.

Final pattern

The resulting Secure Agent Workspace pattern uses single-user VMs for isolation, GitOps for repeatable operations, enterprise identity for access control, network policies to limit reachability, and runtime enforcement to add a deeper layer of safety for autonomous agents.

Next steps

Enterprises can use the Secure Agent Workspace Reference Design to implement secure, governed environments that enable autonomous, always-on AI agents at scale while reducing data exposure and supporting auditability.