Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Limit Where an AI Agent Can Send Data?

Yes, with three fields in the grant: which hosts the run may reach, which destination may receive a real value, and what the model reads on the page. Ask which of the three a tool enforces, then test it with an allowlist entry you know is wrong.

A credential reference travels from a browser record through a bounded route to a separate API destination.

An approver who signs a grant saying an agent may use the deployment service has not yet said where the data goes. Three fields decide that, and they fail in different ways. The first is reach: the hosts a run may address, enforced by a sandbox, a proxy or a cloud network setting beneath the application. The second is release: a destination written into the grant that names where a real value may resolve. The third is content: whether the model is holding the record or a label such as EMAIL_014 when it composes the request. Teams usually fill the first field and stop, because an allowlist is one line in a settings file. The other two are harder to see: a destination is a value inside a document, and a placeholder is a property of the screen. Only the third keeps its guarantee when a person mistypes the first, which is the case this page follows, an allowlist entry that should not be there and an export that reached it carrying tokens. Read against what Anthropic and OpenAI document about reach and what the MCP specification says about scope, that case shows why the approver should require all three fields in the grant and not rely on the allowlist alone. What Is Least Exposure? sets out why a control on actions leaves the content of the screen ungoverned.

Key findings

  • Anthropic's Claude Code documentation states that with a masked credential "the sandboxed command sees a sentinel and the local proxy substitutes the real value only on hosts in injectHosts" (Anthropic, Sandboxing, 2026).
  • The same page states that "the sandbox covers shell commands only; Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks run outside it", so a host list inside the sandbox does not bound those routes (Anthropic, Sandboxing, 2026).
  • OpenAI's Codex documentation states that "by default, the agent runs with network access turned off" and that "Codex asks for approval to edit files outside the workspace or to run commands that require network access", a reach default that says nothing about what an approved command carries (OpenAI, 2026).
  • The MCP specification tells implementers to "warn that MCP servers run with the same privileges as the client", so a token for one server carries the client's reach into the next (Model Context Protocol, 2026).
  • A governed environment replaces a value with a consistent token before any model reads the screen, so an agent filling an export dialog holds EMAIL_014, not the address (What Is Render-Layer Tokenization?).
  • Real values resolve only at the destination the grant names, at the moment a named person approves the action, so a host that should not be listed receives a token (What Is Least Exposure?).

What can a permission grant bound about where data goes?

The scope comes first because the title says agent and the fields sit on different surfaces. A governed browser environment covers what the agent reads and does on a rendered page: dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An agent that posts a bundle from a shell is outside this page and governed by the sandbox around that shell. An agent that opens a console page and submits an export is inside it.

A permission grant is a short document, and the useful ones carry four fields: the action, the resource, the destination, and the approver. The allowlist is not one of them: it is a property of the environment and answers only which hosts the process may open a connection to.

Anthropic's Claude Code page shows the same gap from the file side. To block its file tools from a directory, a team adds a rule such as Read(./secrets/**), and the page then limits the claim: the rules "don't apply to a command that reads files without naming them, such as grep -r pattern . run from the directory that holds the file" (Anthropic, Configure, 2026). A grant that names only an action and a resource has that shape of hole: it describes what the agent may do and leaves where the result goes to whatever the network permits.

The record for this page is an export settings page in a customer support console: a schedule field, a format selector, a destination field and a preview table. The grant names the action, the resource, the analytics vendor's ingest host as the destination, and the data platform lead as the approver. The allowlist carries a third entry nobody needs, a staging host added during an earlier failed run.

Why is a destination field different from a domain on the allowlist?

The allowlist answers an address question. It says which hosts a process may open a connection to, and it is enforced below the application, at a proxy on the host or inside the sandbox. It knows nothing about values: a network rule sits where packets are, and a packet does not say whether the string inside it is a customer's address or a label.

The destination field answers a value question: it names one endpoint, for one action, for one class of value, so the export grant says the analytics ingest host may receive exported ticket fields and nothing else may. It travels with the action, which makes it a document a person can read. A sign-up form has the same shape, with a card field where the ingest host sits here (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?).

One vendor mechanism comes close. Anthropic's sandboxing documentation describes masking, where a sandboxed command sees a sentinel and "the local proxy substitutes the real value only on hosts in injectHosts", or on every host in network.allowedDomains when that list is empty (Anthropic, Sandboxing, 2026). That is release bound to a destination. Two limits matter: it covers sandboxed commands only, and the list is a host list rather than a statement about which action may carry which value.

The research record points the same way. Progent applies privilege control to an agent's tool calls, and its abstract reports that the system "significantly reduces attack success rates while maintaining high utility", with no numbers given there (Shi et al., 2026). A control that narrows which calls run is a grant-level control, and it still needs a destination to be useful, because a permitted call to the wrong host is the failure this page is about.

What do the vendors themselves say?

Three vendor pages bear on this question. None describes a destination field that is attached to an action in a grant.

