Forem: Alden Weaver

Six Enterprise AI Adoption Challenges and How Docker's Latest Tools Address Them

Alden Weaver — Thu, 26 Feb 2026 10:02:58 +0000

AI isn't coming to your software teams. It's already there. Developers are running local models, pulling AI-optimized images, connecting autonomous agents to codebases and cloud APIs, and integrating AI tools into every stage of the development lifecycle. The question for security, platform, and executive leadership isn't whether to allow it. It's whether you govern it or pretend it isn't happening.

The risks are well-documented: unpredictable inference costs, unvetted images and tools entering the supply chain, autonomous agents with write access to production systems, and no audit trail across any of it. Without a deliberate architecture, this becomes Shadow AI.

Docker's recent AI-focused releases address these challenges directly. Here's how they map to the concerns platform and security teams are navigating right now.

The Challenges (and What Addresses Them)

1. "AI inference costs are unpredictable and growing fast."

Docker Model Runner + Remocal/MVM + Docker Offload

Docker's "Remocal" approach pairs local-first development with Minimum Viable Models (MVMs), the smallest models that get the job done. (Docker, "Remocal + Minimum Viable Models") Docker Model Runner executes these locally through standard APIs (OpenAI-compatible and Ollama-compatible) with three inference engines. (Docker Docs, "Model Runner") Developers iterate locally at zero marginal token cost and only hit cloud APIs when they need to.

When local hardware isn't enough, Docker Offload extends the same workflow to cloud infrastructure (L4 GPU currently in beta) without changing a single command. (Docker, "Docker Offload") The cost lever is clear: local by default, cloud when justified.

2. "Autonomous agents with write access terrify our security team."

Docker Sandboxes

This is the answer to the "but what if the agent goes rogue" conversation. Each sandbox runs in a dedicated microVM with its own kernel, filesystem, and private Docker daemon. The agent can build, install, test, and run containers, all without any access to the host environment. Only the project workspace is mounted. When you tear down the sandbox, everything inside it is deleted. (Docker Docs, "Sandboxes Architecture")

This is hypervisor-level isolation, not container-level. Sandboxes already support Claude Code, Codex, Copilot, Gemini, cagent, Kiro, OpenCode, and custom shell. (Docker Docs, "Sandbox Agents") For standard (non-agent) containers, Enhanced Container Isolation (ECI) provides complementary protection using Linux user namespaces. (Docker Docs, "Enhanced Container Isolation")

3. "Developers are connecting agents to GitHub, Jira, and databases with no oversight."

MCP Gateway + MCP Catalog

