Microsoft Azure Reference Implementation#

The cloud reference implementation uses Microsoft Azure as the managed workspace substrate for Secure Agent Workspace. Each user receives a single-user Azure Linux VM, provisioned on demand in a dedicated untrusted virtual network and accessed through enterprise SSO and a trusted access broker. The local endpoint remains a presentation surface; agent execution and enterprise-tool access occur inside the VM boundary, which is ephemeral — one user per VM, demolished after use.

This implementation is intended for enterprises that need a cloud-native deployment of agent workspaces on Microsoft Azure that keeps a simple containment posture — the VM is the sandbox — realized with Azure-native primitives (Azure Virtual Network, Azure Firewall Premium, NAT Gateway V2, Workload Identity Federation, Microsoft Entra ID, Azure Key Vault, Azure Compute Gallery).

The Phase I and Phase II subsections below project the same maturity progression onto Microsoft Azure. The baseline control surface is taken as given; each subsection names only the Azure-specific primitives — Azure resource types, identity flows, network controls — that realize each control on this substrate. Phase II (in-VM runtime-enforced agent policy) adds in-runtime enforcement at the tool-call boundary on the same Azure-native footprint; v1 ships Phase I — the VM boundary plus an egress allow-list carry the load — and Phase II follows.

_images/secure-agent-workspace-azure-reference-implementation.png

Figure 11 Secure Agent Workspace — Microsoft Azure Reference Implementation (v1). The VM is the sandbox: ephemeral single-user VM + egress allow-list. Phase II adds in-runtime enforcement on the same footprint.#

The Azure v1 topology. An ephemeral single-user Azure Linux VM in a dedicated untrust VNet reaches only an Azure Firewall Premium egress allow-list (fail-closed, via NAT Gateway V2) and Azure services over Private Endpoints; the user attaches over a trusted-access-broker SSH reverse tunnel with no inbound path; the control plane provisions secretlessly via Workload Identity Federation with trust-on-boot ARM tags; and there is no route to corp (BGP propagation disabled). The VM is the sandbox in v1 — Phase II adds in-VM runtime enforcement (runtime sandbox, credential proxy, routed inference, signed policy) on the same Azure-native footprint.

Reference Shape#

The baseline v1 deployment consists of:

  • Azure Virtual Machines running Azure Linux, one per user, ephemeral and disposable. Each VM is a single-user workspace, thrown away after use — “the VM is the sandbox.” The agent runs root-capable inside its own VM (sudo + docker, no in-box confinement); the VM boundary plus the egress allow-list are the load-bearing controls.

  • Cloud-neutral control plane with an Azure compute adapter behind a cloud-neutral interface, added without disturbing existing cloud paths (strangler refactor). ARM VM lifecycle is restart-safe — long-running-operation polling resumes after a worker restart, so no duplicate or orphaned VMs.

  • Dedicated untrust VNet (separate subscription preferred), region West US 2 for v1, holding a /19 sandbox subnet (~8,187 usable addresses) and a /26 AzureFirewallSubnet, wrapped in a /16 reservation as growth runway. Hub/spoke is permitted only against an untrust hub, never the trusted corporate hub.

  • Trusted access broker providing the inbound SSH path into the workspace and the outbound reverse tunnel for app-level corp access — the broker agent dials out (reverse tunnel), so there is no inbound door; the same tunnel is how the agent reaches the internal source-control service. No public IP, no inbound path, no Azure Bastion, no graphical desktop (headless / SSH-only).

  • Network boundary controls using Azure-native primitives: a route table (UDR) directing 0.0.0.0/0 through the firewall’s private IP with gateway/BGP route propagation disabled (the single highest-impact control — corp prefixes learned over ExpressRoute would otherwise win on longest-prefix-match and bypass the firewall); NSG deny on corp CIDRs, east-west and direct :53, no public/corp inbound, as defense-in-depth; Azure Firewall Premium (L7 FQDN/app rules with SNI, L3/4 network rules, DNS proxy, IDPS in alert/detect mode, with TLS inspection as a Phase II toggle); and NAT Gateway V2 (StandardV2), zone-redundant on the firewall subnet, for SNAT capacity at fleet scale.

  • Agent runtime inside the VM, running root-capable on Azure Linux. No in-box agent confinement in v1; Phase II adds a kernel-level in-box runtime sandbox (OpenShell), on the same footprint.

  • Image catalog built with Packer (azure-arm) + Cinc from shared configuration-management cookbooks, published to Azure Compute Gallery, headless, with OS disks encrypted under a customer-managed encryption key and the golden image rebuilt on a schedule and for critical CVEs.

  • Logging of Azure Firewall allow/deny events plus NSG / VNet flow logs (the latter keeping Private-Endpoint and east-west traffic observable even where it bypasses the firewall logs by design), emitted to Azure Monitor / Log Analytics, Microsoft Sentinel, or the enterprise SIEM.

