Security And Governance Model#

The security posture has three layers: baseline managed-workspace controls (the workspace perimeter), runtime sandbox controls (kernel-level enforcement), and signed-policy governance (the auditable and attestable control surface above the runtime). Each layer adds enforcement the layer beneath cannot provide on its own.

The three layers map to the Phase I / Phase II maturity model: baseline managed-workspace controls anchor Phase I; runtime sandbox controls and signed-policy governance are the additive Phase II step that turns the workspace from “managed VM” into “in-runtime policy-enforced agent platform.” The specific controls in each layer are summarized below:

_images/secure-agent-workspace-security-envelope.png

Figure 7 Secure Agent Workspace Security Envelope: three layers, each necessary#

The Secure Agent Workspace security envelope. Each layer is necessary; strip any one and the others stop being sufficient. A published data-classification policy is a precondition to turning autonomous agents on.

Control Surface — Contracts, Implementation and Integration Boundaries#

The control surface decomposes into six areas, grouped as two structural control points — the workspace and the runtime, where enforcement physically happens — and four cross-cutting contract surfaces consumed across them. The named contracts in parentheses below — signed policy bundle, runtime verifier, projection into runtime controls, credential mediation, and common audit — describe policy authoring, signing, and distribution to runtime-enforcement layers as a universal pattern applicable across vendors and enterprises; identity / delegation is consumed from enterprise IAM / ODIS rather than owned. Each area names what Secure Agent Workspace implements, what it consumes from enterprise IAM and platform layers, and what remains an integration dependency — so partner contributions know where to plug in without redefining the contract surfaces.

Table 6: Control Surface Contracts

Control area

Expected contracts

Implemented in the reference design

Consumed from enterprise IAM / platform

Integration dependency

Workspace control

Workspace image manifest; workspace lifecycle API (create / stop / rebake / revoke); per-workspace kill switch

Workspace VM provisioning pipeline; lifecycle API; perimeter detection; kill switch

OS image base layer; access broker; enterprise PKI for image signing

Platform management/virtualization; CMDB / provisioning portal

OpenShell / runtime control

Sandbox lifecycle API; per-call policy attestation API; in-runtime egress/write decision API; routed-inference broker contract

OpenShell runtime layer — sandbox, policy engine, in-runtime egress enforcement, routed-inference broker

—

Host-kernel security primitives (LSM-level enforcement; namespace and process isolation); container or microVM runtime

Signed-policy control

Policy bundle format; verifier / decision API; signing key trust chain; rollback semantics

Policy authoring + signing service; per-call decision evaluator; channel-based distribution

Enterprise PKI for signing roots

Policy distribution channel (Git, OCI registry); upstream signed-policy framework when adopted

Identity / delegation control

User/sponsor identity (SSO / OIDC); workspace identity (attested); logical-agent registration; short-lived runtime credential lifetime + binding

Workspace identity binding; logical-agent registration; runtime credential minting and per-sandbox / per-call rotation

Enterprise SSO / OIDC IdP; group membership; access-broker session

ODIS as the spec stabilizes; identity broker; TPM / SEV-SNP / TDX attestation provider

Credential mediation

Credential proxy contract (Authorization-header rewrite, capability semantics); secret-store boundary; HSM trust chain

Credential proxy in Plane 6 (capability issuance, header rewrite); regulated-profile out-of-VM hosting

Enterprise secret store (Vault)

Per-provider credential adapters; HSM-backed broker for the regulated profile

Audit / revocation control

OCSF audit event shape; revocation propagation semantics; rollback contract

OCSF audit emission from all three security layers; revocation receiver wired to the workspace lifecycle API

Enterprise SIEM; SSO revocation endpoint

OCSF schema version alignment; SIEM correlation rule pack

Baseline Managed-Workspace Controls#

  • Require a distinct elevated-autonomy entitlement, separate from standard developer access.

  • Require enterprise SSO and access-broker login. No alternative path. The broker is the trust boundary.

  • Use short-lived sessions with browser-driven re-auth.

  • Run agent tools inside the managed workspace. Approved unattended-agent modes are explicitly permitted in Secure Agent Workspace and explicitly not approved on the local laptop.

  • Use approved workspace images and profiles only. Provisioned through the portal; no user-owned images, no out-of-band VM creation.

  • Allowlist enterprise-service access at the network boundary. Default-deny for non-allowlisted destinations.

  • Endpoint Detection & Response (EDR) on the workspace VM. Standard enterprise workload protection — anti-malware, anomalous-behavior detection, in-VM telemetry to the SOC. This is the VM-management baseline that complements, but does not substitute for, Phase II’s in-runtime policy enforcement against autonomous agents.

  • Require human review before writing to systems of record.

  • Log workspace lifecycle, access and session activity.

Publishing a data-classification policy is a precondition before turning autonomous agents on.

Production Autonomous-Runtime Controls#

