Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does Sandboxing an Enterprise AI Agent Protect Your Data?

It protects the machine, not the data: a sandbox limits what the agent can touch on the host and the network, but the moment the agent signs into a real application the sensitive records are inside the sandbox with it. Check what the model reads once logged in, and what control acts on that, because the sandbox does not.

Documents move into and out of a transparent sandbox containing a bounded geometric processing block.

It protects the machine, not the data: a sandbox limits what the agent can touch on the host and the network, but the moment the agent signs into a real application the sensitive records are inside the sandbox with it. Check what the model reads once logged in, and what control acts on that, because the sandbox does not. Sandboxing has become the default answer to agent risk, for good reason. Vendors of coding and computer-using agents run them in isolated environments, and an agent that cannot write outside a directory or call an arbitrary host has a bounded blast radius on the machine. The question in the title asks something narrower. An enterprise agent does its work inside applications, and once it authenticates to a patient scheduling system or a payroll console, every record those applications render is present in the sandbox, readable by the model, and subject to whatever the model decides or is steered to do with it. This page examines what a sandbox contains, what changes when the agent signs into a real application, what vendors document about their isolation, what a patient record shows about the boundary, how to measure what a sandbox protects, and which claims a buyer should refuse. It follows the earlier analysis of protecting sensitive data from agents that navigate screens, treating isolation as necessary and insufficient.

Key findings

  • Vendor engineering on agent sandboxing states that effective sandboxing requires both filesystem and network isolation, and reports that sandboxing safely reduced permission prompts by 84 percent, a measure of containment on the host rather than of data protection inside applications (Anthropic, 2025).
  • Even the safest language model agent in a controlled emulation exhibited risky failures, such as irreversible actions, 23.9 percent of the time, and a sandbox does not change what the agent decides, only where the consequences land (Ruan et al., 2024).
  • Container security guidance treats isolation as protecting the host and other workloads from the container, which is a different property from protecting the data a process inside the container is authorized to read (NIST, 2017).
  • Browser-using agents from major vendors are documented as running in isolated or managed browser environments, and those environments sign into real web applications on the user's behalf, which brings live records inside the boundary (AWS, 2025).
  • The data exposure inside a sandbox is set by the application's rendered screen, not by the sandbox, so a control on what the model sees has to act at the render layer (Can a Credential Vault Protect What an AI Agent Reads?).

What does a sandbox actually contain?

A sandbox is a boundary around a process. Inside it, the agent may read and write a defined set of files, reach a defined set of network destinations, and use a defined set of system capabilities. Outside it, nothing. Vendor engineering is specific about what the boundary must include: effective sandboxing requires both filesystem and network isolation, because a process that can write anywhere or call any host escapes the intent of either control alone (Anthropic, 2025). The same work reports that sandboxing safely reduced permission prompts by 84 percent, which shows the practical purpose: once the environment is bounded, many actions no longer need a human to approve them, because their worst case is contained.

Federal guidance on application containers describes the same property from the infrastructure side: isolation protects the host and other containers from a compromised or misbehaving workload, through kernel controls, image hygiene and runtime restrictions (NIST, 2017). The threat model is a process that should not be trusted with the machine. That is the correct threat model for an agent, and sandboxing addresses it well.

What the boundary does not define is the content that flows through it legitimately. A sandbox with network isolation still permits the destinations the task needs, and for an enterprise agent those destinations are the applications it works in. The data those applications return enters the sandbox as the ordinary output of an allowed request. The container guidance protects the host from the workload; it has no view of which fields a web application rendered to the process inside. The same point applies to a credential vault: it protects the secret used to sign in, not what the signed-in session then displays.

What happens when the sandboxed agent signs into a real application?

Everything the sandbox was built to exclude now arrives through the front door. The agent authenticates, the application renders the record the task requires, and the full screen, with every field the user's role permits, is inside the boundary. The model reads it. From this moment the sandbox is protecting the organization's machine from an agent holding the organization's most sensitive data.

Two things follow. First, the agent can act on that data within the destinations the sandbox allows, which include the application itself and usually whatever the task's output goes to: an email system, a ticket, a document. An agent steered by planted text to move a value between two allowed destinations is operating within the sandbox's rules. Second, the agent's decisions remain its own. In an emulation built to surface these failures, even the safest language model agent tested exhibited risky behavior, including irreversible actions, 23.9 percent of the time (Ruan et al., 2024). The emulation was itself a sandbox; it contained the consequences and measured the decisions, and the decisions were the problem.

This is why careful deployments pair isolation with a different control inside the boundary. Vendor documentation for a browser-using agent describes safety measures that operate on the agent's behavior during a session, confirmations before consequential steps among them, rather than relying on the remote environment alone (OpenAI, 2025). The remote browser contains the agent; the confirmations govern what it does with what it sees. Neither governs, in the pages reviewed, what the model is shown in the first place. Rendering in a cloud browser does not change the content; the analysis of protecting data without cloud browser rendering covers why the location of the render is separate from its content.

