A sandbox needs a stated purpose
Sandbox can describe a range of execution environments with different isolation properties. Identify whether the intended boundary concerns process execution, files, memory, network access, credentials or application data. A product name does not establish all of these protections. AWS documents dedicated microVM environments for AgentCore Runtime sessions; that is a specific implementation, not a property of every agent platform. Procurement and design should state the mechanism and supported configuration rather than treating sandbox as a universal assurance label or proof of complete separation.
Inventory what remains shared
Sessions may still use shared gateways, model providers, retrieval systems, identity services or management infrastructure. Those dependencies need their own permissions and capacity controls. A separated filesystem does not prevent an overprivileged tool from retrieving another customer’s records. Likewise, a protected process does not establish that prompts are retained appropriately by every external service. Draw the complete path and distinguish execution isolation from application authorization. The most consequential gap can sit outside the environment the supplier demonstrates when showing that one process cannot read another process’s local files.
Understand session and storage lifetimes
AWS explains that a runtime session can continue logically after its compute stops, with a later invocation provisioning new compute. Optional session storage can persist files at a configured mount path. This makes lifecycle semantics central to isolation review. Determine what is ephemeral, what persists and which identity can retrieve it after resumption. Avoid asserting that stopping a sandbox deletes every relevant record. Other platforms require their own documentation and tests; do not transfer one vendor’s microVM behavior or storage rules to an unrelated runtime.
Constrain tools and network reach
OWASP recommends minimum tool access, separate tool sets where appropriate and explicit authorization for sensitive operations. Apply these controls even when the execution environment is isolated. Restrict capabilities to the actual task and verify the receiver’s authority checks. External content should not expand those privileges. An agent that cannot read a host file may still be able to disclose confidential information through an allowed outbound call. A sound design therefore reviews what the session can cause other systems to do, not only what it can inspect locally.
Test boundaries through authorized scenarios
Use test identities and non-sensitive fixtures to examine cross-session access, incorrect ownership, stale context, denied tools and supported shutdown. Include management and support paths, which may have broader visibility than ordinary requests. Record the actual runtime, policy, image and configuration assessed. Security evaluation should not rely entirely on a happy-path demonstration. Tests also need a clear expected result and an owner for discrepancies. A denied request is useful evidence of one boundary working, not certification that every untested path or future version is secure.
Connect isolation with recovery and accountability
Decide how a session is paused or stopped, which evidence remains available and how legitimate users recover their work. IBM’s October announcement describes containment capabilities in technology preview, illustrating active commercial development without establishing universal availability. Verify the product’s current status before purchase. A useful sandbox balances clear limits, operational support and appropriate evidence. Its purpose is to contain selected risks in a defined service, not to justify unrestricted autonomy or remove the need for authorization, privacy controls and repeated evaluation as the surrounding integrations change.
Worked scenario: local isolation with a broad connector
Imagine two customers receive separate execution environments but share a document-search service. The runtime cannot access the other environment’s local files, yet its connector accepts any customer identifier supplied in the request. The proper evaluation must inspect the receiving service’s authorization, not stop after the local isolation test. Use approved fixtures to confirm both permitted retrieval and denial across the intended tenant boundary. This example is hypothetical, but it shows why execution isolation and data access are different claims that require different evidence and responsible owners.
