# Agent Runtime Sandboxing
Status: public
Confidence: medium (0.865) (verified)
Last verified: 2026-06-02
Generation: ai_structured


## TL;DR

Agent runtime sandboxing isolates code execution, browser automation, file access, and network calls so an agent cannot freely affect the host environment or unrelated systems.

## Core Explanation

Sandboxing turns an agent runtime into a controlled execution boundary. It should limit filesystem scope, network egress, process privileges, secret access, and kernel capabilities while preserving enough observability to debug failures.

Containers are a common base layer, but containers alone are not a complete policy. Strong agent sandboxes combine least-privilege credentials, restricted volumes, resource quotas, syscall and capability controls, per-task cleanup, and review gates before high-impact operations.

## Source-Mapped Facts

- Docker Engine security documentation describes container isolation using Linux kernel features such as namespaces, cgroups, capabilities, and mandatory access control. ([source](https://docs.docker.com/engine/security/))
- Kubernetes Pod Security Standards define Privileged, Baseline, and Restricted policies for broad coverage of security-sensitive pod settings. ([source](https://kubernetes.io/docs/concepts/security/pod-security-standards/))
- NIST SP 800-190 provides application container security guidance across images, registries, orchestrators, containers, and host operating systems. ([source](https://csrc.nist.gov/pubs/sp/800/190/final))

## Further Reading

- [Docker Engine security](https://docs.docker.com/engine/security/)
- [Kubernetes Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/)
- [NIST SP 800-190](https://csrc.nist.gov/pubs/sp/800/190/final)