The open-source MCP Gateway runs every tool server in an isolated container with restricted privileges, network controls, and resource limits. It manages credential injection (so API keys don't live in developer configs), and it includes built-in logging and call tracing. Every tool invocation is recorded. (Docker Docs, "MCP Gateway"; Docker, "MCP Gateway: Secure Infrastructure for Agentic AI")

The MCP Catalog provides 300+ curated, verified tool servers packaged as Docker images. Organizations can create custom catalogs scoped to their approved servers, turning "find a random MCP server on the internet" into "pick from the approved list." Docker is also applying automated trust measures including structured review of incoming changes. (Docker Docs, "MCP Catalog")

4. "We can't control what our developers are pulling and running."

Docker Hardened Images + Registry Access Management + Image Access Management

Docker Hardened Images (DHI) are distroless, minimal base images stripped of shells, package managers, and unnecessary components. Every image ships with an SBOM, SLSA Build Level 3 provenance, and transparent CVE data. (Docker, "Introducing Docker Hardened Images") DHI is now free and open source (Apache 2.0) with over 1,000 images available, which removes the "it's too expensive to do the right thing" objection. (Docker Press Release, December 17, 2025)

Registry Access Management (RAM) provides DNS-level filtering to control which registries developers can access through Docker Desktop. (Docker Docs, "Registry Access Management") Image Access Management adds controls over which types of Docker Hub images are permitted. (Docker Docs, "Image Access Management") Together, they let your platform team enforce approved sources without slowing anyone down.

This isn't just for application images. Docker is actively extending hardening to MCP server images, the tools AI agents use to interact with external systems. (Docker, "Hardened Images for Everyone")

5. "We need an audit trail and we need it yesterday."

Docker Scout + MCP Gateway logging

Docker Scout provides continuous SBOM and vulnerability analysis across container images in the stack: DHI base images, application images, and MCP server images. (Docker Docs, "Docker Scout") MCP Gateway logging captures tool-call details with support for signature verification (checking image provenance before use) and secret blocking (scanning payloads for exposed credentials). (Docker, "MCP Gateway: Secure Infrastructure for Agentic AI"; GitHub, docker/mcp-gateway)

Together, these answer the three questions auditors will ask: What's running? Is it safe? What did the agent do?

6. "We can't enforce any of this without knowing who's who."

SSO + SCIM

Identity is the layer that makes all the others enforceable. RAM policies only activate when developers sign in with organization credentials. Image Access Management is scoped to authenticated users. Audit trails are meaningless without verified identities attached.

SSO authenticates via your existing identity provider. SCIM automates provisioning and deprovisioning. When someone joins or leaves, their Docker access updates automatically. (Docker Docs, "Single Sign-On")

What This Looks Like Composed

Outcome	Docker Tool(s)	Why It Matters
Lower AI spend + faster iteration	Docker Model Runner + Remocal/MVM + Docker Offload	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 + RAM + 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 + tool-call logs improves triage and audit readiness.
Identity-based policy enforcement	SSO + SCIM	Tie governance controls and audit trails to verified, managed identities across every layer.
Faster CI + hardened non-agent containers	Docker Build Cloud + Enhanced Container Isolation (ECI)	Reduce build bottlenecks and strengthen isolation for everyday containers.

The Seven-Layer Architecture

For teams ready to go deeper, here is a reference architecture that weaves these capabilities into seven concurrent layers to solve the problems mentioned above.

Layer	Docker Tool(s)	What It Does
Foundation	Docker Hardened Images + RAM + Image Access Management	Hardened/minimal base images; registry allowlisting and image-type controls
Definition	cagent	Declarative YAML agent configs with root/sub-agent orchestration
Inference	Docker Model Runner + Remocal/MVM	Local-first model execution with Minimum Viable Models; Docker Offload for cloud burst
Execution	Docker Sandboxes	MicroVM isolation with a private Docker daemon per agent
External Access	MCP Gateway + MCP Catalog	Governed, containerized tool servers with credential injection and call tracing
Observability	Docker Scout + MCP Gateway logging	Continuous SBOM/CVE analysis; tool-call audit trails
Identity	SSO + SCIM	Authentication, user provisioning, and identity-based policy enforcement

For the full architecture walkthrough, including how each layer connects, read the companion overview: From Shadow AI to Enterprise Asset: A Seven-Layer Reference Architecture for Docker's AI Stack.

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 "How I Wrote This" section of my deep dive into these concepts: From Shadow AI to Enterprise Asset: A Seven-Layer Reference Architecture for Docker's AI Stack - The Deep Dive.

From Shadow AI to Enterprise Asset: A Seven-Layer Reference Architecture for Docker's AI Stack

Alden Weaver — Thu, 26 Feb 2026 09:00:53 +0000

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

From Shadow AI to Enterprise Asset: A Seven-Layer Reference Architecture for Docker's AI Stack - The Deep Dive

Alden Weaver — Thu, 26 Feb 2026 08:58:46 +0000

Introduction

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'. Without a strategic architecture, teams end up with unmanaged tool sprawl, inconsistent configurations, unclear security boundaries, and unpredictable cloud-inference bills. Docker's newer AI-focused building blocks can be composed into a repeatable, governed developer workflow that reduces developer friction while giving platform and security teams isolation, visibility, and policy enforcement at each layer.

TL;DR

The tables are a good place to start; from there, you can decide where to dive deeper.

Note: For a high level summary of this blog post, see From Shadow AI to Enterprise Asset: A Seven-Layer Reference Architecture for Docker's AI Stack.

Who This Is For

This article is for platform engineering, developers, security, and DevEx leaders who need a practical way to move AI agents and tools from a “cool experiment” to a governed, repeatable workflow. You’ll get a 7-layer architecture that maps Docker’s AI tools to real enterprise concerns (identity, supply chain, isolation, observability, and tool governance), plus clear “where it fits” guidance for each layer. This isn’t a full implementation guide or a product pitch; it’s a mental model and blueprint you can use to align teams, pick controls, and reduce Shadow AI drift.

This post walks through the architecture in the order a developer typically encounters each capability. In practice, several of these layers operate concurrently.

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.

The Architecture: Layer by Layer

1) Foundation — Approved images and hardened supply chain (Docker Hardened Images + Registry Access Management + Image Access Management)

