Your AI Agent Can Delete Every Container on Your Machine

Your AI coding assistant just wiped your local Docker environment. You asked it to "clean up that test container," and it decided to be thorough — removed every container, deleted the images they were built from, and destroyed the volumes holding your database state. Your PostgreSQL data, your Redis cache, your Elasticsearch index. Gone. No confirmation prompt, no undo.

It was trying to help. The Docker MCP server gave it the tools to list, create, start, stop, and — critically — remove every Docker resource on your machine. The agent saw old containers, stale images, and orphaned volumes. It cleaned them all. As we explored in What Happens When Your AI Agent Goes Rogue, these aren't edge cases. They're the predictable consequence of giving agents destructive capabilities without constraints.

The ckreiling/mcp-server-docker

MCP server exposes 19 tools. The read operations are harmless — list_containers

, list_images

, list_volumes

, fetch_container_logs

. Fine. Let agents inspect your environment all day.

The problem is the other half:

remove_container

remove_image

remove_network

remove_volume

Then there are the creation and execution tools — create_container

, run_container

, build_image

, pull_image

. Not destructive individually, but a runaway loop pulling hundreds of images or spawning containers will exhaust your disk and CPU in minutes.

MCP provides no built-in mechanism to restrict any of this.

Intercept sits between your agent and the Docker MCP server. Every tools/call

is evaluated against a YAML policy before it reaches Docker. Violating calls are blocked and the agent receives a clear denial message — no silent failures.

First, block all destructive operations outright:

version: "1"
description: "Policy for ckreiling/mcp-server-docker"
default: "allow"
tools:
    remove_container:
        rules:
            - name: "block container removal"
              action: deny
              on_deny: "Removing containers is not permitted. Stop the container instead."
    remove_image:
        rules:
            - name: "block image removal"
              action: deny
              on_deny: "Removing images is not permitted."
    remove_network:
        rules:
            - name: "block network removal"
              action: deny
              on_deny: "Removing networks is not permitted."
    remove_volume:
        rules:
            - name: "block volume removal"
              action: deny
              on_deny: "Removing volumes is not permitted. Volume data could be lost."

Four action: deny

rules. Unconditional. The agent can still stop containers — it just cannot delete anything. When it tries, it gets the on_deny

message as the tool response, telling it what to do instead.

Next, rate limit the creation tools to prevent runaway loops:

    create_container:
        rules:
            - name: "rate limit container creation"
              rate_limit: "10/hour"
              on_deny: "Container creation rate limit exceeded (10/hour). Wait before creating more containers."
    run_container:
        rules:
            - name: "rate limit container run"
              rate_limit: "10/hour"
              on_deny: "Container run rate limit exceeded (10/hour). Wait before running more containers."
    build_image:
        rules:
            - name: "rate limit image build"
              rate_limit: "10/hour"
              on_deny: "Image build rate limit exceeded (10/hour). Wait before building more images."
    pull_image:
        rules:
            - name: "rate limit image pull"
              rate_limit: "10/hour"
              on_deny: "Image pull rate limit exceeded (10/hour). Wait before pulling more images."

Ten per hour on each creation tool. Enough for legitimate development workflows. Not enough to fill your disk.

A global rate limit catches everything else:

    "*":
        rules:
            - name: "global rate limit"
              rate_limit: "60/minute"
              on_deny: "Global rate limit exceeded (60 calls/minute). Slow down."

The default: "allow"

posture lets read tools pass through unrestricted. If you want tighter control, switch to default: "deny"

and explicitly allowlist each tool.

Install Intercept and point it at the Docker MCP server:

npm install -g @policylayer/intercept

Then run it with the Docker policy:

intercept -c docker.yaml -- npx -y @ckreiling/mcp-server-docker

Every tool call now passes through the policy engine. Container removal gets blocked. Image pull number 11 in an hour gets blocked. Your volumes survive the agent's enthusiasm for tidying up.