Most organizations are already using AI agents in their development workflows. The question is whether those agents are governed or fall under the category of “shadow AI”. Docker’s recent AI-focused releases can be composed into a single architecture that reduces developer friction while giving platform and security teams isolation, visibility, and policy enforcement at each layer.
Here’s the full stack in seven layers.
Note: For a deep dive into these concepts, see From Shadow AI to Enterprise Asset: A Seven-Layer Reference Architecture for Docker’s AI Stack – The Deep Dive.
The Seven Layers
| Layer | Docker Tool(s) | What It Does |
|---|---|---|
| Foundation | Docker Hardened Images + Registry Access Management + Image Access Management | Hardened/minimal base images; registry allowlisting (RAM) and Docker Hub image-type controls (IAM) to reduce exposure to unapproved sources |
| Definition | cagent | Declarative YAML agent configs with root/sub-agent orchestration |
| Inference | Docker Model Runner + Remocal/MVM | Local-first model execution using Minimum Viable Models (MVMs) via a local model runtime (Model Runner); optional remote workload execution with Docker Offload when you need to scale beyond local resources |
| Execution | Docker Sandboxes | MicroVM isolation: each sandbox gets its own VM with a private Docker daemon; the agent can build/run/test without access to the host Docker environment |
| External Access | MCP Gateway + MCP Catalog/Toolkit | Gateway-managed MCP tool servers run in isolated containers with restricted privileges/network/resources, plus built-in logging and call tracing for governance; the Catalog provides curated MCP servers packaged as Docker images |
| Observability | Docker Scout + MCP Gateway logging | Continuous Software Bill of Materials (SBOM) and Common Vulnerabilities and Exposures (CVE) visibility across images (Docker Scout) + tool-call logs and traces from MCP Gateway for visibility and governance |
| Identity | SSO + SCIM | Authentication and user provisioning to support identity-based access control at scale |
Two additional Docker Business capabilities complement these layers:
| Capability | Docker Tool(s) | What It Does |
|---|---|---|
| Build Acceleration | Docker Build Cloud | Offloads image builds to cloud infrastructure to reduce build times and improve CI/CD feedback loops |
| Standard Container Isolation | Enhanced Container Isolation (ECI) | Strengthens isolation for standard containers using Linux user namespaces (limiting impact of malicious containers by reducing effective privileges) |
Executive Snapshot: What each layer buys you (ROI + controls)
| Outcome | Docker Tool(s) | Why It Matters |
|---|---|---|
| Lower AI spend + faster iteration | Docker Model Runner + Remocal/MVM | Run more of the dev loop locally to reduce paid API calls and latency during iteration. |
| Safe autonomy for agents | Docker Sandboxes | MicroVM isolation + fast reset reduces host risk and cleanup time when agents misbehave. |
| Governed tool access | Docker’s MCP Catalog + Toolkit (including MCP Gateway) | Centralize tool servers, apply restrictions, and capture logs/traces for visibility. |
| Stronger supply-chain posture | Docker Hardened Images + Registry Access Management + Image Access Management | Standardize hardened bases and prevent pulling from unapproved sources. |
| Fewer vuln/audit fire drills | Docker Scout + MCP Gateway logging | Continuous SBOM and CVE visibility across images + tool-call logs/traces improves triage and audit readiness. |
| Faster CI + hardened non-agent containers | Docker Build Cloud + Enhanced Container Isolation (ECI) | Reduce build bottlenecks and strengthen isolation for everyday (non-agent) containers. |
Layer by Layer
1. Foundation — DHI + RAM + Image Access Management
Docker Hardened Images provide distroless, minimal base images with every image including an SBOM, SLSA Build Level 3 provenance, and transparent CVE data. Now free and open source under Apache 2.0, with a catalog of over 1,000 images and Helm charts on Alpine and Debian. This foundation applies broadly across the architecture. DHI base images underpin the application containers developers build and the MCP server containers that agents call through the Gateway. Registry Access Management (RAM) adds DNS-level registry allowlisting, and Image Access Management controls which types of Docker Hub images are permitted. Together they enforce the foundation at the organizational level. (DHI Docs; RAM Docs)
2. Definition — cagent
Agents defined as declarative YAML, not ad-hoc scripts. Root agent delegates to sub-agents, each with its own model, tools, and instructions. Bundled in Docker Desktop 4.49+, packaged as OCI artifacts, shareable via Docker Hub. Swap models by changing one line instead of rewriting the workflow. (Docs)
3. Inference — Docker Model Runner + Remocal
Reduces cost and iteration time during development. Docker Model Runner uses local-first model execution via OpenAI-compatible and Ollama-compatible APIs. Three inference engines: llama.cpp (all platforms), vLLM (NVIDIA GPUs), and Diffusers (image generation). Docker’s “Remocal” philosophy: use the smallest effective model locally during development, scale to cloud only when needed. Docker Offload provides GPU cloud compute (L4 in beta, broader GPU in 2026) as a drop-in replacement. (Docs)
4. Execution — Docker Sandboxes
When agents need autonomy for tasks such as editing files or installing packages, Docker Sandboxes provide microVM isolation with a private Docker daemon. Hypervisor-level boundary: separate kernel, workspace-only mount, no host Docker access. This layer wraps agent definition and inference together in an isolated environment. Currently supports Claude Code, Codex, Copilot, Gemini, cagent, Kiro, OpenCode, and custom shell. For standard (non-agent) containers, Enhanced Container Isolation (ECI) provides complementary protection via Linux user namespaces. (Docs)
5. External Access — MCP Gateway + MCP Catalog
Governs all agent interactions with external systems (such as GitHub, Jira, databases) throughout the workflow. The open-source MCP Gateway runs MCP servers in isolated containers with restricted privileges, credential injection, and built-in logging/call tracing. The MCP Catalog provides 300+ verified, curated servers as Docker images. Organizations can create custom catalogs to scope approved tools. (Docs)
6. Observability — Docker Scout + Gateway logging
Docker Scout provides continuous SBOM and vulnerability analysis across container images in the architecture: DHI base images, application images, and MCP server images. MCP Gateway logging and call tracing captures tool invocations with support for signature verification and secret blocking interceptors. Together they answer: “what’s running, is it safe, and what did the agent do.” (Scout Docs; Gateway GitHub)
7. Identity — SSO + SCIM
The layer that binds everything together. SSO authenticates developers via the organization’s identity provider; SCIM automates user provisioning and deprovisioning. RAM policies only take effect when users sign in, Image Access Management controls are scoped to authenticated users, and audit trails only have meaning when tied to verified identities. Without this layer, the other six can’t enforce governance. (Docs)
Conclusion
Composed together, these seven layers form a governed architecture for AI agent workflows:
- Foundation standardizes trusted images and limits unapproved sources (Docker Hardened Images + RAM/IAM)
- Definition makes agent behavior reproducible (cagent)
- Inference enables local-first model execution economics (Docker Model Runner + Remocal/MVM)
- Execution isolates autonomous work in microVM sandboxes
- External Access centralizes and governs tool use through MCP Gateway (with curated servers via the Catalog)
- Observability combines supply-chain visibility (Docker Scout) with tool-call logs/traces (MCP Gateway)
- Identity (SSO/SCIM) supports consistent access and lifecycle control at scale.
Two additional Docker Business capabilities complement these layers:
- Build Acceleration improves developer and CI throughput by offloading image builds to cloud infrastructure (Docker Build Cloud).
- Standard Container Isolation strengthens isolation for everyday (non-agent) containers using Linux user namespaces, reducing effective privileges and limiting blast radius (Enhanced Container Isolation / ECI).
The net effect is a path from unmanaged “shadow AI” to a governed architecture that reduces developer friction, provides isolation and visibility at each layer, and gives platform teams the controls to enforce policy without slowing delivery.
How I Wrote This Article
This post was produced through a multi-stage process combining human research and writing with AI tools. I spent a week studying Docker’s AI-focused releases, built the architectural framework, then used AI tools (Gemini, ChatGPT, and Claude) iteratively for drafting, fact-checking, and structural review. For the full methodology, see the deep dive’s “How I Wrote This” section.