Before any agent runs, the platform engineering team establishes a secure foundation that underpins the entire pipeline. Docker Hardened Images (DHI) follow a distroless philosophy, stripping unnecessary components like shells, package managers, and debugging tools to dramatically reduce attack surface and improve vulnerability posture through curated maintenance and transparent CVE reporting. (Docker, "Introducing Docker Hardened Images"; Docker, "FedRAMP Compliance with Hardened Images") Every image ships with a complete Software Bill of Materials (SBOM), SLSA Build Level 3 provenance, and transparent public CVE data. (Docker, "Introducing Docker Hardened Images")

DHI is now free and fully open source under the Apache 2.0 license, with a catalog of over 1,000 images and Helm charts built on Alpine and Debian. Organizations needing SLA-backed CVE remediation (under seven days for critical and high-severity vulnerabilities), FIPS-enabled images, or extended lifecycle support can upgrade to DHI Enterprise. (Docker, "Hardened Images for Everyone")

This foundation layer 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. Docker is actively extending its hardening methodology to MCP server images, with hardened versions of popular servers like Grafana, MongoDB, and GitHub already available. (Docker Press Release, December 17, 2025)

To enforce this foundation at the organizational level, Docker's Registry Access Management (RAM) provides DNS-level filtering that controls which registries developers can access through Docker Desktop. Admins maintain an allowlist of approved registries; any pull or push to a registry not on the list is blocked. Docker's Image Access Management provides complementary controls over which types of images can be pulled from Docker Hub — Docker Official, Verified Publisher, Organization, or Community images — including repository allow lists. Docker recommends combining both for comprehensive coverage. (Docker Docs, "Registry Access Management"; Docker Docs, "Image Access Management")

Cloud Native Now reports that future Docker Desktop updates will enable teams to publish and manage their own MCP servers using enterprise controls such as Registry Access Management (RAM) and Image Access Management (IAM), letting platform teams apply familiar governance mechanisms to agent tooling. (Cloud Native Now, "Docker Embraces MCP")

Operational note: Because distroless images omit interactive debugging tools, Docker recommends approaches like attaching a debug sidecar (e.g., Docker Debug) or using multi-stage builds rather than modifying the hardened image itself. (Docker Docs, "Distroless Images")

2) Definition — Agents as configuration (cagent)

Instead of ad-hoc Python scripts, developers define agents in a declarative YAML configuration. Docker's open-source cagent framework uses a "root agent + sub-agents" model, where the root agent delegates work to explicitly defined sub-agents, each with its own model, parameters, and tool access. cagent is bundled in Docker Desktop 4.49 and later, so developers can start building agents without a separate installation step. (Docker, "cagent Comes to Docker Desktop")

cagent supports external tools via MCP servers, and offers model flexibility across providers — OpenAI, Anthropic, Google Gemini, or local models via Docker Model Runner — without rewriting the overall agent workflow. Agents are packaged as OCI artifacts, meaning they can be pushed, pulled, and shared through Docker Hub or any OCI-compatible registry, just like container images. This makes agent configurations versionable, reviewable, and distributable through the same supply-chain controls the platform team already enforces for container images. (Docker Docs, "cagent")

