Add a configurable networking policy for spawned Docker/Podman workloads so local-LAN access can be restricted by default, with an explicit opt-in when LAN access is required.
Problem
By default, Docker and Podman containers can often reach devices on the same LAN segment as the host (NAS, printers, routers, IoT devices, internal services, etc.).
For agent-driven or untrusted workloads, this increases blast radius:
- Containerized tasks can probe or connect to private LAN devices
- Sensitive internal services may be reachable unintentionally
- Users may assume container isolation is stricter than it is
This is a security/usability gap: users need a clear and simple way to prevent LAN egress unless explicitly allowed.
Proposal
Introduce a networking policy setting for runtime/container execution, for example:
lan_access = "blocked" | "allowed" (or equivalent boolean defaulting to blocked)- CLI override flags (e.g.
--allow-lan, --block-lan)
Default behavior should prefer safety:
- Block container access to RFC1918/private ranges and other local-link/LAN targets by default
- Keep normal internet egress behavior configurable (implementation-dependent)
- Allow explicit per-run override when users need LAN reachability
Implementation can use backend-specific mechanisms (iptables/nftables rules, Podman network config, Docker network policy, custom bridge isolation, etc.), but should present one consistent product-level behavior.
Scope
- Define a user-facing LAN access policy in config
- Add CLI-level override for one-off runs
- Apply policy consistently across Docker and Podman backends
- Document exact blocked address ranges and behavior
- Surface active policy in logs/output so users can verify at runtime
Add a configurable networking policy for spawned Docker/Podman workloads so local-LAN access can be restricted by default, with an explicit opt-in when LAN access is required.
Problem
By default, Docker and Podman containers can often reach devices on the same LAN segment as the host (NAS, printers, routers, IoT devices, internal services, etc.).
For agent-driven or untrusted workloads, this increases blast radius:
This is a security/usability gap: users need a clear and simple way to prevent LAN egress unless explicitly allowed.
Proposal
Introduce a networking policy setting for runtime/container execution, for example:
lan_access = "blocked" | "allowed"(or equivalent boolean defaulting to blocked)--allow-lan,--block-lan)Default behavior should prefer safety:
Implementation can use backend-specific mechanisms (iptables/nftables rules, Podman network config, Docker network policy, custom bridge isolation, etc.), but should present one consistent product-level behavior.
Scope