Identity and Provisioning Model#

Azure identity has two distinct trust planes — control-plane→Azure for provisioning, and VM→Azure at runtime:

  • Control-plane→Azure: Workload Identity Federation (secretless). The control plane proves its identity to Azure ARM via a federated token exchange — no stored credential ever sits on a control-plane host.

  • VM→Azure: two shared, fixed-scope managed identities with a broad→narrow swap. Each VM gets a broad bootstrap identity used only during setup, swapped to a narrow runtime identity before any agent code runs (an instance-profile-style broad→narrow swap). Two shared identities per role, not per-VM — a per-VM identity would exhaust Azure’s ~4,000 role-assignments-per-subscription cap well before the fleet reaches target scale.

  • Trust-on-boot via ARM tags. The control plane never calls into the private VM; readiness and identity signals return as ARM tags on the VM resource. Inbound access into the VM is broker-mediated SSH only.

  • Login via Microsoft Entra ID — cloud-native, with no corporate-AD dependency. Corporate AD / SSSD is the regular-desktop path, not the sandbox’s.

  • GA fleet planning — multi-subscription sharding. Fixed per-subscription Azure caps (~980 resource groups, 4,000 role-assignments, ~2,500–5,000 VMs per subscription per region) mean the full fleet spans multiple subscriptions, each with its own untrust VNet under one non-overlapping /16 IPAM reservation, each egressing through the firewall. The reservation and peering model are designed for sharding from day one.

Phase I: Deployable Managed VM Controls#

Phase I is the v1 Azure deployment — deployable today with standard Azure primitives and standard enterprise operations practices.

Controls include:

  • One ephemeral Azure VM per user (auto-terminate at 8 hours idle for interactive, 7-day cap for auto-runs, with a 30/90-day inactivity backstop).

  • Approved golden images only — built with Packer + Cinc, published to Azure Compute Gallery, OS disk encrypted with a customer-managed encryption key.

  • Workspace lifecycle through the cloud-neutral control plane (Azure compute adapter), trust-on-boot via ARM tags.

  • Microsoft Entra ID login with broker-mediated SSH; no public IP, no inbound path, no Azure Bastion.

  • Default-deny network egress through Azure Firewall Premium against the egress allow-list (owned day-to-day by the platform team), fail-closed (if the firewall is down the sandbox cannot reach the model — safer than failing open).

  • Dedicated untrust VNet with gateway/BGP route propagation disabled and NSG corp-CIDR / east-west deny, so there is no route to the corporate network.

  • NAT Gateway V2 (StandardV2) for SNAT at fleet scale; Azure Key Vault and Blob Storage reached over Private Endpoints locked to the sandbox.

  • Azure Firewall allow/deny logs and NSG / VNet flow logs to Azure Monitor / Log Analytics, Microsoft Sentinel, or the enterprise SIEM.

In this phase, containment lives in the two walls the design names: the VM (one user, one task, then destroyed) and the door (a single fail-closed firewall with a short, reviewed allow-list, no inbound path, and no route to corp). The Azure egress allow-list is a reachability control, not data-loss prevention — data could still leave through an already-allowed service such as a code-hosting or package-registry service.

Phase II: Runtime-Enforced Agent Policy on Azure#

