Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Limit Where a Hijacked Agent Can Send Data?

A hijacked agent can only send to places it can reach, so bound the network first, bound where real values resolve second, and leave the model holding placeholders. Check which of the three layers a tool documents, then send one test request to an allowed domain and read what it carried.

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

For a security owner approving an agent, the question of where a hijacked run can send data has three answers, and they are not interchangeable. One bounds the destinations a request may reach. A second bounds the value a request may carry to a destination, so an approved host receives a placeholder and the real value resolves there and nowhere else. A third decides what the model ever read, so a hijacked run has nothing to send. Teams tend to buy them in the reverse order of their difficulty: an allowlist is a setting in a cloud environment or a sandbox, a destination policy is a rule someone has to own, and placeholders require the screen itself to be governed. The page tests all three against one record type, an alert-routing page in an observability console whose destination already sits on an allowlist, using what OpenAI, Anthropic, Docker and E2B document about network access and credential handling, the MCP specification's rule on token scope, and the research on how often an injected instruction wins. What Is Least Exposure? sets out the second control in general terms; this page covers where each of the three sits and what each stops.

Key findings

  • OpenAI's Codex cloud page says "setup scripts still run with internet access so you can install dependencies," a window that opens before the agent phase and its network block begin (OpenAI, Codex Cloud, 2026).
  • Docker's sandbox documentation states that "outbound TCP traffic from the sandbox routes through a proxy on your host," which puts every destination a run reaches behind one inspection point (Docker, 2026).
  • E2B's documentation describes the same boundary from the credential side: "the egress proxy injects the real value into matching outbound HTTPS requests outside the sandbox," so a sandbox configuration "contains only a reference to the secret" (E2B, 2026).
  • Adaptive attacks bypassed 12 published defenses with an "attack success rate above 90% for most," many of which had reported near-zero rates, so a detector on the way in or the way out is not a boundary (Nasr et al., 2025).
  • A destination policy bounds where a real value resolves, so an allowed host receives a placeholder and the value appears only at the destination a person approved (What Is Least Exposure?).
  • An agent whose screens render as tokens has nothing worth sending, so a hijacked run that reaches an allowed domain carries labels such as SVC_001 in place of the credential (What Is Render-Layer Tokenization?).

What does an egress boundary cover, and what does it leave open?

The scope comes first, because the title says agent and the controls sit at different layers. A browser control of this kind covers what an agent reads and does on a rendered page: a dashboard, a console, a settings page or a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An agent that reaches a host from a shell is governed, if at all, by the network boundary around that shell. An agent that opens a console page and submits a form is inside the page boundary.

An egress boundary is a statement about destinations. It says which hosts a process may reach, and vendors enforce it beneath the application with a proxy on the host or an OS-enforced sandbox. Codex's local mode is described the same way, as "an OS-enforced sandbox that limits what it can touch," with network access off by default and approval required for a command that needs it (OpenAI, Agent, 2026). None of those layers reads the page the agent is working on, and none knows which field held a token.

That is why the two boundaries are complements rather than substitutes. A page control with no egress boundary can keep a value out of the model and still let the agent address any host it likes. An egress boundary with no page control bounds the destination and leaves the request intact. A team with only one of the two has answered half the title.

A policy that lives in one tool travels badly, because a second console applies its own copy and the two drift apart (How Do You Keep Data Access Policies Consistent Across AI Tools?). An egress list that exists in four tools is four lists, and a hijacked agent finds the loosest one.

Why does a request to an allowed domain still leak?

Take one record type: an alert-routing page in an observability console. The page has a destination field already set to an ingest host on the egress allowlist, a payload template, and a service token field that signs the request. An agent asked to wire up alerting reads the page, copies the token into the template, and sends a test event. The request leaves for an allowed host by an allowed method, and it carries the token in a header.

Nothing in the transaction is out of policy: the host is allowed, the method is allowed, and the agent is doing the task it was given. The allowlist did its job, because the request was addressed to a host the organization trusts; the value inside it was the part nobody had a rule for. Browsing agents in a measured study showed "prompt injection, domain validation bypass, and credential exfiltration," and the authors "demonstrate how untrusted web content can hijack agent behavior" (Mudryi et al., 2025). The last of those findings is the one an allowlist cannot see.

Layer What it decides What it cannot see
Egress allowlist Which hosts and methods a request may use What the request carries
Destination policy Which values may resolve to a given host, at which action What the page showed the model
Render-layer substitution What the model reads on the screen Where an approved action may send a value

