Security: Docker code executor mounts host filesystem without trust boundary validation (ASI10)

[dockfixlabs]

Description

The Docker code executor at autogen_ext/code_executors/docker/_docker_code_executor.py mounts host filesystem directories into sandboxed containers without explicit trust boundary validation. This allows an agent with code execution capability to escape its container sandbox and access the host filesystem.

Location

python/packages/autogen-ext/src/autogen_ext/code_executors/docker/_docker_code_executor.py

Impact

An agent utilizing this code executor can read, write, or delete files on the host system through mounted volumes, bypassing the intended sandbox isolation. This is a trust boundary violation (OWASP ASI10) where the agent's code execution scope extends beyond its designated sandbox.

Severity

CRITICAL — container escape through filesystem trust boundary violation.

Suggested Mitigation

1. Restrict mounted volumes to explicit, allowlisted paths only
2. Add a security configuration option that defaults to no host mounts
3. Document the trust boundary implications for users who enable host mounts
4. Consider using Docker's --read-only flag where write access is unnecessary

Scanner

Found by AgentGuard v0.6.1 — open-source AI agent security scanner. OWASP ASI Top 10 compliant.

[Tuttotorna]

The core invariant here should be:

container execution authority != host filesystem authority

A Docker code executor may be allowed to run code, but that does not automatically mean the same transition is authorized to read, write, or delete host files through mounted volumes.

I would model every host mount as an explicit transition support record, not as an implicit executor detail.

For each mount, the runtime should be able to prove:

{
"transition_id": "...",
"executor": "docker",
"host_path": "...",
"container_path": "...",
"access_mode": "read | write | read_write",
"purpose": "...",
"policy_ref": "...",
"allowlist_match": true,
"read_only_required": true | false
}

Then the execution is valid only if the required support is present for this exact transition:

Required(container_execution_with_host_mount)
⊆
Supported(explicit_mount_policy + allowlist + access_mode + purpose_binding)

If that relation cannot be proven, the safe default should be:

• no host mounts
• read-only filesystem where possible
• write mounts only with explicit allowlist + purpose + transition binding
• fail closed when mount policy is absent or ambiguous

The important distinction is that the sandbox boundary should be enforced before container startup, not inferred after execution.

So the fix should not only restrict mounts; it should make host filesystem authority an explicit, auditable capability separate from code execution authority.