Phase II adds an in-VM runtime enforcement layer beneath the VM boundary, so containment no longer rests on the VM wall and the egress allow-list alone. v1 establishes Phase I — the VM is the sandbox: the agent runs root-capable inside the VM (sudo + docker), with the VM boundary plus the egress allow-list as the containment. Phase II then adds, on the same Azure-native footprint, an in-runtime policy layer (NVIDIA OpenShell or equivalent) that enforces a signed policy bundle at the tool-call boundary:

  • In-box agent confinement / runtime sandbox. A kernel-level sandbox inside the VM confines all agent operations — shell, hooks, MCP servers, skills — with filesystem and process scope restricted to the workspace, so the agent no longer runs unconfined as root-in-VM.

  • Credential / egress proxy. A layer separate from the agent injects per-service authorization at egress and keeps raw secrets out of the agent process — the agent holds only short-lived, scoped capabilities. Deny-by-default egress is enforced in-runtime, not only at the network boundary. In v1 the user’s own model access lives on the short-lived VM; Phase II moves it behind the proxy.

  • Routed inference. Model calls are brokered to approved endpoints under the same capability rule, so credentials never reach the agent.

  • TLS inspection of model traffic. An optional toggle on Azure Firewall Premium that brings deep packet inspection inline.

  • Signed policy and controlled release. Policy is authored centrally, signed, distributed to the workspace, verified on load, and enforced per tool call; the agent cannot widen its own scope or policy.

Phase II is additive — it does not replace Phase I. It brings the agent’s runtime behavior under enforcement at the actual tool-call boundary, below the prompt layer, rather than relying on the VM wall and egress allow-list alone.

Storage and Key Management Notes#

Azure storage and secret handling for the sandbox follow a few load-bearing rules:

  • Bootstrap secrets in Azure Key Vault, build artifacts in Azure Blob Storage, both reached over Private Endpoints + Private DNS so traffic stays on Azure’s private backbone.

  • Lock every Private-Endpoint resource to the sandbox (resource-level firewall allowing only the Private Endpoint) so the private path cannot be repurposed for exfiltration.

  • A Private Endpoint injects a /32 route more specific than the 0.0.0.0/0 → firewall UDR, so its traffic bypasses (and is not logged by) the firewall by design — account for it with resource-level locks, correct Private DNS zones, and NSG / VNet flow logs so the traffic stays observable.

  • Customer-managed encryption keys for OS disks.

  • DNS through the firewall DNS proxy; all :53 forced through the proxy (NSG-deny direct outbound 53). Corp names clean-fail rather than silently hang; no blanket corporate DNS forwarder in v1.

  • Allow the Azure platform IP 168.63.129.16 for platform health / DNS / IMDS, but verify at go-live that it does not become a direct :53 bypass.

Operating Invariants#

The Azure implementation should preserve these invariants:

  • The endpoint attaches over broker-mediated SSH; it does not execute autonomous work.

  • The Azure VM is the user’s single-user, ephemeral workspace and the primary isolation boundary — one VM per user, deleted when the task is done.

  • The control plane never calls into the private VM; readiness and identity signals return as ARM tags (trust-on-boot). The agent cannot grant itself broader Azure permissions because the runtime managed identity carries deliberately minimal, fixed scope, locked down before any agent code runs.

  • Bootstrap secrets live in Azure Key Vault, reached over a Private Endpoint. In v1 the user’s own model login does sit on the VM (bounded to that one user’s own model access on a short-lived VM); a Phase II credential / egress proxy would remove it from the box.

  • Workspace state is disposable; the agent’s app-level corp access is over the broker’s reverse tunnel — there is no corp-routable network from the VM.

  • The egress firewall is fail-closed: if it is down, sandboxes cannot reach the model — a deliberate availability choice in favor of containment.

  • Containment resets by disposal: each VM is one user, one task, then destroyed (auto-terminate at 8h idle / 7-day cap), so a compromise dies with the VM, usually within hours.

Why This Matters#

Microsoft Azure gives enterprises a cloud-native path to host single-user agent workspaces on infrastructure they already operate, with a simple containment posture — the VM is the sandbox, egress is allow-listed, the control plane is secretless, and there is no inbound path or route to corp. The v1 deployment realizes that posture with Azure-native primitives; Phase II then adds in-runtime enforcement at the tool-call boundary (in-box containment / OpenShell, a credential / egress proxy, routed inference, signed policy, TLS inspection), on the same Azure-native footprint.

The result is a practical Azure-native Secure Agent Workspace pattern: ephemeral single-user VMs for isolation, Azure Firewall Premium and NAT Gateway V2 for egress, Workload Identity Federation for secretless provisioning, Microsoft Entra ID and a trusted access broker for access, and Azure Compute Gallery for image governance — with Phase II adding in-runtime enforcement at the tool-call boundary (in-box containment, a credential / egress proxy, routed inference, signed policy, TLS inspection) on the same footprint.