Red Hat OpenShift Virtualization Reference Implementation#

The on-premise reference implementation uses Red Hat OpenShift Virtualization as the managed workspace substrate for Secure Agent Workspace. Each user receives a single-user VM hosted on Red Hat OpenShift, accessed through enterprise SSO and a trusted access broker. The local endpoint remains a presentation surface; agent execution, policy enforcement, enterprise-tool access and audit occur inside the managed VM boundary.

This implementation is intended for enterprises that need on-premise control of agent workspaces, integration with existing Red Hat OpenShift operations, and a path from near-term managed VM controls to stronger runtime-level policy enforcement.

_images/secure-agent-workspace-openshift-reference-shape.png

Figure 7 Red Hat OpenShift Virtualization Reference Implementation Shape#

The Phase I and Phase II subsections below project the same maturity progression onto Red Hat OpenShift Virtualization. The baseline and in-runtime control surface is taken as given; each table names only the Red Hat OpenShift-specific primitives — CRDs, operators, integration points — that realize each control on this substrate.

Reference Shape#

The baseline deployment consists of:

  • Red Hat OpenShift Virtualization hosting one persistent Linux or Microsoft Windows VM per user. Each VM is a single-tenant workspace.

  • Red Hat OpenShift GitOps / Argo CD managing VM profiles, namespace configuration, network policy, egress controls, policy-release metadata and supporting platform services. Git is the source of truth for policy intent; GitOps reconciles platform desired state.

  • NFS-backed shared storage for user workspace persistence, policy bundles, image artifacts or shared enterprise data where appropriate.

  • Trusted access broker for SSO-backed, short-lived, auditable user sessions into the workspace.

  • Network boundary controls using Red Hat OpenShift-native primitives such as NetworkPolicy, EgressFirewall, EgressIP, routes and approved ingress paths.

  • Agent runtime inside the VM, initially using standard coding or knowledge agents, with a path to OpenShell or equivalent runtime sandboxing.

  • Policy distribution channel where GitOps publishes approved policy-release metadata and signed policy bundles are mounted or fetched read-only by the workspace.

  • OCSF-compatible audit path for workspace lifecycle events, broker sessions, policy-release activity and runtime/tool events.

GitOps Policy Model#

GitOps is the control plane for authoring, review and release. It should not be treated as the only enforcement mechanism.

The recommended pattern is:

_images/secure-agent-workspace-gitops-policy-model.png

Figure 8 GitOps Policy Model — End-to-End Policy Flow#

Red Hat OpenShift ConfigMaps can be useful for small bootstrap metadata, such as active policy channel, release version, bundle path, hash and signature reference. They should not be the primary policy-bundle transport for large or frequently changing runtime policy. Kubernetes ConfigMaps have size limits, and OpenShell itself currently has a tighter practical serialized policy size limit than the ConfigMap ceiling.

For runtime policy refresh, the stronger pattern is a small in-VM policy agent that watches an approved release pointer, validates the signed bundle, and applies it through the runtime’s policy API. In OpenShell terms, dynamic network policy should be applied through openshell policy update or openshell policy set, rather than assuming that a changed mounted YAML file is itself the enforcement boundary.

Phase I: Deployable Managed VM Controls#

Phase I is deployable with standard Red Hat OpenShift Virtualization and enterprise operations practices.

Controls include:

  • One VM per user, no shared agent process space.

  • Approved VM images only.

  • Workspace lifecycle through a portal or API.

  • SSO-backed access broker with short-lived sessions.

  • Default-deny network egress with an enterprise-defined allowlist.

  • GitOps-managed VM profiles and platform policy.

  • Human review gates before writes to systems of record.

  • Centralized workspace lifecycle and access audit.

In this phase, policy enforcement primarily lives at the workspace perimeter: identity, VM lifecycle, network reach, image governance and human approval.

Phase II: Runtime-Enforced Agent Policy#

Phase II adds an in-VM runtime sandbox such as OpenShell.

Controls include:

  • Signed policy bundles.

  • Runtime verification of active policy.

  • Hot update of dynamic network policy where supported.

  • Credential proxying so raw secrets do not enter the agent process.

  • Routed inference through approved endpoints.

  • Filesystem and process scoping.

  • Per-tool or per-request enforcement.

  • Runtime policy status reported back to the platform.

This phase is additive. It does not replace the Phase I controls; it makes the agent’s runtime behavior enforceable below the prompt layer and closer to the actual tool-call boundary.

Storage Notes#

NFS is suitable as the primary shared storage layer for the on-premise implementation when used carefully:

  • Use NFS for workspace persistence, shared artifacts and versioned policy bundles.

  • Mount policy bundles read-only into VMs.

  • Use immutable release directories rather than in-place mutation.

  • Publish a small current pointer or release manifest, then atomically advance it.

  • Include hash and signature verification before applying policy.

  • Avoid relying only on filesystem change notification for policy reload; use polling plus checksum validation or a platform-driven reload signal.

A typical layout:

_images/secure-agent-workspace-nfs-storage-layout.png

Figure 9 NFS storage layout for policy bundles and workspace persistence#

Operating Invariants#

The on-premise implementation should preserve these invariants:

  • The endpoint attaches; it does not execute autonomous work.

  • The VM is the user’s managed workspace and primary isolation boundary; one VM per user.

  • The Git policy repo is the source of truth for policy intent.

  • GitOps reconciles platform desired state.

  • Runtime policy must be signed, versioned and auditable.

  • The agent must not be able to grant itself broader policy.

  • Secrets should live behind a credential proxy or external secret boundary, not directly inside the agent process.

  • Workspace state is recoverable; authoritative work flows back to enterprise systems (Git, tickets, docs, object storage) via brokered services (workspace state is local and ephemeral relative to enterprise systems).

  • Operators retain a kill switch through the Red Hat OpenShift lifecycle API: revoke SSO, stop VM, remove route, rotate policy, or rebake image.

Why This Matters#

Red Hat OpenShift Virtualization gives enterprises a proven path to host long-running, single-user agent workspaces on infrastructure they already operate. GitOps gives platform and security teams an auditable release model for VM profiles, network reach and policy channels. OpenShell or an equivalent runtime layer then provides the next step: policy enforcement at the agent/tool boundary.

The result is a practical on-premise Secure Agent Workspace pattern: managed VMs for isolation, GitOps for repeatable operations, NFS-backed storage for durable workspace and policy artifacts, and runtime enforcement for autonomous-agent safety.