Open-source demo separates AI model proposals from sandboxed tool execution

A new open-source demonstration project shows the difference between an AI model proposing an action and software actually performing it under controlled conditions. The kinfey/aks_opensbx_ghc_demo, an unofficial McDonald's-themed technical exercise, runs a Copilot-based food-ordering assistant whose tool executions happen inside per-session sandboxes assembled from OpenSandbox and Kata Containers on Azure Kubernetes Service (AKS). The premise: an agent can only propose what its model can generate, but whether that proposal turns into an action depends on the execution platform — where the code runs, what permissions it holds, and how long the environment lives.

The project separates three problems that often get blurred. The Model Context Protocol standardizes how a model-facing application discovers and invokes tools, but routing a call through MCP does not automatically place it inside a security boundary. OpenSandbox supplies the working environment: lifecycle management, command execution, file operations, and network access. Kata Containers provides runtime isolation by running workloads in lightweight VMs with their own guest kernels rather than sharing the host kernel like conventional containers.

The architecture runs the web and API layer in regular Azure Container Apps, with the execution plane on AKS. The FastAPI backend requests a sandbox through the OpenSandbox SDK; a Kubernetes controller reconciles that request into a pod specified with runtimeClassName: kata-vm-isolation, scheduled onto a shared system/Kata pool of three Standard_D4s_v5 nodes. The model itself, gpt-6-astra accessed through GitHub Copilot APIs, is not hosted on those nodes. Each conversation session maps to one sandbox reused across related turns, with cleanup at session end. Files surviving between turns does not mean they survive sandbox deletion; anything durable requires an explicit, governed persistence path.

Credentials are handled in layers. A trusted backend supplies credentials and bindings to an egress sidecar; the workload process sees only placeholders, and the proxy injects authentication into matching outbound HTTPS requests. This reduces the workload's direct access to long-lived credentials but does not erase them from the system, and preventing the model from reading a token does not prevent abuse of the operations that token authorizes. Remote tools are restricted to read-only operations with exact hostname bindings.

The project documents operational findings. The initial pull of the roughly 2.8 GB sandbox image took almost six minutes — not model latency, and not attributable to feature approvals. Image warmup was moved out of the user request path, and the project warns against comparing warm-capacity allocation times against cold image pulls. Another debugging issue: Markdown tables vanished from replies not because of CSS, but because Copilot's terminal output had already converted them to character borders, and execd's line-oriented logging stripped the line terminators. The fix extracted original assistant content from CLI JSONL, re-encoded it in a single-line JSON envelope, decoded it in the backend, and sanitized it before rendering. A fixed-reply browser test proved insufficient; the project added a live-model test verifying raw Markdown, DOM tables, mobile layout, and confirmed sandbox deletion.

The demo makes no production claims: session mappings live in memory, at most one replica runs, and there is no user login or authenticated session ownership. A session ID routes and maps resources — it is not authorization, and an agent-generated confirmation boolean is not an auditable purchase approval.

The project frames platform choice as three questions rather than a self-hosted-versus-serverless debate: what needs to be controlled, what the team is willing to operate, and how execution completion will be proven with structured results and actual side effects rather than success-shaped sentences.