The sandbox's OS-level identity should have the minimum filesystem, API, and system permissions needed for the specific task — not the permissions of the host, the container orchestrator, or the wider agent deployment.

Non-root execution: The sandbox should run as a non-root user with no sudo access. Root inside a container may still be root on the host in misconfigured deployments.

Read-only filesystem: Where possible, mount the working filesystem as read-only and provide a separate, writable ephemeral directory for output. This prevents code from modifying system files or persisting across sessions.

No privileged container flags: The --privileged Docker flag grants the container near-full access to the host kernel. Never use it for agent sandbox containers.

No mounted Docker socket: Mounting /var/run/docker.sock into a container grants complete control over the Docker daemon and is a well-known container escape path. Never mount it in an agent sandbox.

The single most effective control against credential exfiltration via generated code is ensuring the credentials are not in the execution environment to begin with.

No environment variable secrets: API keys, database passwords, and access tokens must not be present as environment variables in the sandbox. If the agent needs to call an API, the call should be made through a proxy or sidecar that holds the credentials outside the sandbox — not by passing credentials into code the agent can read and exfiltrate.

No cloud metadata API access: Block access to cloud metadata endpoints (169.254.169.254, fd00:ec2::254) from the sandbox network namespace. These endpoints return IAM credentials to any process that can reach them.

Short-lived, scoped tokens if needed: If the task genuinely requires credentials, use short-lived, task-scoped tokens that expire immediately after the task completes — not long-lived credentials that persist if the sandbox is compromised.