What do agent vendors document about their own isolation?

Three vendors in the sources reviewed document how their agents are isolated, and together they show what sandboxing is designed to achieve.

Dimension Vendor, per its documentation What a buyer should verify
Filesystem and network boundary Anthropic describes filesystem and network isolation for its coding agent, and documents security and isolation for its cloud-hosted sessions Which destinations the sandbox allows, since each delivers live data inside the boundary
Isolated execution for computer use Anthropic's computer use documentation carries safety guidance on running the tool in an isolated environment What limits what the model reads on screens rendered inside it
Managed browser for agents AWS documents a managed browser through which agents interact with web applications Whether anything changes rendered content before the model reads it
Per-field control on rendered screens Not described in the pages reviewed for any of the three Whether identifiers reach the model in the clear once signed in

The documentation is consistent in purpose. Anthropic's cloud sessions carry a section on security and isolation (Anthropic, 2025), and its computer use tool documentation includes safety guidance on running the tool in an isolated environment (Anthropic, 2024). AWS documents a browser tool through which agents interact with web applications (AWS, 2025). In each case the environment bounds the agent; none of the pages reviewed describes a control that changes what the model sees on a screen rendered inside it. Academic work on infrastructure for trustworthy agent automation treats this layering, environment plus controls on behavior and data, as an open design area (Columbia University DAPLab).

What does a single patient record show about the sandbox boundary?

Take one record type, a patient appointment record in a scheduling system, and one task: an agent confirms tomorrow's appointments by checking each record's status and sending a reminder to the patient's preferred contact. The record renders the patient's name, date of birth, medical record number, phone and email, insurance identifier, the appointment time and type, and a free-text reason for visit.

Inside a well-built sandbox, the agent cannot touch the host filesystem, cannot reach any destination except the scheduling system and the messaging gateway, and cannot install anything. Then it signs in. The full appointment record is rendered inside the boundary. The model reads the name, the medical record number, the insurance identifier and the reason for visit, none of which the reminder needs. If the reason-for-visit field for one patient contains text planted to redirect the agent, the agent has the patient's contact details and identifiers in front of it and two allowed destinations to use. The sandbox has done its job completely, and the data is exposed completely, because the exposure was never on its side of the boundary.

Under a data-level control inside the same sandbox, the screen is changed before the model reads it. The model sees PATIENT_001, a token in place of the medical record number and insurance identifier, the appointment time and type in the clear, and a contact token that resolves to the real phone number only at the messaging gateway at the moment the approved reminder is sent. The planted text, if present, has nothing to redirect. The reminder content is confirmed by the scheduling lead before the batch sends. The sandbox still bounds the machine; the render-layer control bounds the data; and the record of the run shows the screen as tokens. The two controls answer different questions, and the title asks the second.

How should an organization measure what a sandbox protects?

Measure the boundary and the content separately. For the boundary, enumerate the paths the agent can write, the destinations it can reach and the capabilities it holds, and test each with an attempt to exceed it. This is the measurement vendor engineering reports when it describes the share of actions that no longer need a permission prompt (Anthropic, 2025), and it is worth doing.

For the content, take a sample of the screens rendered inside the sandbox during a real task and list the fields on each that the model read in the clear. Compare that list with the fields the task required. The difference is the exposure the sandbox did not address. If the list includes identifiers, regulated values or credentials that the task did not need, the organization has measured a gap that no tightening of the sandbox will close, because every one of those values arrived through an allowed destination.

Third, measure behavior under adversarial content. Place benign test strings in records the agent will read and observe whether the agent's actions change. The emulation research found risky behavior in a measurable fraction of runs even for the most careful agent tested (Ruan et al., 2024), and an organization's own figure for its own workflows is the number that matters. The same question arises for an AI gateway placed between the agent and the model: a control that bounds the path does not by itself change the content on it, and the measurement is what the model saw.

What does a governed environment change?

A governed environment protects the data a sandbox leaves exposed: once the agent signs into a real application, the records inside the boundary reach the model as consistent tokens rather than real values, so isolation of the host is joined by control of what the model reads. Container security guidance treats isolation as protecting the host and neighboring workloads from the process inside (NIST, 2017). That property is unchanged; what changes is the content of the screens.

This class of control acts at the render layer. Sensitive values on the rendered page, a patient identifier or a card number, are replaced with consistent tokens before any model reads them, and the task runs on tokens inside the sandbox. Real values resolve only at an approved destination at the moment of an approved action, such as a record saved to the application or a payment submitted. A named person confirms what is tokenized and approves consequential actions, including irreversible ones. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

The page's evidence shows why the second control is separate from the first. In controlled emulation even the safest agent took risky actions, including irreversible ones, 23.9 percent of the time (Ruan et al., 2024); a sandbox changes where the consequences land, and an approval gate changes whether they land at all. The exported record also supplies what a sandbox cannot: the screen of a real record as the model saw it, with sensitive values absent, and the approval log for a sample run.

