Agent sandbox assurance
Know what the execution environment can contain.
A code, browser or computer-use agent can reach more than the visible task suggests. Examine the boundaries around its filesystem, network, secrets and lifecycle in the configuration you intend to run.
Know what the execution environment can contain
- Workload process
- The code or browser session executing the delegated task.
- Filesystem mounts
- The paths and shared volumes the workload can access.
- Network routes
- The destinations reachable from inside the environment.
- Lifecycle cleanup
- The state that remains when execution ends.
Discipline model
Name the resources the workload must not reach
The relationships that define the discipline
- Workload process
- The process sits inside controls whose configuration defines its reach.
- Filesystem mounts
- Mounts connect workload storage to resources outside the process boundary.
- Network routes
- Routes can cross host, tenant and external-service trust boundaries.
- Lifecycle cleanup
- Teardown determines what state can cross from one execution to the next.
Sandbox assurance concerns the space in which an agent executes. Runtime packaging alone does not describe every allowed crossing: host mounts, network routes, injected secrets and shared caches can change the effective boundary. Start with the protected resources and identify each mechanism that separates them from the workload.
Illustrative situation
Reused environments need a cleanup boundary
A constructed situation to reason through
Illustrative scenario
- Session completes
An agent finishes processing a confidential draft.
- Workspace reused
A later workload receives the same persistent volume.
- Boundary question
Determine whether prior data remains accessible.
Use this situation to identify the evidence that would change the decision. The proposed examination must stay within the agreed scope, and any conclusion must describe the conditions actually inspected.
Working approach
Examine the runtime across its full lifecycle
Proposed investigation sequence
- Define workload process
State the decision and conditions the work must address.
- Map filesystem mounts
Connect the relevant actors, configuration and evidence.
- Examine network routes
Use agreed evidence and controlled cases where appropriate.
- Review lifecycle cleanup
Record limits, ownership and the condition for a next decision.
Map the runtime architecture and deployment configuration before selecting authorised probes. Examine filesystem and network access, secret handling, resource limits and tenant separation. Include startup, interruption, snapshot restoration and teardown: a boundary that holds during one process may depend on what happens when an environment is reused.
Working artefact
Record the crossing and the resulting state
Illustrative working record
Illustrative working format
- Workload process
- Define the subject and the requirement the record addresses.
- Evidence reference
- Link source, version and observed condition without copying sensitive material.
- Network routes
- Explain the finding or choice and its consequence.
- Lifecycle cleanup
- Assign the next action and state what remains unresolved.
An isolation finding should name the protected resource, attempted crossing, relevant configuration, observed response and final state. This lets the platform owner distinguish a denied request from a resource that remained reachable by another path. Findings should identify the tested runtime and configuration rather than generalize to every use of the product.
Scope and next decision
Agree authorised probes and platform responsibilities
Prepare a bounded next discussion
- Workload process
- Bring one concrete workflow question and its accountable owner.
- Filesystem mounts
- Identify the evidence and access that can be made available.
- Network routes
- Agree the specialist involvement and responsibilities required.
- Written scope
- Confirm activities, evidence, readiness and acceptance before commitment.
Active boundary testing requires written authorisation, agreed targets and stop conditions. A scoped assessment cannot certify a sandbox product or establish escape impossibility. Platform controls and customer configuration need separate evidence and clearly assigned owners.
Explore the discipline
Specialist areas within this capability
Choose a question to explore its methods, boundaries and indicative outputs.
- Sandbox architecture review
- Isolation-boundary testing
- Escape-resistance assessment
- Filesystem-access testing
- Network-egress control review
- Secret-exposure testing
- Resource-exhaustion testing
- Malicious-code execution testing
- Persistence and cleanup verification
- Tenant-isolation assessment
- Sandbox image supply-chain review
- Runtime-policy validation
- Snapshot and rollback testing
- Auditability assessment
- Comparative sandbox benchmarking
- Secure computer-use environment design
- Browser sandbox evaluation
- Code-execution sandbox certification readiness
Related services
AI Agent Runtime Security Review
Make every delegation explicit. Examine who the agent acts for, where it can execute and which tools it can reach when instructions alone are not enough.
AI Agent Red Team
Challenge the boundaries that matter to your workflow. Test agreed attack scenarios against agent instructions, tools and data access.
AI Agent Sandbox Assurance
Examine the boundary between agent execution and the systems around it, including files, networks, secrets and cleanup.
AI Secure Agent Architecture Review
Design authority and isolation into the system. Review trust boundaries, credentials, tools and recovery before deployment choices become difficult to change.
AI Secure Agent Deployment Review
Look beyond a successful demonstration. Examine the permissions, dependencies and operational controls that shape an agent’s behaviour in deployment.
Relevant insights
The permission boundary behind every agent action
An agent can only be evaluated in the context of what its tools allow. Examine identity, delegated authority and action boundaries before you put a workflow in motion.
Before your agent can act, define its authority
A working paper for the moment an AI system moves from advice to action. Map identity, permissions, approvals and recovery into an authority model your team can review and test.
Testing an agent’s network-egress boundary
“Internet access” is too broad a permission for an agent. Define destinations, protocols, data-release rules and failure behaviour, then test bypasses against the deployed network path.