An agent runs inside an isolated environment. It can also fetch a web page, call a business API and open an authenticated browser. Which of those actions is actually constrained by the isolation?
That is the useful question behind AI agent sandboxing. The word describes an execution boundary, but buyers can mistake it for a guarantee about the whole workflow. A well-contained process can still use an overpowered tool to make an unwanted change.
In brief: Define what must be prevented, identify where each restriction is enforced and test both permitted and denied behaviour. Process isolation, network policy, tool authority and data handling are different controls. A sandbox label is not evidence that all four work together.
This is a narrow implementation question within the Agentic AI reading path, not a recommendation to build another agent platform.
Managed execution makes the boundary question more important
On 28 October 2026, Microsoft introduced the Copilot harness in Foundry Agent Service in public preview. The service runs the agent loop and sandbox, with skills, connected tools, file and code operations, and delegation to subagents.
That can remove useful engineering work from an application team. It does not remove the need to understand which controls belong to the service and which remain with the application.
Microsoft's current documentation makes an important distinction: during this preview, the service manages approval policy for built-in harness tools, while the customer-configured MCP approval setting does not apply to those harness tools. The documentation also says the preview has no service-level agreement and is not recommended for production workloads. These limits matter more to an acceptance decision than the presence of a sandbox alone.
On 29 October, Island announced an enterprise browser for agents. Its stated controls include read-only access, credential isolation and restrictions on browser operations. Those are supplier claims, not independently verified protection. They illustrate another boundary: browser-mediated activity has controls and failure paths separate from the process running the agent.
Meanwhile, The New Stack's 27 October sandboxing analysis examines workload, host and network separation. CNCF sponsored that article. Its architectural argument is useful, but sponsorship and supplier descriptions should not be confused with a penetration test of your deployment.
The direction is clear enough to act on without predicting a market winner. More execution machinery is being packaged for teams. The acceptance criteria still need to describe the business risk.
Start with the prohibited outcome
“The agent must be secure” is not testable. “The agent must not retrieve another customer's case or send case data to an unapproved destination” is.
Choose one bounded workflow. Write its legitimate inputs, outputs and actions, then the outcomes it must not produce. Include confidential data exposure, unauthorised modification, cross-tenant access, uncontrolled resource use and persistent changes outside its workspace where relevant.
For an illustrative support assistant, legitimate work might be reading one authenticated customer's order and drafting a response. Prohibited outcomes could include exporting the customer list, changing a refund policy, sending an external message or accessing another tenant's attachments.
This example is a design exercise, not a description of an incident or an implemented product.
Assign each prohibition an enforcement point. Tenant isolation belongs in the data and application access path. A blocked network destination belongs in an enforceable egress policy. A prohibited refund needs a tool or receiving-system restriction, not only an instruction telling the model to avoid refunds.
The Agentic AI control-plane article explains the broader management architecture. A sandbox acceptance test should be more specific: this identity, using this path, cannot perform this action.
Separate execution isolation from business authority
A runtime boundary limits what code can do to its surrounding environment. It does not automatically limit what a permitted remote API will do on its behalf.
For local execution, review the isolation mechanism, privilege level, exposed files, available commands and resource limits. A container, a microVM and a managed code interpreter do not have interchangeable properties. Nor does using a stronger isolation mechanism compensate for unnecessarily broad application credentials.
Docker's bind-mount documentation explains that bind mounts can expose host files and are writable by default unless configured otherwise. That is an explicit path through the boundary, not a mysterious failure of isolation.
Inspect what is mounted, why it is needed and whether read-only access is sufficient. Avoid exposing a developer's complete working environment to a task that needs one sanitised input directory.
For remote business actions, inspect the actual tool. A tool called “prepare credit” might merely create a draft, or it might post a credit to the account. Its name is not an authority contract.
Test the receiving system's permissions with the agent's real identity path in a controlled environment. Do not assume that removing a button, hiding a tool description or adding a warning to the prompt removes the underlying ability.
Trace every route out
An egress restriction is useful only if it covers the routes the workload can actually use.
List direct HTTP access, browser navigation, search services, MCP servers, package downloads and any internal proxy that can retrieve external content. Some tools execute outside the sandbox. Their permissions and destinations must be reviewed separately.
Docker's bridge-network documentation notes that containers on the default bridge can communicate. Network attachment and published ports require deliberate configuration; a container is not a complete network policy.
For an agent workflow, check both destination and purpose. Allowing a business API hostname does not mean every endpoint should be available. A permitted service might also support uploads, outbound webhooks or broad exports.
Test redirection and secondary requests in your own safe fixtures. A request that begins at an approved destination should not silently gain access to any destination named in its response.
Where the platform does not expose enough network control for the intended data, narrow the task or choose a different execution route. Do not present an architectural requirement as satisfied because a model declined a test request once.
Keep credentials and data on their intended side
Credentials should be available to the component that needs to authenticate, not automatically to the model or every child process.
Inspect whether tools inject authentication outside model-visible context, which identity they use and how scope is enforced. A credential vault can help, but a vault does not make a broad grant narrow.
Use synthetic data and non-production identities to test whether files, process output, tool errors or diagnostic traces expose information that should remain hidden. Record pass or fail and the affected component. Do not copy real credentials into the test report.
Check data separation between conversations, jobs and tenants. Start a new workspace and attempt an authorised test read of a harmless marker from the previous one. The expected result depends on the documented retention and sharing contract, but it should not be accidental.
Also inspect generated artefacts. A report may correctly omit sensitive fields while an attached working file retains them. Outputs, logs and caches need explicit handling and retention rules.
The Omningage case study provides context for joined-up service work. It is not evidence that the specific sandbox tests proposed here have been implemented there.
Make the acceptance matrix small and repeatable
Begin with a compact set of high-consequence tests rather than a long list of generic assurances.
| Boundary | Permitted test | Denied test |
|---|---|---|
| Workspace | Read the assigned synthetic case | Read a separate tenant's marker file |
| Network | Reach the approved test endpoint | Reach an unapproved test destination |
| Tool authority | Create a draft change | Commit the change without approval |
| Data movement | Produce a redacted result | Export a restricted synthetic field |
| Resource use | Complete within the agreed budget | Continue beyond the enforced limit |
These are examples, not a universal certification scheme. Add tests that reflect your actual architecture and consequence.
Use deterministic requests through the relevant execution paths as well as realistic agent prompts. The first checks enforcement directly. The second checks whether orchestration, alternative tools or delegated work introduce a route the direct test missed.
A model refusing a prompt is useful behaviour, but it is not equivalent to an enforced denial. Conversely, an enforced block should return a usable error so the legitimate workflow can stop or request help.
Retain the runtime version, tool configuration, identity scope, policy version and test result. Repeat the relevant tests when those inputs change. The wider production AI evaluation guide covers outcome testing; this matrix establishes a narrower boundary claim.
Exercise intervention and delegated work
Test what happens when the main agent delegates to a subagent or uses a browser operated by another service. Confirm the downstream component does not inherit wider authority merely because it has a different execution environment.
Then rehearse intervention. Can the operator stop new work, block the next consequential call and identify actions already accepted downstream?
Stopping a process does not undo a completed action. Nor does terminating one runtime necessarily revoke an issued token or cancel a queued request. The access-review guide covers revocation in more depth. The sandbox acceptance test should prove the specific stop path on which the operation intends to rely.
Use harmless test resources. Do not probe another tenant, production system or external destination without authorisation.
Buy a demonstrated boundary
Ask a supplier to demonstrate your prohibited outcomes using the proposed configuration, not a generic security slide. Establish which controls are available now, which are managed by the service and which require your own gateway or application code.
Keep unresolved limitations in the delivery decision. A constrained research pilot using public information can be appropriate even when the same environment is unsuitable for production customer data.
Before expanding access, require an accountable owner to accept the evidence and the residual risk. That is part of technology delivery, not an optional task after the agent works.
If the boundary cannot be demonstrated, reduce the authority or change the design. Discuss a bounded Agentic AI implementation around one workflow and a small, repeatable set of acceptance tests.
The useful result is not a claim that the agent is inside a sandbox. It is evidence that the actions and data paths that matter remain constrained.
Sources and evidence notes
- Microsoft's Copilot harness announcement, 28 October 2026. Primary supplier announcement; the managed harness is a public preview.
- Microsoft harness configuration guidance, checked 2 November 2026. Current provider documentation, including preview restrictions and the distinction between MCP approvals and built-in harness-tool policy.
- Island's agent-browser announcement, 29 October 2026. Vendor claims, not independent validation.
- The New Stack, sandboxing across multiple boundaries, Michael Levan, 27 October 2026. CNCF-sponsored contributed analysis; not a deployment-specific security assessment.
- Docker bridge networking and bind mounts, checked 2 November 2026. Established implementation references, not new agent-specific standards.
The acceptance method and examples are original recommendations. They are not claims of measured protection or deployments in Ahmad Nizami's businesses. No sandbox can be declared universally secure from this checklist alone.