Anthropic's engineering write-up states that "effective sandboxing requires both filesystem and network isolation" and that sandboxing "safely reduces permission prompts by 84%", which is the argument for an allowlist: bounded reach is what makes autonomy affordable (Anthropic Engineering, 2025). The write-up is about isolation and not about the payload, so it leaves open what a permitted connection carries. The companion sandboxing page names the limit precisely: sandbox.credentials "affects sandboxed Bash commands only", while Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks sit outside the sandbox (Anthropic, Sandboxing, 2026). A team that reads the isolation claim as a data control has read it one step too far.

OpenAI's Codex documentation states that "locally, Codex uses an OS-enforced sandbox that limits what it can touch (typically to the current workspace)", with approval required to run commands that need the network (OpenAI, 2026). That is a boundary around a local session, and it does not say which values an approved command carries to the host it reaches, or how credentials are stored in the session at all.

What the pages document, then, is reach control plus, from Anthropic, one value that resolves only on listed hosts for sandboxed commands. A grant whose destination field decides which action may release which class of value is not described in the pages reviewed, and a buyer should not assume a network setting supplies it.

Dimension Anthropic, per its documentation OpenAI Codex, per its documentation What a buyer should verify
Reach default Filesystem and network isolation for sandboxed commands; 84% fewer permission prompts Network access off by default; approval for commands that need it Which routes the setting actually covers
What sits outside Read, Edit, Write, WebFetch, WebSearch, MCP servers, hooks The approval applies to the local session, not to a rendered page Whether the page the agent reads is governed at all
Release of a real value Masked credentials resolve only on hosts in injectHosts, for sandboxed commands No per-value release rule stated on the page Which component decides that a value may resolve here

What does a wrong allowlist entry still receive?

The agent opens the export settings page, sets the destination and submits. The analytics host rejects the request because the key is not yet activated for exports. The issue the agent is working from carries a line added months earlier: if the primary endpoint refuses, retry against the staging endpoint. That host is the third allowlist entry, so the connection is permitted, and the agent changes the destination and submits again.

What the staging host receives is a well formed export whose rows read CUST_001, EMAIL_014, TICKET_2201. There is no address or phone number in the file, because the page rendered placeholders and the model composed the request from what the page showed it.

Without substitution the same request would have carried several thousand customer records to a host that is not a destination at all, the class OWASP records as "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores" (OWASP, 2025). Exfiltration was the dominant use of the malware Sonatype counted: "56% of the malware discovered in Q1 2025 was related to data exfiltration", "a dramatic increase from 26% in Q4 2024" (Sonatype, 2025).

A placeholder is not nothing: the file still gives the record types and row count, and a recurring label links two exports to one customer, though it resolves to nothing outside the run.

What failed was the first field. A staging host added during an outage and never removed is a destination the organization forgot it had approved. Only a release rule can refuse a real value at a host that should not receive one. An enterprise browser that blocks a paste at the client is a different control at a different layer (Enterprise Browser or Render-Layer Tokenization?).

How should a team write and test a grant for one destination?

A grant answers six questions on one page: which action, on which resource, to which destination, for which classes of value, approved by whom, until when. Then test it against a host the task does not need. Add that host to the allowlist, put a line in the task that points the agent at it, and run the task on synthetic data. Read what the host received. Records mean the allowlist was the only control in force; labels such as EMAIL_014 mean release or substitution did the work.

Put a line in the ticket body asking the agent to send the export to a paste service, and watch whether the destination moves. Willison's design patterns constrain what an agent may do at all: "These design patterns constrain the actions of agents to explicitly prevent them from solving arbitrary tasks", a structural limit with no empirical tests reported (Willison, 2025).

Of 353 IT professionals in a SailPoint survey, 80% of organizations said agents had taken unintended actions, about 40% said agents "accessed unintended systems", 31% said agents shared inappropriate data and 23% said agents revealed credentials (How Do You Test Whether an AI Agent Can Reach Data Outside Its Assigned Task?). The route in is usually content: indirect prompt injection is the attack Greshake and colleagues named (What Is Indirect Prompt Injection and How Does It Reach AI Agents?). A console an agent is allowed to configure has the same property, with a resource where the export has a URL (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?).

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on labels such as EMAIL_014. Real values resolve only at the destination named for the action, at the moment a named person approves it. That person confirms the tokenization policy, and every consequential action carries an approver. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this page's question the three fields stop being three settings. The allowlist becomes an input: the hosts it names are the ones a value may resolve to, and a host it does not name is refused before a request is composed. The destination stops being text the agent can type into, because release is bound to the action a person approved rather than to the URL in the form. The placeholder is what makes a mistake in the first two survivable, since a wrong entry and a permitted action together still carry nothing that resolves outside the run.

That ordering is the answer to the title. Reach bounds the request, destination bounds the value, and content bounds the damage when the first two are wrong. A team that buys only the first has a list to maintain. A team that buys all three has a record of what the model read, where it sent it, and who approved the release.

