Ubuntu Workshop: The Right Sandbox for Running AI Agents

Canonical released Workshop in May 2026 — a tool for launching isolated development environments using LXD system containers with a single command. Its timing reflects a real problem: coding agents, local LLMs, and autonomous tools now routinely access files, run shell commands, and manage credentials on behalf of developers. Most existing sandboxes weren’t built with that threat model in mind. Workshop’s architecture was.

What Workshop Is — and What Makes It Different

Workshop is a Snap application distributed through the Snap Store, requiring LXD 6.8 or newer as a prerequisite. Environments are defined in YAML configuration files: a single file describes which SDKs to load, which host resources are accessible, and what the environment contains. From that file, Workshop can create, upgrade, or tear down the environment with one command. The YAML can be version-controlled, reviewed, and shared across a team — the environment becomes reproducible across machines rather than something that “works on my laptop.”

Workshop isn’t a package manager or a virtual environment wrapper. It’s a workload isolation layer built on top of a mature container runtime. The comparison point isn’t venv or conda — it’s closer to a lightweight VM with a developer-friendly interface.

System Containers vs. Docker: The Kernel Is the Difference

Docker application containers share the host kernel. Isolation relies on Linux namespaces and cgroups, which is effective for most workloads but leaves a shared kernel attack surface. If a workload inside a Docker container finds a kernel vulnerability, that vulnerability is present in the host kernel too.

Workshop uses LXD system containers: each environment runs its own kernel instance, not the host’s. This is structurally closer to a virtual machine than to a Docker container, though without the full overhead of hardware virtualization. The kernel boundary is real, not just a namespace boundary.

Additionally, Workshop containers are unprivileged by default. A root process inside a Workshop environment maps to an unprivileged user ID on the host — the same technique Docker supports via user namespace remapping, but which is rarely enabled by default in practice. In Workshop, this is the baseline, not an opt-in configuration.

Why AI Agents Change the Sandbox Requirements

A coding agent like Claude Code operates with the permissions of the local user: it reads the filesystem, edits files, runs shell commands, and can reach SSH keys, cloud credentials, and API tokens stored in the user’s home directory. Under human supervision, this is manageable. In automated or semi-autonomous workflows, the same capabilities become a significant exposure — especially when the agent is running an experimental model, a third-party tool, or a local LLM whose behavior under edge cases isn’t fully characterized.

The problem isn’t that agents are malicious — it’s that they’re capable. An agent that misunderstands a task or follows an ambiguous instruction can do real damage with developer-level permissions. The reasonable response is containment: run the agent inside a boundary that limits what it can reach, not just what it intends to reach.

Workshop frames this directly: “you control what AI agents have access to.” That control is structural, not dependent on the agent behaving correctly.

The Interface System: No Implicit Access to Host Resources

Workshop’s interface system, modeled after the snapd interface architecture, manages how a container accesses host resources. GPU, SSH agent, network interfaces — none of these are available to a Workshop environment by default. They must be explicitly declared in the YAML configuration and granted through the interface system.

This design has a useful property: the set of host resources an agent can reach is visible in the configuration file, not buried in runtime flags or implicit from how the container was started. If a coding agent running inside Workshop needs to push code via SSH, the SSH agent interface must be enabled — and that decision appears in the YAML, reviewable alongside everything else the environment declares.

For teams running local LLMs via Ollama, the GPU interface gets granted to exactly that workload. Other environments on the same machine don’t inherit GPU access just by existing. The capability grant is scoped, not ambient.

YAML Configuration as a Permission Manifest

The YAML file that defines a Workshop environment functions as a permission manifest for the workload running inside it. It captures what SDKs are loaded, which host interfaces are connected, and what the environment is expected to do — before the workload runs, not discovered afterward when something goes wrong.

This matters architecturally because it separates two questions that are often conflated: what can this agent do, and what does this agent do. The YAML answers the first question explicitly. The agent’s runtime behavior operates within that boundary. When the boundary needs to change — the agent requires a new capability — that change goes through the same review process as any other configuration change.

For teams with multiple agents at different trust levels (an experimental model vs. a production coding assistant), different YAML configurations can encode different capability sets for the same host machine.

SDK Store: Prebuilt Environments for AI Workloads

Workshop ships with an SDK store that currently includes Ollama, OpenCode, NVIDIA CUDA, AMD ROCm, Intel OpenVINO, and ROS 2, among others. SDKs can be pulled from stable or edge channels, and custom SDKs can be created and published for internal distribution.

For AI development specifically, this means the runtime infrastructure for a workload is part of the environment definition, not a separate installation step on the host. An environment running a local LLM via Ollama with NVIDIA CUDA acceleration can be fully specified in YAML and reproduced from scratch on another machine — or rolled back to a previous configuration — without manually reinstalling GPU drivers or model runners on the host.

The ROS 2 SDK entry signals that Workshop’s intended scope extends to robotics and embedded development, where agentic control systems have physical-world consequences — arguably the highest-stakes case for meaningful sandbox boundaries.

What Workshop Doesn’t Cover Yet

Workshop is new — released in May 2026 — and the SDK ecosystem is still early. The current documentation doesn’t describe granular network isolation within a Workshop environment: restricting an agent to specific API endpoints while blocking outbound calls to others, for example. For teams concerned about an agent exfiltrating data or making unexpected external requests, network-level controls would need to be layered separately.

Workshop also requires the Ubuntu and Snap ecosystem. Development teams on macOS, Windows, or non-Ubuntu Linux distributions would need a VM layer to run Workshop, which reduces its practical appeal for cross-platform setups. The tool is clearly positioned as an Ubuntu-first product for now.

The Discipline Workshop Enforces

Workshop’s contribution isn’t that it makes AI agents safe — no sandbox can guarantee that. Its contribution is that it makes the safety perimeter explicit and auditable. The YAML file, the interface system, the unprivileged-by-default container — each of these is a mechanism that forces the question “what does this workload actually need?” to be answered before the workload runs.

For teams experimenting with coding agents and local LLMs, the discipline Workshop enforces — define the environment, declare the access, run in isolation — is a reasonable baseline for working with systems that act autonomously on a developer’s behalf. The alternative is hoping that the agent doesn’t reach something it wasn’t supposed to touch. Workshop makes that hope unnecessary.