On this page
The short answer
Evaluate an agent sandbox by defining allowed operations and probing the closest forbidden alternatives. Test files, subprocesses, network access, credentials, and resource ceilings independently. A container starting successfully does not establish isolation, and a blocked command does not prove that another path cannot reach the same protected resource.
What to take away
- Write an operation matrix before running tests.
- Pair every forbidden probe with a permitted control.
- Inspect the host and downstream services for effects.
Sources checked . Research synthesis and Rubrex recommendations. Examples and local experiments are labeled; they are not client results.
Define the boundary at the deployed layers
Kubernetes documents named pod-security profiles and specific workload restrictions. Rubrex recommends treating those controls as part of a layered sandbox design, not a complete agent-isolation certificate. Inventory the runtime, mounted paths, network routes, process permissions, credential exposure, and host interfaces.
Use a synthetic coding task allowed to read a fixture directory, write a result directory, and contact one mock package service. Prohibit reading a separate marker directory, changing host settings, and contacting an unrelated mock destination. All markers and endpoints should be harmless test resources under the evaluator’s control.
Evidence: Kubernetes: Pod Security Standards [1]
Probe alternate paths to the same resource
Try the permitted file path first, then a neighboring disallowed path and an equivalent path reached through a controlled symbolic link where the environment supports it. Test direct network access and access through a subprocess. Record the enforcement component and actual effect rather than relying only on the agent’s reported error.
Add a credential-shaped synthetic marker to an excluded environment surface and verify it is unavailable to the task. Do not use real secrets as test material. A fixture should establish whether the intended exposure boundary works without creating a new incident during evaluation.
Check resource exhaustion and cleanup
Run bounded CPU, memory, output-size, and process-count probes appropriate to the isolated test environment. Observe the sandbox’s termination, cleanup, and final artifact state. An agent stopped by a limit should not leave an untracked background process or a partially published result that appears complete.
Keep normal compilation or file-writing controls to ensure restrictions still permit the intended workload. Report unauthorized effects, denied attempts, false denials, and resource-limit behavior separately. Repeat after restarts and with the same deployment configuration used for the supported task; a development sandbox can have materially different mounts and privileges.
| Case | Evidence to retain | Acceptance condition |
|---|---|---|
| Allowed result write | Saved artifact | Supported task remains usable |
| Protected marker read | Access decision and marker inventory | Marker unavailable |
| Resource ceiling | Termination and cleanup record | No orphan work or false completion |
Publish only the scope actually exercised
Accept the coding fixture when permitted work completes and the tested forbidden operations cannot affect protected resources. If one operation cannot be tested safely, record that gap and narrow the supported task instead of claiming complete isolation. Preserve runtime version, policy, mount inventory, and probe results.
Re-run the matrix when adding a mount, tool, image, network exception, or credential. An authorization boundary in a tool adapter and a host isolation boundary solve different problems, so retain both where needed. The result is a bounded acceptance record for one deployed sandbox configuration, not a universal security guarantee.
Limits of the evidence
All probes described here are proposed for isolated, authorized test environments. No sandbox was attacked or certified. Passing a small operation matrix does not establish resistance to unknown runtime vulnerabilities or every host and network escape path.
Common questions
Is containerization enough?
No. Verify the configured mounts, privileges, network, credentials, and limits for the actual workload.
Should testing use real secrets?
Use unique synthetic markers and controlled resources instead.
Sources & further reading
Primary sources behind this briefing. A source’s findings apply to its own study conditions; publication on arXiv does not establish peer review.
- Kubernetes: Pod Security Standards Kubernetes · Living reference · Maintained documentationReviewed: named workload restriction profiles and controls; not proof of complete agent sandbox isolation. Accessed October 16, 2026.
Questions or corrections? Write to Rubrex. Read our editorial approach.