Use a layered model. Start with code execution isolation to contain untrusted generated code, then add resource and network containment to limit filesystem, egress, and credential exposure. For production agents that invoke tools or APIs, add behavioral enforcement so policies reflect observed runtime actions, not guesses about intent. Isolation reduces blast radius. Behavioral controls stop misuse inside the boundary.
Why Kubernetes sandboxing for AI agents needs two layers
When an agent can execute code and invoke tools, treat those as separate trust problems inside the same runtime. Code execution isolation protects the cluster from arbitrary generated code, while tool controls govern what the agent can reach once it is inside the sandbox. If you only harden one layer, the other becomes the easiest path to file access, network egress, or secret exposure.
In practice, the strongest designs assume the sandbox is a containment boundary, not a guarantee of good behaviour. That means the pod, runtime, and node controls should be tight enough that a bad prompt, a malicious dependency, or a malformed output cannot automatically expand into broader cluster access. The goal is to keep the agent useful while making each additional capability explicitly permitted.
For teams that want a structured starting point, NHIMG’s AI Agent Sandboxing and Code Execution Guide covers the runtime choices and containment controls that matter most when agents run untrusted code.
What the sandbox has to contain in Kubernetes
The first containment problem is code execution. An agent that writes or runs code needs filesystem restrictions, process limits, and a runtime boundary that reduces the chance of escape or cross-pod impact. In kubernetes, that usually means pairing pod isolation with tight security context settings, minimal base images, and a sandbox runtime that matches the risk of the workload.
The second containment problem is reachability. Even when code stays inside the container, it may still read mounted files, reach metadata services, contact package registries, or exfiltrate data over the network. Resource quotas, network policy, and restrictive mount patterns matter because they limit what the agent can discover or leak if the code path is compromised.
The third containment problem is tool access. Tool calls are not just another API request, because the agent can chain them, repeat them, or select them in response to runtime feedback. A control that works for a static app often fails once the workload can decide which tool to call next. That is why authorization needs to be action-aware rather than based only on the agent's nominal role.
If your deployment also exposes model-driven tool selection, the AI Agent Authorisation Guide is the right companion for separating bounded execution from per-action permission decisions.
How to keep tool use safe without breaking the agent
Use behavioural enforcement when the agent's runtime actions matter more than its declared purpose. A practical policy should consider the actual tool, target, scope, and timing of the request, so the platform can block a harmful action even if the agent appeared legitimate at startup. This is especially important when the same agent can both generate code and use networked tools from within the same pod.
That policy layer should also distinguish between allowed experimentation and high-risk actions. For example, a sandbox may permit local test code to run but still deny access to production secrets, cluster metadata, or external endpoints that are not part of the task. The cleaner the separation between code execution and tool authority, the easier it is to reason about blast radius.
Behavioural controls are also the place to enforce approval for sensitive transitions, such as moving from read-only lookup to write, delete, deploy, or credential-bearing operations. If the runtime can make that jump without an explicit policy check, the sandbox becomes a staging area for misuse rather than a boundary.
When the main concern is not just code safety but agent misuse inside the boundary, NHIMG’s Agentic AI Security Guide is useful for mapping inputs, tools, orchestration, and identity into one threat model.
Risk and Threat Considerations
Sandboxes fail when teams confuse isolation with trust. A runtime that contains arbitrary code but still permits broad egress, mounted credentials, or overly capable tool bindings can turn a limited compromise into a full environment event. The main adversarial pattern is simple: get the agent to run something unexpected, then use its permitted paths to reach data, secrets, or external services.
Failure mechanism: The agent inherits more filesystem, network, or tool authority than the task really needs, so malicious or mistaken code can pivot through the sandbox boundary instead of being trapped by it.
Impact: The result can be secret exposure, destructive tool actions, lateral movement into adjacent workloads, or a false sense of safety because the code was "sandboxed" even though the effective blast radius was still large.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent code and tool use create runtime privilege abuse risk inside the sandbox. |
| Recommendation — Enforce per-action authorization for agent tool calls and sensitive state changes. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Kubernetes agent tooling depends on controlling identities, permissions, and delegated access. |
| Recommendation — Restrict agent identities to least privilege and short-lived access paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The sandbox should limit what the agent can do even after code execution begins. |
| SC-7 — Boundary Protection | Network and filesystem containment are core to limiting blast radius in Kubernetes sandboxes. | |
| SI-3 — Malicious Code Protection | Untrusted generated code needs controls that reduce execution of harmful code paths. | |
| Recommendation — Apply least privilege so the agent can only access the resources required for the task. Isolate sandboxed agents at the boundary to restrict egress and inbound reachability. Inspect and constrain generated code before it can execute in the sandbox. | ||
Practitioner Guidance
What to prioritise: Start by deciding which risk you are actually containing, untrusted code execution, sensitive tool use, or both. If you do not separate those concerns, you will overbuild the sandbox in one area and leave the other undercontrolled.
What to verify: Validate that the pod cannot read more than it needs, reach more networks than it should, or inherit credentials that outlive the task. Then test whether the tool policy still holds when the agent attempts chained actions, retries, or unusual parameter combinations.
Practitioner takeaway: The right design is not "put the agent in a container", it is to make every code path, network path, and tool path independently bounded and explicitly authorised.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org