Skip to main content

Docker AI (Gordon)

How to bring Docker's AI agent (Ask Gordon), dev containers, and WSL under Behavry — and where the honest boundaries are.

The short answer

Behavry governs the MCP traffic, not the host. The enforcement proxy authenticates every call, evaluates it against policy, and writes a Decision Trace whether the agent runs on bare metal, in a dev container, or in WSL. The policy model doesn't change for any of them.

What does change is (a) reachability and credentials, and (b) endpoint-level exposure signal, which is namespace-bound.

Why routing is the lever​

Gordon reaches its MCP tools through Docker's MCP Toolkit / MCP Gateway. Docker describes the Gateway as "a centralized proxy between clients and servers, managing configuration, credentials, and access control" — it aggregates many MCP servers behind one endpoint and injects credentials before forwarding.

That aggregation is exactly the problem for attribution. If Gordon points at Docker's Gateway and the Gateway talks to servers directly, Behavry sees one hop and per-tool attribution collapses. Docker's Gateway does inspection, isolation, and call-tracing — but it has no identity registry, no per-agent RBAC, and no behavioral baseline. That is precisely the gap Behavry fills.

The fix is a drop-in swap: point Gordon's MCP configuration at Behavry's endpoint instead of Docker's Gateway. Behavry's unified proxy does the same aggregation job — one URL, tools namespaced by server — so it slots in where the Docker Gateway target was. Every call Gordon then makes carries an identity, is evaluated against policy, and is logged.

The enrollment recipe​

1. Enroll Gordon as its own agent identity​

A container-context agent acting as the developer blends into that human's activity. Enroll Gordon as a distinct agent identity with its own role set, so its actions stay attributable and don't merge into the operator's Decision Traces.

2. Point Gordon's MCP config at Behavry, not Docker's Gateway​

Gordon can mount a remote HTTP MCP connection. Set that target to Behavry's proxy:

https://<tenant>.behavry.ai/mcp/v1

Register the MCP servers Gordon needs as Behavry backends (see MCP Server Registration). Behavry re-exposes them under one namespaced surface, so from Gordon's side it is a single endpoint — the same shape Docker's Gateway presented.

3. Put policy on what a container agent reaches for​

Gordon leans on container-context tooling — the Docker socket, mounted volumes, and exec / shell tools on the servers it mounts. Treat docker exec and Docker-socket access as high-exposure actions in policy: a socket handle is effectively root on the host, and an exec into a running container is an unlogged shell unless it traverses governance.

4. Route those backends through Behavry too​

Any MCP server that exposes shell, exec, or filesystem tools should be registered as a Behavry backend, not mounted into Gordon directly. Once it is behind the proxy, its tools/list passes through Context Gate, its calls are DLP-scanned, and each action lands in a Decision Trace.

Dev containers and WSL​

The reassuring part first: proxy governance is unaffected. Policy, identity, and Decision Trace are identical for an agent inside a dev container or a WSL distro. Only two practical controls and one signal caveat differ.

Reachability​

The in-container / in-WSL MCP client must hit a reachable Behavry URL, not the host's localhost:

EnvironmentReach Behavry via
Dev container / Docker Desktopthe plane's public URL, or host.docker.internal
WSL2the public URL (WSL2 localhost forwarding is unreliable for this)

Credential lifecycle​

Ephemeral containers that rebuild lose their enrollment. Bake a durable credential into the image or re-enroll on build, or every rebuild re-enrolls as a new actor and fragments the agent's history.

Endpoint exposure (Warden) — the one genuinely reduced signal​

Behavry Wardens — the OS-level endpoint sensor — is namespace-aware, and this is where honesty matters. A host sensor does not cross the container's process namespace or the WSL2 VM boundary cleanly, so exposure-tier attribution for in-container and in-WSL agents is coarse.

Scope Warden coverage, don't assume it

Full proxy-level governance still applies inside containers and WSL — every tool call is authenticated, policed, and traced. It is only the endpoint exposure enrichment (the Operational Exposure tiering that Warden feeds) that is reduced. In-namespace Warden coverage is still cert-gated; scope it with your team rather than assuming it ships for your environment today.

What this does not cover​

Be precise with stakeholders about the boundary.

  • Gordon's built-in tools don't traverse MCP. Gordon ships native shell, filesystem, and fetch tools that execute locally and do not pass through any MCP endpoint — so routing Gordon at Behavry governs the MCP servers it mounts, not its built-in shell or filesystem. To govern those actions, deliver the capability through a governed MCP server routed via Behavry instead of relying on Gordon's built-ins, or cover the endpoint with Warden.
  • Endpoint exposure tiering is coarse across the container / WSL2 boundary (above). Proxy governance is unaffected; only the Warden enrichment is.
  • Scope. This governs what Gordon and container/WSL agents reach through MCP. It does not, on its own, govern arbitrary host commands a developer runs outside an agent.

Where Behavry earns its place​

Docker-native control (MCP Gateway)Behavry adds
Aggregates servers, injects credentialsAn identity on every call, bound to a distinct agent principal
Isolation + call-tracingPer-tool, per-action policy — read_file allowed, docker exec escalated
No identity registry / RBACAgent identity and role-based authorization
No behavioral baselineBehavioral baselines and drift detection
No per-action recordA tamper-evident Decision Trace per action
No data inspectionDLP redaction and inbound injection detection on the traffic

Sources​

Verified against Docker Docs on 2026-07-22. Docker changes this surface frequently; re-check before relying on specifics.