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.
ADR-0002: Prepare stdio for Secure MCP Tunnel
- Status: Accepted for local readiness; remote transport unverified
- Date: 2026-09-13
#Decision
Use the fixed Windows launcher plugins/ai-work-hub/scripts/start-mcp.ps1 as the only local process entry for a future OpenAI Secure MCP Tunnel pilot. The launcher resolves the MCP adapter relative to itself and invokes Node with a fixed entry point. It accepts no arguments and exposes only hub.ping.
Stage 0 readiness does not install, configure, start, or validate a tunnel. Tunnel executable paths, profile names, endpoints, tenant values, and credentials remain operator-supplied placeholders until copied from current official documentation and approved for the pilot environment.
As verified against the official documentation on 2026-09-13, the intended path is: ChatGPT web → OpenAI-hosted tunnel endpoint → foreground tunnel-client → fixed start-mcp.ps1 → stdio MCP child. The tunnel requires a tunnel_id, a runtime API key, and a locally reachable stdio or HTTP MCP target. Default egress is outbound HTTPS to api.openai.com:443; when control-plane mTLS is configured it is mtls.api.openai.com:443. OpenAI Secure MCP Tunnel
Platform tunnel permission and ChatGPT Developer Mode permission are separate. Read + Manage creates or edits tunnels; Read + Use runs the client or selects a tunnel while creating an app. Tunnel associations must include the intended Platform organization and ChatGPT workspace. Developer Mode is enabled separately, then a private app is created from ChatGPT Plugins using Tunnel as the connection. OpenAI Secure MCP Tunnel, ChatGPT Developer mode
#Trust boundaries
- The stdio adapter trusts only framed local JSON-RPC input within its 65,536-byte ceiling. It does not authenticate a remote caller.
- The future tunnel is responsible for remote transport and its supported authentication. This design does not assert that a remote end-user identity is propagated to the local MCP process.
- The local launcher is a process boundary, not OS isolation. It grants no file, shell, terminal, package-install, or process tool.
hub.pingproduces a unique correlation ID and one bounded audit record. Correlation is operational evidence, not proof of user identity or tamper-resistant audit.
#Consequences
A foreground, single-owner pilot may proceed only after the operator verifies the current official tunnel syntax, local account capability, executable integrity, profile scope, credential storage, and revocation procedure. Remote web-to-PC acceptance remains open until an authorized end-to-end invocation succeeds and evidence is reviewed.
This decision covers private testing only. Secure MCP Tunnel is not a public plugin distribution path. Responses API or model calls are excluded from the pilot and would require separate API/billing authorization even though the tunnel documentation lists them as a supported caller.