3) Inference — Local-first economics (Remocal + Docker Model Runner)

Docker's "Remocal" (Remote + Local) framing encourages pairing local-first development with "Minimum Viable Models" (MVMs) — the smallest, most efficient models that solve the core problem effectively. The idea is to iterate quickly, reduce dependency on external APIs, and keep cost and latency more predictable during development, reserving cloud-scale models for production workloads that genuinely require them. (Docker, "Remocal + Minimum Viable Models")

Docker Model Runner is the local execution layer. It runs models locally and serves them through OpenAI-compatible and Ollama-compatible APIs, with support for three inference engines: llama.cpp (the default, works on all platforms), vLLM (for high-throughput inference on NVIDIA GPUs), and Diffusers (for image generation on Linux with NVIDIA GPUs). Models are stored as OCI artifacts and cached locally after the initial pull. (Docker Docs, "Model Runner")

Because cagent's YAML config specifies which model to use, swapping between a local MVM and a cloud-hosted frontier model is a one-line change — no workflow rewrite required. This is where the Definition layer and Inference layer connect directly.

When workloads exceed local resources, Docker Offload extends your local Docker workflow into cloud infrastructure. It uses the same Docker CLI commands (docker build, docker run) but executes them on cloud-hosted machines, with NVIDIA L4 GPU acceleration currently in beta and broader GPU support described as arriving in 2026. (Docker, "Model Runner Product Page"; Docker, "Docker Offload")

4) Execution — Isolated autonomy (Docker Sandboxes)

When an agent needs broad freedom, such as editing files, installing dependencies, running tests, or building containers, Docker Sandboxes provide the execution environment. Each sandbox is a dedicated microVM with its own kernel, filesystem, and private Docker daemon. The agent can build images, start containers, and run tests without any access to the host Docker environment. Only the project workspace is mounted; the agent cannot see host containers, images, volumes, or the host Docker daemon. (Docker Docs, "Sandboxes Architecture")

This is the layer that wraps and contains the work defined in layers 2 and 3. The developer defines the agent (cagent YAML), selects a model (Model Runner or cloud), and then the sandbox provides the isolated environment where all of that actually executes. Docker describes it as hypervisor-level isolation: unlike containers (which share the host kernel), the sandbox VMs have separate kernels and cannot access host resources outside their defined boundaries. Network isolation is configurable via allow/deny lists. When a sandbox is removed, the entire VM and its contents are deleted. (Docker, "Docker Sandboxes: Run Agents Safely")

Docker Sandboxes currently support Claude Code, Codex, Copilot, Gemini, cagent, Kiro, OpenCode, and custom shell with microVM-based sandboxes available on macOS and Windows. cagent can be run inside a sandbox with YOLO mode for fully autonomous operation. (Docker Docs, "Sandbox Agents"; Docker Docs, "cagent Sandbox")

For standard (non-agent) containers in everyday development, Enhanced Container Isolation (ECI) provides complementary protection. ECI runs all user containers with Linux user namespaces via the Sysbox runtime, mapping container root users to unprivileged users inside the Docker Desktop VM. Together, Sandboxes and ECI cover both agent and non-agent workloads. (Docker Docs, "Enhanced Container Isolation")

5) External Access — Governed tool use (Docker’s MCP Catalog and Toolkit, including MCP Gateway)

Throughout its work, an agent may need to interact with external systems: GitHub, Jira, databases, search APIs, and more. The MCP Gateway governs all of these interactions. It runs MCP servers in isolated Docker containers with restricted privileges, network access, and resource usage. The Gateway manages each server's full lifecycle: starting a server when an AI application requests a tool, injecting required credentials (managed via Docker Desktop’s secrets store and OAuth flows), applying security restrictions, and forwarding requests. It includes built-in logging and call-tracing capabilities for visibility and governance of tool activity. (Docker Docs, "MCP Gateway")