The table also shows why the layers are bought in that order. An allowlist is one setting and covers every process on the machine, so it comes first. A destination policy needs an inventory of value classes and owners. Substitution needs control of the screen, so it covers the case the other two cannot.

An environment variable is not a fix. E2B draws the line for its own environment, noting that a variable differs from a secret because "any code running in the sandbox can read it" (E2B, 2026). The same is true of a token painted into a form: anything the agent reads in order to fill a field is in the context the injection addresses.

What do the vendors themselves say?

Four vendor pages bear on the question, and none of them claims to bound what an allowed request carries.

OpenAI's Codex cloud page states that "by default, Codex blocks internet access during the agent phase," and advises teams to "allow only the domains and HTTP methods you need, and review the agent output and work log" (OpenAI, Codex Cloud, 2026). The same page lists prompt injection from untrusted web content as a risk of turning internet access on, and it is marked Legacy.

Anthropic's Claude Code page describes a mode that will "sandbox bash commands with filesystem and network isolation, reducing permission prompts while maintaining security" (Anthropic, Security, 2026). It then limits the claim: "the boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can" (Anthropic, Security, 2026). The credential story is separate: "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM," and the VM holds "a short-lived credential scoped to that session" (Anthropic, Security, 2026). It closes with a sentence to copy into a review: "while these protections significantly reduce risk, no system is completely immune to all attacks" (Anthropic, Security, 2026).

The proxy designs cited above bound the request, not its contents. Docker routes every outbound connection through a proxy on the host, and E2B injects a real value at that proxy only for matching requests. Neither describes a check on what else the request carries. What is not described in the pages reviewed is a rule that decides which value a permitted request may carry to which host.

Where should a destination policy sit?

A destination policy is a rule about values rather than addresses. It names the classes of value that may resolve to a given host at a given action, and holds the rest back: the alert-routing page may send a placeholder to the ingest host while the same token may not resolve to a paste service. It sits between the egress list and the page, above the network because it knows what the request carries, and below the model because it decides what the model was shown.

OWASP's CI/CD guidance is the same rule in credential form: "prefer using temporary credentials over static credentials," and "avoid sharing the same set of credentials across multiple contexts" (OWASP, 2026). The MCP specification makes the scope point: "poor scope design increases token compromise impact, elevates user friction, and obscures audit trails," and it requires that "MCP servers MUST NOT accept any tokens" that were not issued for that server (Model Context Protocol, 2026). OIDC settles how the pipeline authenticates, and the destination rule is what the authenticated request may then carry (How to Set Up S3 and GitHub With Cowork or Dots). Durability is the last question, because a long-lived credential is the case to refuse outright, and the guidance against root access keys recorded in Is It Safe to Let an AI Agent Set Up Your Cloud Environment? is that refusal stated for identity. The scale is the volume of credentials already in source, which How Do You Let an AI Agent Manage API Keys Without Reading Them? collects.

What is left to send when the agent holds placeholders?

The third layer changes what a successful request carries. An agent working a page whose values render as tokens can still be told to send the page: the request is composed, the allowlist may permit it, and the body contains SVC_001 where the service token sits, beside the field name that says what it means. What arrives is a description of the record, not the record.

That is worth something to an attacker and not what they came for. Sonatype reported that "56% of the malware discovered in Q1 2025 was related to data exfiltration," "a dramatic increase from 26% in Q4 2024," which describes an attacker population built around sending data out (Sonatype, 2025). A placeholder converts that traffic into labels that resolve only inside the environment that issued them.

A label beside a field name tells an attacker the shape of the record, and a label that recurs across screens links two records to one person without naming the person. The reach is the first thing to measure, and How Do You Test Whether an AI Agent Can Reach Data Outside Its Assigned Task? records a survey in which 80% of organizations said agents had taken unintended actions. The second is what the reached system holds, which How Do You Isolate AI Agents From Sensitive Company Systems? treats as a property of the session.

Two destinations belong on no allowlist. The MCP guidance names one: "cloud metadata endpoints often expose IAM credentials, API keys, and other secrets" (Model Context Protocol, 2026). The other is the ingest host this page's record uses, which accepts a payload from any client that presents a token: fine for a placeholder, poor for a value.

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 placeholders such as SVC_001. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, and a send to an external host is one. 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 it merges three decisions that the vendor pages keep separate. The egress list becomes an input: the destinations it names are the ones a value may resolve to, and the rest are refused before a request is composed. The destination policy becomes a rule enforced at resolution rather than a document maintained in four tools. The token becomes the reason a request composed under an injection carries nothing that resolves outside the run.

