Always-on, Autonomous Agents, Now Safe for the AI Factory#

Enterprises are moving from chat-style assistants to always-on personal agents hat read code, inspect documents, run tests, query systems, draft updates and operate for hours at a time on behalf of an individual employee. That shift creates a new platform requirement: a secure, managed agent workspace for autonomous agent execution.

Secure Agent Workspace gives enterprises a governed place for autonomous agents to run. User endpoints attach, but execution happens in a managed workspace where identity, network access, credentials, runtime policy, audit, and human review constrain what agents can do.

The Secure Agent Workspace Reference Design addresses that requirement to operationalize always-on agents in the AI Factory:

  • The user’s endpoint — browser, terminal, IDE, agent app, remote-desktop client — is a presentation layer, not an execution layer.

  • The agent runtime executes inside a managed remote environment (single-user VM, optionally GPU-accelerated) provisioned through an approved lifecycle, accessed through a trusted broker, contained by a runtime enforcement layer and connected to enterprise systems through governed connectors with human review for sensitive writes.

Local tools are user-interface surfaces; the managed workspace is the execution and policy boundary.

Protecting Against#

  • Accidental writes. The agent updates the wrong ticket, deletes the wrong file, or runs a destructive command without human review.

  • Prompt injection. Instructions hidden in documents, email, tickets, or upstream tool output redirect the agent — even when the user’s prompt is valid.

  • In-VM root compromise. A kernel CVE or local-privilege-escalation inside the workspace VM, but the VM boundary prevents that compromise from directly impacting the user’s host system.

Outcomes#

  • Employees, developers and researchers get a persistent, optionally accelerated workspace where an agent can run indefinitely without binding to a laptop’s network or power state. The workspace ≠ the session.

  • Security teams get identity gates, egress policy, credential isolation, audit logs and human-review controls — and a runtime that enforces them irrespective of how the agent is prompted.

  • Platform teams get a reference pattern they can configure, manage, update, roll back and operate as fleet software and at AI Factory scale - with cost reporting, budget controls and partner-backed enterprise SLAs as offering matures.

Just as the AI Factory industrializes AI for enterprise, this reference design industrializes the environment for autonomous agents within an enterprise AI Factory. It offers the security, auditability, repeatability and performance required for enterprises to unlock the latest wave of productivity and innovation from agentic AI.

Maturity Model — Phase I and Phase II#

Phase 1 provides controls outside the VM. Phase 2 adds in-VM runtime enforcement.

Both phases sit on top of the standard enterprise managed-VM baseline — configuration management, patch and vulnerability management, EDR / anti-malware, image governance, SOC telemetry, rebuild / revocation. Call this Phase 0. Phase 0 is the workload-protection foundation any enterprise-managed VM is expected to meet; it is necessary for Secure Agent Workspace but not sufficient on its own, and not a Secure Agent Workspace differentiator — what follows is what Phase I and Phase II add on top.

Table 1: Phase I and Phase II Maturity Model

Phase

Inside the VM

Outside the VM

Phase I — Agent in a managed VM

A coding or knowledge agent (e.g. Codex, or an enterprise-built agent) running in a single-user managed workspace. Enterprise-governed VM image, includes configuration management and EDR for host-level workload protection.

Workspace-perimeter controls — SSO + access broker, image governance, network-boundary allowlist, human review for writes, audit logging at the workspace edge.

Phase II — Signed policy enforced runtime sandbox

Phase I + runtime sandbox (NVIDIA OpenShell or equivalent) enforcing a signed policy bundle at runtime action boundaries, including tool calls: deny-by-default in-runtime egress, credential proxying, routed inference, filesystem and process scoping.

Phase I + central signed-policy authoring, distribution, and attestation chain — policy authored centrally, signed, distributed to workspaces, attested at boot, verified per-call.

Phase I is the substrate that the customer can deploy today. Phase II adds the in-runtime enforcement layer that survives an in-VM-OS compromise. The phases are additive; Phase II does not replace Phase I.

_images/secure-agent-workspace-phase-i-ii.png

Figure 1 Phase I and Phase II — the adoption path#

Both phases include the standard enterprise VM-management baseline — configuration management and endpoint detection and response (EDR) — for host-level workload protection on the managed VM itself. This is the same workload-protection tooling the enterprise already runs on its other managed VMs; Phase II’s in-runtime enforcement sits above this baseline, not in place of it.