The MCP Gateway works behind the scenes for both cagent-defined agents (which specify MCP toolsets in their YAML) and for interactive coding agents like Claude Code and Copilot in VS Code. It acts as a centralized proxy: instead of configuring each MCP server for every client individually, you configure the Gateway once and connect all clients to it. The Gateway is open source. (Docker, "MCP Gateway: Secure Infrastructure for Agentic AI")

Rather than letting every developer find and run random MCP servers, Docker's MCP Catalog provides a curated collection of 300+ (and growing) verified MCP servers packaged as Docker images with versioning, provenance, and security updates. Organizations can also create custom catalogs scoped to their approved servers — a natural extension of the "approved images" pattern into "approved tools." Docker is applying additional trust measures to the MCP ecosystem, including automated review of incoming changes with structured reporting. (Docker Docs, "MCP Catalog")

6) Observability — Continuous monitoring and audit (Docker Scout + Gateway logging)

A governed architecture requires continuous visibility, not just point-in-time checks. Two capabilities provide this across the stack.

Docker Scout analyzes container images to produce and consume SBOMs, matching them against a continuously updated vulnerability database to identify known issues in image components. This applies to every layer that involves container images: DHI base images, application images, and MCP server images from the Catalog. Scout provides ongoing supply-chain visibility across the full architecture. (Docker Docs, "Docker Scout")

MCP Gateway logging and call tracing provides the audit trail for agent activity. When logging is enabled (via the --log-calls flag), tool calls that pass through the Gateway are logged and traced — including which tool was invoked and the request/response details. The Gateway also supports interceptors like signature verification (ensuring MCP container images have valid provenance before use) and secret blocking (scanning payloads for credentials that shouldn't be exposed). Together, these give platform and security teams the observability they need to answer "what did the agent do and why." (Docker, "MCP Gateway: Secure Infrastructure for Agentic AI"; GitHub, docker/mcp-gateway)

7) Identity — Authentication and policy enforcement (SSO + SCIM)

Identity is the layer that binds all other layers together. Without knowing who is pulling images, defining agents, running sandboxes, or invoking tools, governance policies have no teeth and audit trails have no meaning.

Docker Business supports SSO for authenticating via an identity provider, and SCIM provisioning for ongoing user lifecycle synchronization between an IdP and Docker. This is the prerequisite for policy enforcement across the entire architecture: RAM policies only take effect when users sign in to Docker Desktop with organization credentials, Image Access Management controls are scoped to authenticated users, and MCP Gateway tool access can be governed by identity. (Docker Docs, "Single Sign-On")

When a developer joins or leaves the organization, SCIM ensures their Docker access is provisioned or revoked automatically. This closes the loop on the governance model — ensuring that the Foundation layer's image controls, the External Access layer's tool governance, and the Observability layer's audit trails all tie back to verified, managed identities.

Strategic 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

I spent a week of my free time studying Docker's recent AI-focused releases. It occurred to me that these offerings could be woven together to create a comprehensive ecosystem that solved a lot of the problems developers and enterprise teams are facing these days.

I read documentation and used Gemini and Google's NotebookLM (audio overviews, slides, videos, chat) to build my understanding of each component. This was the conceptual work of finding the patterns, figuring out how these separate products compose into a layered architecture, and identifying the connections between them.

Once I had found the common thread of how all these features could be woven into a comprehensive architecture, I used multiple different AI tools and my own writing and research skills to iteratively write and fact check this article. I finished off the process with one last manual overview.

Building AI-Powered Projects: My Complete Claude Development Stack

Alden Weaver — Tue, 11 Nov 2025 06:08:39 +0000

Tools at a Glance

Category	Tool	Purpose	Experience Level
Planning	Claude Projects	Organize chats, PRDs, epics	Beginner-friendly
	Research Mode	Deep analysis & competitive research	Beginner-friendly
	B-Mad Method	Structured agent-based development	Intermediate