It also produces the statement the other controls cannot. An allowlist can show which hosts were refused. A proxy can show which request received a value. Neither shows what the model read before it composed the request. A record of the screens, the actions and the approvers answers that question after the fact, which is where an incident review starts.

What the environment does not do is choose the policy. The hosts, the value classes and the approvers are the organization's to set. A policy nobody wrote cannot be enforced, and an allowlist nobody reviewed is a list of destinations that happened to be convenient.

Methodology and limitations

This page rests on vendor documentation from OpenAI (two Codex pages), Anthropic's Claude Code security page, Docker's sandbox architecture page and E2B's secrets page; the Model Context Protocol specification's security guidance; OWASP's CI/CD credential guidance; Sonatype's Q1 2025 package research; two preprints, one on browsing agents and one on adaptive attacks; and the RedactSure research pages cited 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 below 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 alert-routing page in an observability console, and not an organization.

Determinations about whether a workflow, a credential design or an egress 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 policy or the vendor's platform.

What the record shows

The record answers the title in three parts, and the order is the answer's main claim. An egress list bounds the hosts a hijacked agent can address, and every vendor page reviewed offers some version of it, from a cloud environment that keeps the network off during the agent phase to a proxy on the host. It leaves the request intact, so the value inside an allowed request is the value the agent held. A destination policy bounds which values resolve to which host. Placeholders bound what is left: an agent that never read the value has nothing worth sending, and a successful injection collects labels that resolve only inside the run. RedactSure's environment is built at the third layer, with the first two as inputs. Before approving an agent, a team should test one agent on one task against three questions: which hosts its requests may reach, which values may resolve to those hosts, and what the model read before it composed the request.

Frequently asked questions

Can I stop a hijacked agent from sending anything at all?

No. An agent with a browser session and a task can always compose a request, and the record on adaptive attacks says the instruction that hijacks it can be made to land. What a team can do is bound where the request may go, bound which values resolve to that destination, and keep the value out of the model. A design that assumes the instruction fails has to be right every time. A send that carries a label is still a send, and it hands over nothing spendable.

Does an egress allowlist stop data exfiltration?

Only the part addressed to a host nobody listed. An allowlist removes the unattended route and pushes an attacker toward a service the organization already trusts, which is real progress. It does not inspect the envelope, so a token pasted into a permitted webhook leaves through the allowlist. The list is still worth having, because it turns an unbounded problem into a short list of services whose logs somebody can read. Treat it as the first control and add a rule about what an approved host may receive.

What is a destination policy, in practice?

A written rule that names which classes of value may resolve to which host at which action, plus who approves the resolution. In practice it is a short table: the ingest host may receive a log token, the payment gateway may receive a card token, a paste service receives nothing. Every entry answers two questions, what value and what destination, and the environment enforces the table when a value would resolve. Write it where the environment can read it, not where a wiki can.

Do placeholders make an injection harmless?

No, they make it unprofitable. The instruction still runs, the request still leaves, and the attacker still learns the shape of the record, the field names beside each label, how many rows the run touched and when it fired. A label that recurs across two screens also links those records to one person. The gain is narrow, and it is the one that matters: nothing resolvable outside the run travels with the request. Measure it by reading the outbound message, not by trusting the policy document.

Which control should a team turn on first?

The one the platform already offers, in ascending order of effort. Network access off by default, then a domain and method allowlist, then a proxy or egress rule that holds the credential outside the agent's process. A team that starts at the top gets most of the reduction for a fraction of the work. Placeholders require a change at the screen, so they come last, and they cover what the other three cannot: an allowed request whose payload nobody inspected.

What should a security team ask for in writing?

Which destinations a run may reach and how the list is enforced; which values may resolve to each of them and who approves the resolution; what the model reads on the screens the agent opens; and what record exists after the run showing all three. Ask for the record rather than the description, then run one test event to an allowed destination and compare the answers with the request that arrived. Keep those answers beside the record, 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 Real Values Off an Allowed Destination

An allowlist decides which hosts a request may reach without touching its contents, and the proxy designs reviewed never govern what the model read.

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

Before, on the alert-routing page, the model read the token and pasted it into the payload template, so the test event left for an allowlisted host carrying the real string. Inside, the field renders SVC_001, the request reaches the same host, and the named person approves the send.

RedactSure is deploying now with enterprise and government customers. Sonatype counted data 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 allowlisted host can still receive a real token if the agent reads it and pastes it into a payload. Bring an alert-routing task and see, with test values, what the test event would carry. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.