Data Report · By Chris Sowa · Published
Last updated
How Do You Isolate AI Agents From Sensitive Company Systems?
By architectural separation rather than instruction: the agent should never hold sensitive data, untrusted input and the ability to act outward in the same session, and the cleanest way to break that combination is to keep real values out of the model entirely. Check which of the three the agent holds in each workflow, and which your design removes.

By architectural separation rather than instruction: the agent should never hold sensitive data, untrusted input and the ability to act outward in the same session, and the cleanest way to break that combination is to keep real values out of the model entirely. Check which of the three the agent holds in each workflow, and which your design removes. Isolation is an old discipline in security, from network segmentation to the scoping rules of the payment card standard, and it transfers to agents with a twist. The thing to isolate is not only the agent from the system but the agent from a dangerous combination of capabilities within itself. Researchers at several vendors and universities have converged on the same shape of answer: an agent that reads untrusted content, holds sensitive data and can communicate or change state is unsafe until prompt injection is reliably stopped, so a session should hold at most two of those three. This page sets out what isolation means for an agent, how segmentation and zero trust translate to it, which separation patterns researchers and vendors describe, what a single employee payroll record shows, how to measure isolation, and which claims a buyer should refuse. It builds on the earlier analysis of which systems an agent should be allowed to use and extends it to what the agent holds while using them.
Key findings
- Meta's security guidance states that, until prompt injection is reliably stopped, agents must satisfy no more than two of three properties within a session: processing untrusted input, accessing sensitive systems or data, and changing state or communicating externally (Meta AI, 2025).
- The CaMeL design from Google, Google DeepMind and ETH Zurich sets the goal that untrusted data retrieved by the model can never impact program flow, separating the control path from the data the model reads (Debenedetti et al., 2025).
- A companion body of work proposes principled design patterns for building agents with provable resistance to prompt injection, each pattern constraining what the agent can do after reading untrusted content (Beurer-Kellner et al., 2025).
- Payment card scoping guidance shows that isolation is defined by what a system can reach and be reached by, so a component that connects to the sensitive environment is in scope regardless of intent (PCI Security Standards Council, 2016).
- Sandboxing isolates the agent from the host, and effective sandboxing requires both filesystem and network isolation, but neither addresses the sensitive data an agent reads inside an allowed application (Anthropic, 2025).
- Removing the sensitive data leg, by substituting tokens for real values before the model reads a screen, breaks the three-way combination while leaving the agent able to read content and act (What Is Sensitive Data Masking for AI Agents?).
What does isolation mean for an agent, and what must be kept apart?
Classical isolation puts a boundary between a system and everything it should not touch. For an agent, the more useful unit is the session: one agent, one task, one run. Within a session, three properties determine the danger. The agent may process untrusted input, such as a web page, an inbound email or a free-text field a customer filled in. It may access sensitive systems or data, such as a payroll record or a payment console. And it may change state or communicate externally, by submitting a form, sending a message or updating a record.
Meta's security guidance states the rule that follows: until prompt injection is reliably stopped, agents must satisfy no more than two of those three properties within a session (Meta AI, 2025). The reasoning is that an injection in untrusted input can steer the agent, and if the steered agent both holds sensitive data and can act outward, the attacker has a complete path from planted text to exfiltration or damage. Remove any one leg and the path is broken.
Isolation for agents, then, means designing each workflow so the session never holds all three. That can be done by separating the agent from the untrusted content, from the sensitive data, or from the outbound capability. Each choice has a cost. An agent that cannot read external content cannot do research or triage inbound mail. An agent that cannot act cannot finish a task. An agent that cannot see sensitive data can still read the screen and act, if the values it would have seen are replaced with tokens it can work with. That asymmetry is the central point of this page, and the analysis of giving a third-party assistant access to company systems shows what happens when none of the three is removed.
How do segmentation and zero trust translate to agent isolation?
Network segmentation and the payment card standard's scoping rules supply the older vocabulary. Under that guidance, a system is in scope if it stores, processes or transmits cardholder data, or if it is connected to or can affect the security of systems that do; segmentation reduces scope by removing connectivity, and a connected component is in scope whatever its intended function (PCI Security Standards Council, 2016). Applied to agents, an agent that connects to a sensitive system is part of that system's boundary, and isolating it means removing the connection or removing the sensitive data from what flows across it.
Zero trust supplies the enforcement mechanism. Instead of trusting a session once authenticated, every request is evaluated by a policy decision point and enforced at a policy enforcement point between subject and resource (NIST, 2020). For an agent, the enforcement point can sit where the agent reads and acts, which for a browser agent is the rendered session, and the policy can be expressed per workflow: which screens, which values, which actions, and which actions require a person.
Browser isolation adds a third tool. Cloudflare documents remote browser isolation, in which web content is rendered away from the user's device to protect the device from the content (Cloudflare, 2025). For a person, that isolates the endpoint from a hostile page. For an agent, the same pattern isolates the organization's infrastructure from the agent's browsing, but the model still reads the page, hostile text included. Remote rendering separates the device from the content, not the model from the content, which is the separation the Rule of Two concerns.
Which separation patterns do researchers and vendors describe?
| Pattern | What it separates, per the source | What a buyer should verify |
|---|---|---|
| Rule of Two | The session from holding all of untrusted input, sensitive data and outbound capability | Which leg each workflow removes, and how |
| CaMeL | Control flow from untrusted data, so retrieved data cannot alter the program | Whether the plan is fixed before untrusted content is read |
| Design patterns for secure agents | Actions available after untrusted content is read | Which pattern a workflow follows and what it gives up |
| Sandboxing | The agent process from the host filesystem and network | What the model reads inside allowed applications |
| Remote browser isolation | The device from rendered web content | What the model reads from the page |
The research patterns address the model itself. CaMeL's goal is that untrusted data retrieved by the model can never impact program flow (Debenedetti et al., 2025). The design patterns work generalizes this into a family, each pattern constraining the agent's capabilities after exposure to untrusted content, aiming at provable resistance to prompt injection (Beurer-Kellner et al., 2025).
The vendor patterns address the environment. Sandboxing bounds what the agent process can touch, and its engineering reports an 84 percent reduction in permission prompts once the bound is in place (Anthropic, 2025). Computer use documentation adds safety guidance on running in an isolated environment (Anthropic, 2024). None of the vendor pages reviewed describes a control on which values the model reads inside that environment. The gap between the two families is the sensitive data the model holds, where an AI gateway's limits also lie.
What does a single employee payroll record show?
Take one record type, an employee record in a payroll system, and one task: an agent reconciles each employee's bank details against a change request submitted through an HR portal form, and flags mismatches. The payroll screen renders the employee's name, national identifier, home address, salary, bank account and routing numbers, and tax withholding elections. The change request is free text typed by whoever submitted the form.
Count the three properties. Untrusted input: the form text, which anyone with portal access could have written. Sensitive data: everything on the payroll screen. Outbound capability: the agent can update the bank details or send a confirmation. All three are present. If the form text says, in effect, to update the account to a new number and confirm to an external address, the agent has the current details to compare, the authority to change them and a channel to confirm. Instructions to the agent to ignore such text are exactly what the planted text is written to override. Isolation by instruction has failed before the session begins.
Now remove the sensitive data leg. Before the model reads the payroll screen, the national identifier, address, salary and account numbers become consistent tokens; the model sees EMP_001 and ACCT_001. The form's account number is tokenized the same way as it is read, so the model compares two tokens and reports a match or mismatch without holding either real number. The update, if the agent may propose it, waits for the payroll lead, and the real value resolves only at the payroll system when that approved update is committed. The agent still reads the untrusted form and still proposes an action; the session now holds two properties, not three, and the agent lost nothing it needed. The same move applied to screen-navigating agents generally is the practical form of the Rule of Two for browser work.
How should an organization measure whether an agent is isolated?
For each workflow, write down the three properties and mark which the session holds. Untrusted input is present if the agent reads anything a person outside the trusted team could have written, including fields inside internal systems that customers or vendors populate. Sensitive data is present if any value the organization would be obliged to report as breached is rendered to the model in the clear. Outbound capability is present if the agent can submit, send or update without a person confirming. A workflow with all three marked is not isolated, whatever the environment around it.
Then check the enforcement of each removal. If the design removes untrusted input, confirm the agent cannot reach external content or free-text fields, not that it is told to ignore them. If it removes outbound capability, confirm that every state change waits for a named person, with a record of each approval, consistent with evaluating each action at an enforcement point rather than authorizing the session once (NIST, 2020). If it removes sensitive data, sample the screens as the model saw them and confirm that identifiers and regulated values appear as tokens, consistently across the run.
Finally, test with planted content. Put a benign instruction in a free-text field the agent will read and observe whether the agent's actions change. A session that holds two properties should show no path from the planted text to harm, because the leg the text needs is missing. The payment card scoping guidance offers the right attitude: scope is determined by what can connect and what can flow, not by what is intended (PCI Security Standards Council, 2016). An agent's isolation is determined the same way.
What does a governed environment change?
A governed environment removes the sensitive data leg of the three-property combination: the agent still processes untrusted input and still acts, but the values it reads on the organization's screens are tokens, so the session no longer holds all three.
The mechanism is a class of control applied to the rendered screen. Sensitive values are replaced with consistent tokens before any model reads them, so the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized for each workflow and approves consequential actions such as payments, submissions and record changes, which also gates the outbound leg where a workflow needs it. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.
This is isolation by architecture rather than instruction, which is the position this page takes. Meta's guidance holds that an agent should satisfy no more than two of three properties within a session: processing untrusted input, accessing sensitive data, and changing state or communicating (Meta AI, 2025). A system prompt cannot remove a leg, since it is content the model weighs against other content; tokenizing the screen removes one by construction, and the record shows which. Sandboxing isolates the agent from the host and needs both filesystem and network isolation, but does not address the data an agent reads inside an allowed application (Anthropic, 2025); this class of control is the complement, and the three-property inventory per workflow can be checked against the run record.
The environment does not replace sandboxing or browser isolation, and 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 removes the sensitive data leg of the three-way combination, the removal this page argues costs the agent least. 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 identifiers and regulated values reach the model as consistent tokens, such as ACCT_001 or PATIENT_001, for the whole run, and the model can still read untrusted content and propose actions without holding the values an injection would need. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change, which RedactSure calls Supervised Delegation, so the outbound leg is gated as well. 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 show, for each session, which of the three properties the agent held and the screens as the model saw them, so the Rule of Two could be checked against a record rather than a design document. Everyone else controls where data can go. RedactSure controls what the AI can see.
Methodology and limitations
This page rests on vendor research and engineering writing, preprint research, official guidance and vendor documentation. Vendor research is Meta AI's Agents Rule of Two post (October 2025). Preprints are the CaMeL paper from Google, Google DeepMind and ETH Zurich (June 2025) and the design patterns paper by Beurer-Kellner and colleagues (June 2025). Official guidance is the PCI Security Standards Council's scoping and segmentation guidance (2016) and NIST Special Publication 800-207 on zero trust architecture (2020). Vendor documentation comprises Cloudflare's browser isolation documentation (2025), Anthropic's engineering post on sandboxing (October 2025) and Anthropic's computer use tool documentation (2024). All sources were read as of October 16, 2026, and are cited for the facts they state or plainly cover.
No hands-on testing of any product, agent or research prototype 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 research patterns are described as their authors describe them and have not been evaluated here. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The payroll record example describes a record type, not any organization; no customer or prospect is described.
Whether a given isolation design meets the segmentation, access control and data protection obligations that apply to an organization's systems is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.
What the record shows
Isolating an agent from sensitive systems is a question of what the session holds, not only of where the agent runs. Researchers and vendors have converged on the same rule: a session that processes untrusted input, holds sensitive data and can act outward is unsafe while prompt injection remains unsolved, and one of the three must go. Removing untrusted input or outbound capability leaves an agent that cannot read or cannot finish; removing the sensitive data, by substituting tokens before the model reads the screen, leaves an agent that can do both without holding what an attacker would want. Sandboxing and remote browser isolation protect the infrastructure and should be kept, but they do not perform that removal. The test is to name one agent and one task and ask which of the three properties the session holds, and to ask for the screen as the model saw it if the answer is that the data leg was removed.
Frequently asked questions
Is the Rule of Two the same as the lethal trifecta?
They describe the same three-way combination from two directions. The trifecta names the combination of private data, untrusted content and external communication as the condition for a prompt injection to become an exfiltration. The Rule of Two states the operating constraint that follows: no more than two of the three in one session until injection is reliably stopped. One is a diagnosis, the other a design rule, and this page applies the rule to enterprise workflows that run through a browser.
Which leg is cheapest to remove?
For most enterprise workflows, the sensitive data leg. Removing untrusted input means the agent cannot read customer messages, web pages or free-text fields, which rules out most useful work. Removing outbound capability means every action waits for a person, which is right for consequential actions but slow for everything else. Substituting tokens for real values lets the agent read and act while holding nothing an injection could take, which is why this page treats it as the default removal.
Does network segmentation still matter for agents?
Yes, for the same reasons it matters for any connected system. An agent that can reach a sensitive system is within that system's security boundary, and limiting which systems it can reach limits scope. Segmentation operates on connectivity, though, and an agent connected to a system it legitimately needs still reads everything the system renders. Segmentation sets the outer boundary; what the model sees inside it is a separate control that has to be applied at the screen.
Can the agent still do its job if it never sees real values?
For tasks that compare, route, reconcile or summarize, yes, because a consistent token carries identity without content. The agent can tell that ACCT_001 on one screen is ACCT_001 on another and that two tokens differ. Tasks that require the real value, such as calling a customer by name, resolve the value at the approved destination at the moment of the approved action, so the value is used without ever being in the model.
How do CaMeL and similar designs relate to this?
They separate control flow from data so that untrusted content cannot change what the program does. That addresses the untrusted input leg at the level of program structure, and it is a strong pattern where an agent's plan can be fixed in advance. Browser agents that navigate screens adaptively are harder to fit to a fixed plan, which is why removing the data leg at the render layer is the complementary pattern for that kind of work.
What does an isolation record look like?
Per session: the task, the applications reached, the screens rendered with the values the model saw on each shown as tokens or in the clear, the actions proposed, and the approvals given. From that record an auditor can mark the three properties for the session and confirm which one the design removed. In RedactSure's design that record is the AI Control Record; any design should be able to produce an equivalent.
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