These are the required attributes of the runtime enforcement layer, stated independent of implementation. They form a stacked model: in-sandbox containment (reference implementation OpenShell — open-source) and a separate credential / authorization proxy. The requirement is the attributes below, not a specific product.

  • Kernel-level in-sandbox containment covering all agent operations — not just shell tool calls, but hooks, MCP servers, and skills.

  • Deny-by-default egress, enforced at the platform network boundary (Phase I) and inside the sandbox (Phase II).

  • Credential proxy and isolation — A layer separate from the agent that performs tool-level authorization and credential injection, so raw secrets never enter the agent (it receives short-lived, scoped capabilities). It is a concentrated trust point, bounded deliberately: secrets stay in the enterprise secret store (Vault), capabilities are least-scope per the delegation record, every use is OCSF-audited, and authority is revocable per delegation record. Co-located with the runtime by default; hosted outside the VM (HSM-backed) for stricter threat models — including root inside the VM.

  • Routed inference.

  • Filesystem and process controls — writes confined to the workspace; reads outside the workspace denied by default; writes to configuration, hook, and MCP files denied regardless of path, since they convert into persistent code execution.

  • Signed policies and controlled release channels.

  • OCSF-compatible audit logs to SIEM.

  • Incident response runbook.

  • Rollback path for runtime, connector and policy releases.

  • Identity / delegation enforcement. Per-engagement delegation record defining task, scope, tools, duration, and approval mode; runtime credential minting and per-sandbox / per-call rotation; delegation-record revocation. The agent operates with a policy-defined subset of the end-user’s permissions, enforced at the runtime layer — not as a separate authority.

Threat Model — What If the In-VM OS Is Compromised?#

A specific question CISOs ask: if a Linux kernel privilege-escalation vulnerability (Copy-Fail-class CVE; LPE primitives that yield root on the workspace OS) is chained inside the sandbox to gain access to the VM host OS, what stays standing? The threat model treats the in-VM OS as partially trusted — hardened, patched, monitored, but not assumed unbreakable — and stages defenses accordingly.

Table 7: Threat Model — Residual Controls by Compromise Level

Compromise level

Phase I residual control

Phase II residual control

Agent-level compromise — prompt injection, scope creep, or other lethal-trifecta vectors

Network-boundary allowlist; human review of writes; OCSF audit

All Phase I controls + runtime sandbox in-runtime deny-by-default + credential proxy + per-call policy attestation

Unprivileged user-space exploit inside the agent process

Workspace process limits; network-boundary allowlist

Sandbox process and syscall scoping; credential proxy still holds secrets

Root-on-OS inside the workspace (kernel CVE / LPE, or direct local privilege such as passwordless sudo)

Workspace-perimeter detect and respond: EDR and OCSF telemetry drives SIEM detection (anomalous egress, anomalous lifecycle calls); response is kill-switch via the workspace lifecycle API; image rebake; centralized SSO revocation of the affected user

Above plus: signed-policy attestation prevents tampering with the policy bundle the runtime enforces; the credential proxy and routed inference broker can be hosted such that the in-VM root does not yield the secrets they hold; OCSF telemetry continues to flow from the trust-boundary endpoints

Hypervisor / control-plane compromise

Out of Secure Agent Workspace’s scope — handled by the IaaS / on-prem virtualization provider’s own controls

Same

Confidential compute (optional Phase II additive layer). Hardware-attested trusted execution environments (TEEs) sit above the threat model in the table by protecting data and code in use from the host — neither the cloud operator, the infrastructure team, nor a privileged admin can read what executes inside the boundary. Particularly valuable in three cases: regulated-profile / sovereign-cloud deployments where the host operator is outside the workload’s trust boundary; protecting proprietary or frontier model weights from infrastructure and host admins, so vendor-restricted models can run locally on residency- or sovereignty-constrained data; and as additional containment if a sandbox escape compromises neighboring sandboxes on the same host.

DPU / SmartNIC acceleration (optional, future). NVIDIA BlueField DPUs and ConnectX SmartNICs can offload several Phase II runtime-layer controls from the host CPU — network egress firewall (as a DOCA service), filesystem security (DOCA Vault), container security (DOCA Argus), and TLS / transport acceleration (BlueField). The hardware-accelerated path implements the same Phase II contracts — signed policy bundle, OCSF audit emission, deny-by-default egress, the control-surface decomposition in the table above — but executes on a separate compute domain, freeing host CPU and creating an additional trust-domain barrier between the agent workspace and the network-enforcement plane. Optional for any tier; particularly relevant on shared hosts where the host CPU is contended.

Operational responses for the in-VM-rooted case:

  • Per-workspace kill switch. Exposed via the workspace lifecycle API. Triggering stops the VM and invalidates the active broker session.

  • App session and token revocation. Revoke the per-engagement delegation record — halting new capability issuance at the next tool call — and rotate the per-service credentials the credential proxy holds in the secret store (Vault); where the provider supports it, revoke the user’s active application sessions/tokens at the provider. In the default profile the credential proxy is in-VM, so any tokens live during the compromise window are treated as exposed and rotated; the sovereign or residency-constrained profile hosts the proxy outside the VM, so in-VM root yields no usable tokens and only future calls need re-brokering.

  • Periodic VM image refresh. The baseline VM image is periodically refreshed, resetting any in-VM OS persistence.

  • Centralized SSO revocation. SSO entitlement for the affected user can be revoked at the identity broker layer.

  • Telemetry. Independent OCSF events from platform outside-VM and from sandbox runtime in-VM layers.