Giving AI Agents "Hands": Securely Controlling Docker with MCP

From "Knowing" to "Doing": The Next Step for AI Agents

In the previous stage, we gave AI memory and protocols, letting it read lab data and understand the state of the infrastructure. But as the video's author puts it, all of this stays at the level of "knowing"—the AI can sit on the couch like a knowledgeable friend and tell you the state of your system accurately and uselessly.

The real turning point is giving it "hands." And the choice of that first pair of hands matters enormously, because it sets the habits. The author chose Docker, for clear reasons: containers are already the environment we're familiar with in this series; Docker has a clean, well-defined control plane (list, inspect, logs, stats, start, stop, restart); every action has a name, and anything with a name can be allowed or denied individually; and more importantly, it has a natural "blast radius knob"—a Docker control tool only talks to the host you point it at, so you can hand a sacrificial machine to the AI while keeping what actually matters out of reach.

By contrast, handing the AI a raw shell gives you a nearly unlimited attack surface. The author's principle: the first pair of hands should be capable, legible, and controllable.

Ratel: The N+M Dividend of an MCP Server

The tool is called Ratel (the honey badger—small, fearless, in keeping with the lab's "zoo" naming style). The key point is that Ratel is an MCP server. That means no integrations to write, no APIs to stitch together—the clients already speak the protocol, so once it's deployed and connected, every AI brain in the lab immediately knows how to grip this new tool.

This is the N+M dividend planted in the previous episode: one integration, and every AI client automatically gains the new capability—and it keeps paying off with every tool that follows.

MCP (Model Context Protocol) is an open protocol proposed and open-sourced by Anthropic in late 2024, aiming to standardize "how AI applications connect to external tools and data sources." It uses a client-server architecture: AI clients (such as Claude Desktop, various IDE plugins, and custom agent frameworks) act as MCP Clients and communicate with MCP Servers via JSON-RPC; the Server exposes a set of tools, resources, and prompt templates in a unified schema. For tool developers, this means implementing a Server once lets every MCP-compatible client plug and play, with no need to write separate integration code for each AI platform. The so-called "N+M dividend" comes precisely from this: what would once have required N×M adaptations between N AI clients and M tools drops to N+M once the protocol standardizes things.

The Core Deployment Risk: What the Docker Socket Means

Ratel consists of two parts: a gateway that AI clients connect to, and a small node deployed on each Docker host. For the node to control Docker, it must be given the Docker socket.

The author slows down here, because almost every tutorial glosses over this point. In plain terms: anything that can access the Docker socket can do anything on that machine—not just manage containers. It can launch a container that mounts the entire filesystem and read every file on the machine. This isn't a flaw in Docker; it's exactly what the socket is designed to do.

One thing worth remembering in particular: many people online add a read-only flag to the socket mount, thinking that makes it safe. The author admits he once believed this too. But that flag only makes the socket file read-only—it has no effect on the commands you send through it. In a later demo, the tool will restart a container through exactly this kind of mount—a write operation. If the read-only flag actually worked, the demo couldn't run at all.

What actually makes it safe is where you point it. Ratel doesn't touch the cluster or the critical tier today—it only gets a spare little machine sitting on the workbench, outside the cluster, running a few deliberately unimportant demo apps. Its job description is "sacrificial": it carries nothing, and nothing trusts it. Scope first, trust second, expand gradually—this reflex applies to every capable tool you deploy.

The Docker socket (/var/run/docker.sock) is the Unix domain socket exposed by the Docker daemon (dockerd). The Docker CLI talks to the daemon through it, issuing commands to create, start, stop, and delete containers. Whoever can read and write this socket is effectively equivalent to having root on the host: an attacker can make the daemon launch a privileged container that mounts the host's root filesystem, thereby reading and writing arbitrary files and escaping to the host. It's precisely for this reason that the community saying "mounting the socket means handing over the machine" is no exaggeration. The read-only mount flag only governs whether the socket file itself can be written; API requests sent over an already-established connection are not subject to that flag, so it cannot restrict any container operation.

Demo: From Diagnosis to Action

On the sandbox host, a demo app is unhealthy, crash-looping and restarting constantly. The author planted a typo in a config file beforehand—the kind of failure that really happens in the wild. The AI knows nothing about it.

The question is asked in plain language: "The web app on the sandbox host is down—can you check why?"

What follows is the highlight of the whole episode: list the containers, see the restart count, spot the crash loop; pull 50 lines of logs, and actually read them; find the stack trace, trace it back, and report in plain language—the app failed to start because a config value is malformed, here's the line, here's the value, and here's probably what it should be.

The author's assessment is measured: the model isn't doing magic—it's doing triage, the same loop you'd run yourself: read logs, find errors, form hypotheses. But it does it in an instant, it doesn't need sleep at 1 a.m., and it explains itself in natural language. The diagnosis alone is worth the price.

But so far, everything has been "read." Now cross that line: the author fixes the config, and the app needs a restart to take effect. Instead of typing the command himself, he says "just restart it." And the container restarts—the state of a real machine in this room changed because a language model judged the request reasonable and had a tool that could execute it. The app recovers, and the AI even checks its own work: pulls fresh logs, confirms a clean startup, and reports back.

The author asks viewers to feel two things at once: this is genuinely useful—diagnosis plus fix, hands-free, exactly the dream this whole series has been building toward; but it should also make the hair on your arms stand up. Reading can't break anything; doing can. Everything in the episodes ahead grows out of taking that second feeling seriously.

Permission Tiers: AI Tool Safety in One Sentence

Ratel's permissions are divided into tiers, and the design philosophy is worth borrowing.

Tier one: granted by default. This covers read operations (list, inspect, logs, stats) plus "safe writes"—start, stop, restart, pulling images. Why are these default? Because they're the daily workhorses, and their worst case is bounded and recoverable. A mistaken restart is an apology, not an incident.

Tier two: explicit opt-in every time. These are the destructive operations: deleting containers, executing arbitrary commands inside a container, launching brand-new containers.

Why are new containers dangerous? For the same reason the socket is: a new container can be given the entire machine. If you want to give the AI those powers, you have to grant them deliberately, with scope, with a reason—and the tool makes you say so out loud.

Reads and safe writes by default; destructive operations require deliberate consent—that one sentence is most of practical AI tool safety. Use that line to examine any tool anyone hands you: find the line, and see who has to sign before you cross it.

The Principle of Least Privilege is a foundational rule in information security: any subject should be granted only the minimum permissions necessary to complete its task, and only for as long as necessary. The permission tiers in this article are exactly this principle applied to AI tools—splitting tool capabilities by risk, opening reads and safe writes by default, and requiring explicit, per-action authorization for destructive operations. Common companion mechanisms include the "human-in-the-loop" approval gate and "checks that don't trust the executor": the former forces a pause for human confirmation before a dangerous action runs, while the latter has validation logic independent of the model verify results afterward. Together they reduce the real-world harm from model misjudgments.

Reality Check: Designing for "Well-Intentioned Misunderstanding"

The author offers a prediction, which he considers more honest than dodging the question: an agent with hands will eventually do something you didn't intend. Not because it's malicious, but because your instructions weren't precise enough. You say "clean up the old containers," thinking of those two; it interprets "old" broadly—and is literally entirely correct.

The failure isn't the model disobeying; it's the model obeying a sentence you didn't really mean. Humans run into this too when giving instructions to another person. So design for that day instead of praying around it: keep the scope small—one host, until there's a real reason to add a second; put destructive powers behind explicit consent; and coming soon, checks that don't trust the executor, plus gates where dangerous operations inevitably stop and wait for a human.

The honest end state isn't an AI I fully trust, but a system where trust isn't a load-bearing structure.

Next Episode: Giving AI "Eyes"

The gap left today: the AI restarted the app and read the logs to confirm it started. But "the process came up" and "the website actually works" are two different claims, and right now the AI can only verify the former. The next episode gives it a real browser—sandboxed, controlled, pointed at the lab—so it can actually see what it did. The loop starts to close.

This article is based on content from the Smart Workshop channel's video on MCP and Docker control.

One-line Summary

Giving AI its first pair of "hands" via the MCP server Ratel to control Docker, demonstrating the leap from diagnosis to action and laying down principles for AI tool safety through permission tiers and scope control.

Paragraph Summary

The article covers the key step in AI agents moving from "knowing" to "doing": choosing Docker as the first pair of "hands" because of its clean control plane, nameable actions, and adjustable blast radius. The tool Ratel plugs in as an MCP server, so one deployment gives every AI client in the lab Docker capabilities—the N+M dividend realized. The author stresses that the Docker socket equals arbitrary power on a machine, that the read-only mount flag does nothing against this, and that real safety comes from scoping to one sacrificial host. In the demo, the AI reads logs, locates a config typo, and successfully restarts the app—showing both value and risk. From this comes a tiered permission model: reads and safe writes by default, destructive operations requiring explicit consent, and designing for "well-intentioned misunderstanding."