Governance
Configure fix approvals, protected paths, and account settings in one place.
Research
Choosing an isolation boundary for untrusted agent workloads
Why container hardening, kernel exposure, and workload authority must be evaluated together.
Isolation is a threat-model decision
A container is a useful packaging and isolation mechanism, but its protection depends on how it is configured and what it is asked to contain. An internal service running trusted code presents a different risk from an agent executing arbitrary repository scripts or processing adversarial files. The right boundary follows from the workload's potential authority and the consequences of escape.
Docker's security documentation describes the roles of kernel namespaces, control groups, daemon access, and other isolation features. These mechanisms solve different problems. A resource limit can reduce denial-of-service risk without proving separation from host secrets, and a separate filesystem view does not eliminate exposure to a shared kernel.
Inventory authority before adding controls
List the credentials, mounted paths, devices, network destinations, and host interfaces available inside the workload. A container that can access a host management socket may already possess more authority than the surrounding application assumes. Broad bind mounts can defeat an otherwise careful distinction between the workspace and sensitive host files.
For an agent runner, include package installation hooks, test scripts, build tools, and child processes in the inventory. The model is not the only source of behavior. Repository content and dependencies can determine what runs after an apparently routine command, so the runner's permissions must be safe for that broader execution surface.
Use several independent restrictions
Run with the minimum capabilities and filesystem permissions needed by the task. Restrict writable paths, avoid unnecessary device access, and separate credentials by job and purpose. Apply system-call filtering and mandatory access controls where supported, while keeping the policy compatible with the actual build and test workflow.
Network control should cover both outbound access and destinations reachable through local or private routes. A failed attempt to contact one public host does not show that the workload cannot reach cloud metadata, an internal service, or another tenant. Make the intended access explicit and test it from the workload's actual network context.
Consider a stronger execution boundary
When the workload may run adversarial code, compare ordinary containers with alternatives such as a dedicated virtual machine or a microVM-based runner. A different kernel boundary can reduce some shared-kernel exposure, but it introduces its own patching, image, networking, and operational responsibilities. It is not a substitute for limiting credentials or unnecessary mounts.
Choose the design by testing representative workloads and failure cases. Measure startup cost, supported tools, artifact transfer, observability, and cleanup behavior. The security decision should account for both the theoretical isolation property and the practical likelihood that operators will disable inconvenient restrictions to keep jobs running.
Verify containment continuously
Create benign boundary checks for filesystem access, process visibility, network policy, and secret availability. Run them after runner updates and configuration changes. Distinguish a policy denial from a missing tool or unrelated connectivity failure, and preserve enough evidence to understand why a check passed.
Patch the host kernel, runtime, and guest images as applicable. Recreate short-lived workers rather than allowing state and credentials to accumulate across tasks. The useful conclusion is conditional: a particular workload has specified controls and tested limitations. Neither an unqualified claim that containers are safe nor a blanket claim that they are useless provides enough information for an engineering decision.
