AI Agent Sandboxes: Verify the Filesystem Boundary

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

A container or sandbox label does not tell a buyer which host files an agent can reach. A development assistant may need a project directory while a build tool also mounts a package cache, credentials directory, or container socket. A filesystem review measures those concrete boundaries using marked test files. It should explain what the agent process can read, modify, persist, or hand to another tool, rather than treating successful isolation of one directory as a complete containment result.

Define the boundary before testing

Inventory the runtime identity, mounted volumes, working directory, writable paths, inherited environment, subprocess model, and persistent caches. Define the files required for the authorized task and the resources explicitly outside scope. Use a disposable environment with synthetic markers placed by the operator in allowed and denied locations. Record the expected persistence after a job ends and after a worker restarts. If a managed platform controls the sandbox, obtain its documented boundary and identify the parts the assessment can actually observe.

Run a bounded assessment

Execute an ordinary task that reads and changes an allowed fixture. Then use the approved harness to request harmless reads and writes at denied test locations. Check shared caches and artifacts between two isolated test jobs. Observe whether a subprocess or file preview tool has the same restrictions as the primary agent runtime. Test cleanup through the supported job lifecycle rather than trying an escape technique. This review can establish access-policy gaps without publishing exploit instructions, probing the host, or manipulating production credentials.

Keep evidence an engineer can use

Record the runtime and image version, mount policy, process identity, requested operation, expected decision, and observed file state. Include the operator’s marker manifest in restricted evidence so a reviewer can distinguish a denied read from a missing file. If a control exists only in the client interface, inspect whether the worker can still reach the resource through its normal tool. Separate filesystem findings from network, compute, and kernel-isolation questions. A file-boundary assessment should not be marketed as a full proof of sandbox security.

Interpret the result and retest

Retest ordinary work and denied paths after narrowing the runtime privileges. Check that cleanup removes job-specific artifacts while preserving only explicitly permitted caches. New mounts and build features should trigger review because they can expand access without changing the model. OWASP’s container security guidance offers background for runtime hardening. Use the actual platform configuration as the acceptance basis, and keep lower-level sandbox escape research out of scope unless a separate authorized engagement is designed for that purpose.

Assessment scope and next steps

This is a proposed defensive assessment workflow, not a finding about a particular product. Use a staging environment, synthetic records, approved test identities, and an agreed stop condition. Record the model, connector, policy, and application versions so a later result can be compared with the same configuration. Unavailable evidence should remain an explicit coverage gap.

Primary reference: OWASP security guidance. The scenarios and acceptance criteria here are editorial recommendations for adapting that background to an authorized assessment.

For a scoped review of these boundaries, explore FailSafe AI security testing and agentic penetration testing. Agree the specific tools, identities, evidence, and exclusions before purchasing an assessment.