Blocking Container Escapes: Aider and Docker --privileged

Correction note (2026-10-13). The per-call timings and latency figures that appeared in this article had no benchmark behind them and were removed. Sample output in this article is illustrative, not a recorded run. The only published measurement is p50 0.39 ms and p99 1.91 ms (sigmashake-bench daemon-socket run, 2026-06-10, ssg 0.29.156, n=500). Sub-2 ms evaluation is a design target. The local audit log records decisions on a best-effort basis: entries can be dropped if the daemon queue is full, and old rows are deleted at the row caps. It is local, not append-only, and not immutable.

Describe the task

Aider encounters a permission error while running a development database container. To work around it quickly, the agent adds the --privileged flag:

docker run --privileged -v /:/host alpine sh

A privileged container has full access to all host Linux capabilities and devices. Mounting the root filesystem (/:/host) gives it — and any agent controlling it — read/write access to everything on the host. SSG blocks this immediately.

# illustrative sample output
[BLOCK] bash › docker run --privileged -v /:/host alpine — rule: no-docker-privileged

Give SSG context

SSG evaluates Aider's shell commands via the SSG MCP Server integration for Aider sessions.

Required context

rule no-docker-privileged {
  enabled true
  priority 100
  severity error
  DENY execution
  IF command STARTS_WITH "docker run "
  AND command CONTAINS "--privileged"
  MESSAGE "Privileged containers can escape to the host. Use specific capabilities instead."
}

Optional context

Also block dangerous volume mounts:

rule no-docker-root-mount {
  enabled true
  priority 100
  severity error
  DENY execution
  IF command STARTS_WITH "docker run "
  AND command CONTAINS "-v /:"
  MESSAGE "Mounting the root filesystem is blocked. Use a scoped volume path."
}

What SSG does

SSG checks for --privileged in the raw docker run command before any container is created. No container process is started — the block fires at the tool-call layer.

Ask the agent to use specific capabilities instead

--privileged was blocked. Add only the specific Linux capability you need instead:
  docker run --cap-add=NET_ADMIN ...  # for network operations
  docker run --cap-add=SYS_PTRACE ... # for debugging
Don't mount the root filesystem — use a named volume or specific directory.

This principle of least privilege gives the container what it needs without exposing the host.

Block dangerous compose configurations

SSG can also intercept docker compose up — but for compose-level governance, pair with a write rule on docker-compose.yml:

rule no-compose-privileged {
  enabled true
  priority 90
  severity error
  DENY write
  IF path ENDS_WITH "docker-compose.yml"
  AND content CONTAINS "privileged: true"
  MESSAGE "privileged: true in compose config is blocked."
}

Audit container launches in CI

SSG logs docker run commands, blocked or allowed, on a best-effort basis with the full arguments. Use ssg dashboard to verify that your CI pipelines aren't using privileged mode without your knowledge.

How your rule handles flag ordering

Docker flags can appear in any order: docker run --privileged ... and docker run -d --privileged ... both match because you're using CONTAINS "--privileged". This approach is more robust than STARTS_WITH for flag-heavy commands.

Check the rule against your dev tooling

Some local development tools (like Docker Desktop with Lima on macOS) require privileged mode for certain volume features. Whitelist those specific images by adding a higher-priority ALLOW rule for the exact image name.