The environment does not alter the sandbox, its allow list, the application or the model, and it does not replace filesystem and network isolation; it covers the rendered page, not the terminal, IDE or filesystem.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Its design places a data-level control inside the isolation boundary, where this page argues the gap lies. The agent works in a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so the identifiers and regulated values an application renders inside the boundary reach the model as consistent tokens, such as ACCT_001 or PATIENT_001, for the whole run. Real values resolve only at approved destinations at the moment of an approved action, which is how a reminder reaches a real phone number without the model ever holding it. A named person confirms the tokenization policy and approves every payment, submission and record change, which RedactSure calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own workflow would produce the measurement this page describes: the screens rendered inside the environment as the model saw them, with the fields in the clear and the fields tokenized listed for each. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on vendor documentation and engineering writing, official guidance and preprint research. Vendor material comprises Anthropic's engineering post on sandboxing its coding agent (October 2025), its documentation on cloud-hosted sessions with a section on security and isolation (2025) and its computer use tool documentation with safety guidance (2024); OpenAI's Operator system card (January 2025); and AWS documentation on the Amazon Bedrock AgentCore browser tool (2025). Official guidance is NIST Special Publication 800-190 on application container security (2017). Research comprises the ToolEmu preprint on identifying risks of language model agents in an emulated sandbox (2024) and the Columbia University DAPLab program on infrastructure for trustworthy agent automation. All sources were read as of October 16, 2026.

No hands-on testing of any product or agent platform was performed for this page. Where a vendor's documentation does not describe a capability, that capability is described as not described in the pages reviewed, not as absent; the statement that no per-field control on rendered screens is described applies to the pages read, and vendors may document more elsewhere or later. Vendor features change, and the page carries its date. The 23.9 percent figure is reported as the preprint reports it for an emulated setting and is not a field measurement. Statements about RedactSure describe its current design, with deployments in pilot. The patient appointment example describes a record type, not any organization; no customer or prospect is described.

Whether a given isolation design, paired with whatever data controls an organization adopts, satisfies the security and privacy obligations that apply to its records is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Sandboxing protects the machine and the network from the agent, and the published engineering shows it does so well enough to remove most permission prompts. It does not protect the data, because an enterprise agent's data arrives through the destinations the sandbox allows: the applications it signs into. Once signed in, the full rendered record is inside the boundary and the model reads all of it, and the agent's decisions about that content remain as fallible inside the sandbox as outside it. The controls that address data exposure act on the content, by changing what the model is shown before it reads the screen and by placing a person before consequential actions, and they belong inside the isolation boundary, not in place of it. The test is to name one agent and one task and ask for a capture of one application record as the model saw it inside the sandbox; if the identifiers are in the clear, the sandbox has answered a different question.

Frequently asked questions

Is sandboxing still worth doing if it does not protect the data?

Yes. A sandbox bounds the agent's reach on the host and the network, which is a real reduction in blast radius and the reason vendors report fewer permission prompts once it is in place. The point of this page is scope, not value. Sandboxing answers the question of what the agent can touch on the machine. A second control is needed for what the model reads inside the applications the sandbox allows, and the two should be deployed together.

Does running the agent in a cloud browser change what the model sees?

Not by itself. A cloud or managed browser moves the rendering to a remote environment, which isolates the user's device and network from the agent. The page the application renders is the same page, with the same fields, and the model reads it in the remote environment exactly as it would locally. Changing what the model sees requires a control that acts on the rendered content, wherever the rendering happens.

Can network allow lists stop data from leaving the sandbox?

They limit the destinations, and the destinations the task needs remain open. An agent confirming appointments must reach the scheduling system and the messaging gateway, and both are channels through which data can move. An allow list prevents exfiltration to arbitrary hosts, which matters, but data moved from one allowed destination to another, under the agent's own steering or an attacker's, stays inside the rules the allow list enforces.

If the agent is steered by planted text, does the sandbox help?

It limits where the consequences can land, which is useful. It does not change whether the agent is steered, because the planted text arrives as ordinary content from an allowed application and the model reads it the same way. The emulation research measured risky decisions inside a contained environment. Reducing what the model can be steered to do with sensitive values means reducing the sensitive values it holds, which is a render-layer control.

What should an isolation review ask vendors to show?

Three artifacts: the sandbox's allow list of filesystem paths and network destinations; a capture of a real application screen as the model saw it inside the sandbox; and the approval log for consequential actions in a sample run. The first proves containment, the second shows data exposure, and the third shows whether a person stood before the actions that matter. Most vendors can produce the first; the second is the one that decides the title question.

How does a render-layer control fit inside a sandbox?

It operates on the rendered screen before the model reads it, within the same environment the sandbox bounds. Identifiers and regulated values are replaced with consistent tokens, the task's needed fields stay readable, and real values resolve only at an approved destination when an approved action needs them. The sandbox continues to bound the machine. In RedactSure's design this is the environment where the agent works, with every screen recorded as tokens.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.