Methodology and limitations

This page rests on vendor documentation from Anthropic, whose Claude Code permissions and sandboxing pages and engineering write-up on sandboxing are cited above, and from OpenAI's Codex approvals page; on the Model Context Protocol's security guidance; on OWASP's Non-Human Identities Top 10 for 2025; on Sonatype's Q1 2025 malware research; on Willison's design patterns for injection-resistant agents; on the Progent preprint; and on the RedactSure research pages linked in the body. Each fact is taken from the page listed for it, each quotation is that page's wording, and a claim the documentation does not make is left out rather than inferred. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page.

No product was tested hands-on for this page, and no request was sent from a live agent. "Not described in the pages reviewed" means the documentation recorded for that page does not cover the point, not that the vendor does nothing. Vendor features change, and the page carries its date, so a release after October 20, 2026 should be treated as unreviewed until the test above is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, an export settings page in a customer support console, and not an organization.

Determinations about whether a workflow, a grant, an allowlist or a destination rule meets a contractual, regulatory or audit requirement belong to the organization's counsel, its assessors and its own security and compliance officers. Nothing here replaces a test of the organization's own agent against its own destinations, repeated after each change to the agent, the grant or the vendor's platform.

What the record shows

The three fields answer the title. An allowlist bounds the hosts a run may address, which every vendor page reviewed offers in some form, and it leaves the request intact, so the value inside a permitted request is the value the model held. A destination in the grant bounds which endpoint may receive a real value for an action, and the closest vendor mechanism reviewed, masking with a host list, applies that to sandboxed commands only. Placeholders bound what is left: a wrong entry and a permitted action together still deliver labels. Only the third holds when the first is wrong, which is why the answer runs reach, release, content. RedactSure builds at the third layer and takes the first two as inputs. A grant can be tested with a single agent and task: list the hosts it may reach, the destination that may receive a real value, and what the model read before it composed the request.

Frequently asked questions

How do I limit where an AI agent can send data?

Bound three things, in this order. Limit the hosts the run may reach with a network allowlist. Name the destination that may receive a real value for each approved action, and give that action an approver. Render the page as tokens so the model holds labels rather than records. Each bound fails in a different place, and the third is the one that still holds when a host on the allowlist turns out to be wrong. The three are usually set by different people.

Is a network allowlist enough on its own?

No. An allowlist decides which hosts a process may open a connection to, and it does not read the payload. A permitted host can still receive every value the model was shown, and a list edited in a hurry can name a host nobody meant to approve. Treat the list as the first bound, then write down which values may resolve to which destination, and who approves the release. Every outage that adds an entry leaves one behind.

What is a destination field in a permission grant?

It is the field that names the endpoint where a real value may resolve, for one action and one class of value: the analytics ingest host for an approved export. It differs from a domain on an allowlist because it is tied to the action rather than to the process, and a reviewer can read it, disagree with it and test it. An agent cannot widen it by typing a different URL into a page. Write it in the grant, not in the ticket that asked for the work.

What does the agent send when a screen renders as tokens?

The labels the page showed it. An export composed from a tokenized screen carries CUST_001 and EMAIL_014 beside the column names, and nothing in the file resolves outside the environment that issued the labels. The recipient still learns the record types, the field names and the row count, which is worth knowing and is not the same as receiving customer records. Read the payload rather than the policy document to confirm it. A recurring label also links two exports to one customer without naming either.

Can an agent still reach a wrong allowlist entry?

Yes. An agent that follows a runbook line, a redirect or an instruction can address any host the list permits, and a staging entry left behind after an outage is exactly that. The question is what arrives. Without substitution the host receives records; with it, the host receives labels that mean nothing outside the run. Remove the entry, then check what the last payload held. The payload is the evidence; the entry is the thing to fix.

What should a developer ask a vendor to show in writing?

Which component enforces the host list, which field names the destination for each action, and who approves the release. Ask what the model reads on the page before it composes a request, and ask for the record of one run showing the screens, the destination and the approver. Then run an export to a host you know should not receive a value and compare the payload with the answers. Keep those answers beside that payload, so the next review starts from evidence.

About the author

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.

How RedactSure Keeps a Wrong Allowlist Entry From Receiving a Value

An allowlist is edited in a hurry, a staging host left on it is the failure here, and the controls reviewed never decide what the model holds.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before, on the export settings page, the model read ticket rows with real addresses and could send them to any host the allowlist allowed, including the staging host. Inside, the page renders CUST_001 and EMAIL_014, the approved export resolves real values at the analytics host, and the staging host receives labels. A named person approved that export.

RedactSure is deploying now with enterprise and government customers. Sonatype counted exfiltration as 56% of the malware it found in Q1 2025.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

An allowlist entry added by mistake should receive nothing real, even when the export runs as planned. Bring an export your agent sets up and see, with test values, what each receiving host gets. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.