Development	Claude Code CLI	Primary development interface	Beginner-friendly
	Claude Code Browser	Experimental parallel tasks	Experimental
	Claude API	AI-powered features	Intermediate
Parallel Dev	Conductor	Visual branch management	Intermediate
	Git Worktrees	Alternative parallel development	Advanced
Environment	VS Code	IDE	Beginner-friendly
	GitHub Desktop	Visual Git client	Beginner-friendly

New to Claude Code? Check out my beginner's guide to getting started with Claude Code (coming soon!) for a step-by-step introduction to AI-assisted development.

Introduction

This post outlines my current toolkit for developing with Claude AI. As these technologies evolve rapidly, I'm committed to continuous learning and updating my stack.

Where This Stack Really Shines

While I can't share specifics about my proprietary enterprise work, this stack has proven invaluable for large-scale projects involving:

Multiple interconnected services and APIs

Complex business logic requiring careful planning

Teams collaborating on different features simultaneously

Projects with 10+ epics and 50+ user stories

The structured approach (B-Mad Method) combined with parallel development (Conductor) makes it possible to maintain velocity and quality even as projects scale.

How I Wrote This Article

I wrote the initial draft in my natural stream-of-consciousness style, outlining the tools I actually use. Then I asked Claude to refine. The core ideas and tools are mine—the polish and organization are collaborative.

Planning & Ideation

Brainstorming with Claude Projects: I use Claude AI's Projects feature extensively, which allows me to organize chats into folders with reusable project knowledge. I can upload files for context, view memory, and add custom instructions to refine responses. This is where I generate PRDs (Product Requirements Documents), epics, and stories.

Deep Research: When I need in-depth analysis—such as researching best practices or conducting competitive analysis—Claude's Research mode is invaluable.

Large-Scale Projects: For bigger projects, I use the B-Mad Method, a comprehensive framework for agent-based development with Claude Code. From brainstorming through PRDs, epics, stories, development, and QA, there's a specialized agent for each phase. The workflows are well-documented, and you can adopt as many or as few components as your project needs.
UPDATE (11-16-25): There is also a quick spec flow for "Bug fixes, small features, rapid prototyping, and quick enhancements” - BMad Quick Spec Flow

Development with Claude

Claude Code CLI: My primary development interface.

Claude Code in Browser (Beta Research): I'm experimenting with this for handling multiple concurrent development tasks. It's useful for working on different aspects of code simultaneously, though I'm still exploring its optimal use cases.

Claude API: When building AI-powered features, I integrate the Claude API directly. Security best practice: store your API key as an environment variable, never in your codebase.

@ Context Management: The @ mention feature helps manage context by referencing specific files. Pro tip: I spent way too long copying and pasting file paths before I discovered this!

Custom / Commands: I create custom commands stored in a .claude folder at my project root. (Note: if you're using the B-Mad Method, which also uses this folder for its agents, organize your custom commands in a separate subfolder for clarity.) Future goal: package my custom commands as an npm module!

Parallel Development

I've found parallel development most effective when epics and stories are planned with concurrency in mind. When working with Claude to generate project structure, I specifically request stories designed for parallel development.

My preferred approach: Conductor. While Git worktrees are a viable alternative for parallel development, I prefer Conductor because it provides better visual tracking of concurrent branches. The main caveat: performance can degrade with too many active branches, though this will likely improve as the tool matures.

Experimentation: I'm also exploring Claude Code in Browser (Beta Research) for managing concurrent development tasks, though I haven't used it extensively enough to recommend it as a primary parallel development solution.

Development Environment

IDE: Visual Studio Code

Version Control: GitHub Desktop (I can use CLI but appreciate a well-designed GUI)

What's your Claude Code stack? Drop a comment below—I'd love to hear what tools and workflows you're using!

About the Author: I'm a software engineer with 10+ years of experience, currently working on AI-powered SaaS platforms. I'm passionate about using technology for good and continuously learning new tools.

Connect: LinkedIn | GitHub | Portfolio