AI Work Hub
Enterprise supervisor-worker agent orchestration in isolated disposable VM sandboxes.
The Problem
Running untrusted AI-generated code and automated worker pipelines directly on enterprise host machines introduces severe risks of privilege escalation, lateral network movement, and accidental system destruction.
My Role
Engineered the supervisor-worker orchestration architecture, disposable Hyper-V VM isolation pipelines (Stage 1), secure loopback Model Context Protocol (MCP) tunnels, and fail-closed capability gates.
Highlights
- Two-tier Supervisor/Worker architecture separating strategic planning from untrusted task execution
- Stage 1 disposable Windows Hyper-V VM sandboxes with zero host network interfaces and detached virtual disks
- Strict ADR security model completely disabling dangerous capabilities during initial unverified execution stages
- Secure local MCP (Model Context Protocol) stdio and authenticated loopback transport bridges
- Immutable evidence-based acceptance verification enforcing cryptographic hash locks on execution bundles
Stack
Constraints
- Total host boundary defense: no untrusted code execution outside disposable VM sandboxes.
- Strict offline operation: worker sandboxes operate with zero virtual NICs to prevent exfiltration or external command injection.
- Cryptographic determinism: every provisioned execution harness must verify against candidate hash manifests.
System Architecture
Key Trade-offs
The decisions worth defending — what I chose, what I turned down, and why.
Execution sandbox technology
Chose
Disposable Hyper-V Generation-2 VMs with read-only mounted volume injection
Rejected
Windows containers or simple process tokens / AppContainers
Windows containers share the host kernel and have known breakout CVEs; generation-2 hypervisor virtualization provides true hardware-assisted isolation.
Capability rollout strategy
Chose
Strict fail-closed capability gating (ADR-0001: hub.ping only until Stage 1 proof)
Rejected
Gradual allowlist of file operations during development
Allowing partial mutations before complete sandbox boundary evidence is established violates security-first release gates.
Protocol integration layer
Chose
Standardized Model Context Protocol (MCP) over authenticated loopback
Rejected
Custom proprietary RPC protocol
MCP allows seamless interoperability with modern AI model tools and IDE extensions while keeping authentication strictly local.
What I'd Do Differently
An honest retrospective — the stuff I'd change with more time, more users, or a second pass.
- 1Automate memory reclamation and snapshot recycling to lower the 2GB host RAM startup reservation overhead.
- 2Build automated CI integration for Hyper-V nested virtualization testing on cloud runners.
- 3Expand runbook diagnostics to automatically detect host memory pressure before launching provisioners.
Hyper-V Disposable Sandbox Console
Interact with the quarantined isolation supervisor (sandbox boot, mcp bridge, quarantine status, eval "calc.exe").
Technical Deep-Dive
Architecture, specifications, and implementation details.
Stage 1 isolation prototype runbook
Current status: failed closed (stage1Passed:false). No identity-bound complete guest result has passed review.
#Candidate lock
Before execution verify:
- bundle ID
c448bada42de4fe8a324c7593e60f99f; - bundle SHA-256
2C4E662FD3947A7372FC648A2E7BB83A2ACD3D52A6FA2F69B8E2043B99010CC8; - harness source
FF97B8FE2181AE235CF6B294C0E20C3EB6F3B4ED045A74F4E85AC59E4D5F627E; - probe source
48AE5A5DD31E8B13F21360D4905EA4237D748F81683BBFC9609D7834107FC085; - every entry in this exact candidate's manifest: five entries, all five hashes must match. The 35/35 historical verification is only the aggregate across seven archived ZIPs.
Do not infer historical execution. Evidence must carry verifiable identity.
#Read-only preparation
- Confirm file mutation and terminal execution remain disabled.
- Require capability output with
systemChanges:0andnetworkActions:0. - Verify candidate and protected-input hashes.
- Inspect exact VM/evidence/memory/disk/network/process state without mutation.
- Record inaccessible locations as unverified, not absent.
#Current readiness assessment - 2026-09-15
Astra's 23:53:53.6335692+03:00 read-only check verified exact VM AIWH-Stage1-20260914-f15c2a90, ID 7750a32d-8f01-47a6-9d7c-1a44eacaad91, Off, generation 2, assigned memory 0, expected configuration descendant, exactly the two expected disks and zero NICs; both disks were unattached through Get-VHD and Get-DiskImage. Free RAM was 2,057,548 KiB (about 1.962 GiB), 39,604 KiB below the fixed 2 GiB startup allocation before headroom. Existing dynamic-memory settings already match helper values: startup 2 GiB, minimum 1 GiB, maximum 4 GiB, buffer 20. Root at 23:52:49.0078215+03:00 found evidence directory/result absent. At 23:55:31+03:00 the checked process was not Administrator despite sandbox escalation.
Candidate hashes above remain locked and fresh manifest validation was 5/5. Completion-helper SHA-256 is 0FF3EE880F66A4E51423854EFCE6744918C1FAA643F465094E3F956649D15C7A. Historical start_vm/vmCreated:true/vmStarted:false/0x800705AA is consistent with offline injection having been reached, but current guest contents/install/cleanup remain unverified. Assessment complete is distinct from execution-ready or Stage 1 accepted; reassessment documents accepted; Stage 1 remains NEEDS_REVISION.
User may close applications they choose, aiming for roughly 3 GiB free as an operational margin, not a proven Hyper-V minimum. A subsequent bounded Astra execution packet must immediately preflight exact VM ID/state/configuration descendant/two disk paths/zero NICs, RAM/headroom, Administrator token, locked candidate/manifest/helper identity and evidence absence. No process killing, reprovisioning or startup-memory reduction is in this document packet.
The fixed completion helper requires Administrator and the stopped generation-2 VM/configuration descendant/two disks/no NICs/absent evidence; it does not itself enforce immutable VM ID, candidate lock or RAM. It unconditionally reapplies the same current memory settings, starts the VM, waits up to 45 minutes, mounts its VHD read-only (possibly assigning a letter), copies three bounded files and dismounts. It uses no WinRM credentials; injected SetupComplete to run-once locates the unique AIWH-MOUNT volume. A later execution packet needs separate UAC elevation, bounded monitoring and progress communication. Timeout does not stop the VM; helper status:ok does not graduate Stage 1. Require identity-bound evidence, the full register below and independent review.
#Authorization boundaries
The user has authorized ongoing work, including relevant read-only checks; do not request the same user permission again. The current correction packet is document-only. Compilation, temporary profile/ACL mutation, synthetic execution and VM start/completion/recovery require a bounded execution packet within that authorization, verified preconditions and any required platform escalation. Real workspace inspection, external writes and GUI selection are not implied by this packet.
Before an authorized guest run, set AIWH_STAGE1_MOUNT_VOLUME_ROOT in the disposable VM's elevated parent PowerShell process to the verified root of its designated mount-fixture volume. The runner passes the parent environment to the native harness; it has no mount-volume parameter. Missing/empty/non-rooted values cause MOUNT_VOLUME_ROOT_UNAVAILABLE; the harness normalizes the value with a trailing backslash, calls GetVolumeNameForVolumeMountPoint, and uses SetVolumeMountPoint to create and verify the fixture. An arbitrary directory is not a substitute for a verified volume root. No volume is created or mounted by this document task.
The synthetic runner accepts only:
powershell.exe -NoLogo -NoProfile -ExecutionPolicy Bypass -File plugins/ai-work-hub/scripts/run-stage1-isolation-test.ps1 -ConfirmSyntheticIsolationTest
Never point it at a real workspace.
#Mandatory register
Retain OS-observed results for:
- traversal, rooted/absolute/UNC/device/GLOBALROOT/volume-GUID, ADS, DOS names, normalization, length and prefix-collision paths;
- symlinks, junction, real volume mount point, reparse points, hard links, replacement and synchronized per-type races with identity proof;
- parent, child, grandchild, detached, interpreter/script-host/shell and Job-breakaway behavior;
- AppContainer SID, zero capabilities, low integrity, deployment token and inherited-handle denial;
- secrets, profile data, registry, pipes, devices, clipboard and network;
- cancellation/supervisor crash and full process-tree termination;
- revocation, duplicate provisioning, stale revision, root replacement and interrupted recovery.
Static review, compilation, manifest validation, listener non-acceptance and timeout do not pass an OS gate. Network acceptance requires attributable access denial.
#Result and cleanup acceptance
Retain bounded JSON, diagnostics, OS build/source, binary identity, PIDs, token/Job facts, ACL before/after, profile/SID, root identity, attacks and cleanup checks.
Apply the explicit token/Job/handle and race criteria in STAGE1-DISPOSABLE-VM-RUNBOOK.md, recovered from the candidate's archived README and current native source. All four process roles must satisfy them. osVersionSource must be RtlGetVersion; retain kernel version/build and the verified ISO hash. The harness intentionally emits stage1Passed:false until independent security acceptance; a partial passing gate cannot graduate Stage 1.
cleanupComplete:true requires independently verified process absence, applicable ACL restoration, exact profile/SID-mapping absence, applicable registry/canary restoration and fixture absence. Any failed, missing, blocked, inconclusive or unverifiable result keeps Stage 1 failed closed.
Host process absence, VM Off, or an unattached/unmounted guest disk does not prove guest cleanup.
#Fallback
If the complete AppContainer/Job register cannot pass, request authorization for a Sandbox-only synthetic prototype. If unavailable, record blocked and keep capabilities disabled.