Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does Blocking Untrusted Websites Protect AI Agents?

Partly: URL filtering removes the obviously hostile destinations, but trusted domains host third-party content that can carry injected instructions and offer endpoints that can proxy exfiltrated data, as the EchoLeak case showed. Check what the agent holds and can do on the sites you allow, not only which sites you block.

A dark bank of untrusted pages is separated from a raised route through approved browser windows.

Partly: URL filtering removes the obviously hostile destinations, but trusted domains host third-party content that can carry injected instructions and offer endpoints that can proxy exfiltrated data, as the EchoLeak case showed. Check what the agent holds and can do on the sites you allow, not only which sites you block. Blocking untrusted websites is the first control most security teams reach for when agents start browsing, because it is the control they already have. Secure web gateways, URL categories, allowlists and remote browser isolation were built to keep people away from malicious sites, and they do that for agents as well. The question is whether keeping an agent away from bad sites keeps it safe, and the evidence says no, for two reasons the web's structure makes unavoidable. Trusted sites render content that strangers wrote, and trusted sites expose endpoints that will fetch, redirect or embed on request. This page examines what URL filtering does protect against, why an allowlist of trusted domains is still an attack surface, how one documented exploit routed through an allowed endpoint, how an HR case record shows the gap between blocking sites and blocking actions with a reason the user can see, where browser isolation and enterprise browsers fit, and what a buyer should refuse.

Key findings

  • In EchoLeak, CVE-2025-32711 in Microsoft 365 Copilot, an allowed Teams endpoint was used to get past the content security policy, so the exfiltration request went to a trusted domain that carried it onward (arXiv, 2025).
  • A browsing agent shown to be vulnerable to indirect prompt injection operated with the user's full privileges across authenticated sessions, so same-origin style protections did not contain it; the injected content was on an ordinary site (Brave, 2025).
  • Web-based indirect prompt injection against agents has been observed in the wild, outside laboratory benchmarks (Palo Alto Networks Unit 42, 2026).
  • Google describes identifying and redacting external image URLs and suspicious links in model output as one layer of its defense for Gemini, a control on what the client fetches rather than on which sites the model may read (Google Workspace Admin Help, 2026).
  • The zero trust model evaluates each access request at a policy enforcement point rather than granting trust to a network location or domain once, which is the opposite of an allowlist's logic (NIST, 2020).
  • Blocking by site is a coarse control that interrupts legitimate work when tuned tightly and misses the attack when tuned loosely, the same tradeoff DLP rules face (How to prevent legitimate work from being blocked by DLP rules?).

What does URL filtering protect an agent against?

Credit the control for what it does. URL filtering and site categorization stop an agent from loading pages on domains known to be malicious, newly registered, or categorized as phishing, malware distribution or command-and-control. For a browsing agent, that removes the simplest attack: a page built for the purpose of injecting the agent, on a domain the attacker owns. Remote browser isolation adds a further layer by rendering pages away from the endpoint, so that whatever a page does at the browser level does not reach the organization's device; Cloudflare's documentation describes its browser isolation service in those terms as part of its Cloudflare One platform (Cloudflare, 2025). Palo Alto Networks documents a Prisma Browser product that combines enterprise DLP, advanced URL filtering and remote browser isolation in a managed browser (Palo Alto Networks, 2026).

These controls were designed for human users and the threats they face: drive-by downloads, credential phishing, malicious scripts. An agent faces those threats too, and the controls help with them. Anything beyond that is not described in the pages reviewed for either vendor, and the question for this page is what the agent faces that a person does not. A person reading a web page is not at risk of following instructions in it. An agent is. URL filtering decides which pages the agent may read; it has no view of what the page says, what the agent holds while reading it, or what the agent does next. Those three variables are where the agent-specific risk lives, and a site list touches none of them.

Why is an allowlist of trusted domains still an attack surface?

Because trust in a domain is trust in its operator, not in everyone who writes to it. Collaboration suites, ticketing systems, code hosts, document platforms, social networks, review sites and news sites with comment sections all render content that third parties submitted. An agent reading a page on any of them reads the operator's content and the strangers' content in the same stream. Brave's analysis of a vulnerable browsing agent made the point in practice: the injected content sat on an ordinary site, and the agent, operating with the user's full privileges across authenticated sessions, followed it into other sites the user was logged into (Brave, 2025). No allowlist would have excluded the carrier page.

Unit 42's reporting on web-based injection observed in the wild confirms that attackers place instructions where agents read rather than building obviously hostile destinations. The economics favor this. A dedicated malicious domain gets categorized and blocked. A comment on a trusted site is indistinguishable, to a URL filter, from the site itself.

Where the instruction sits Does URL filtering see it? Why
A page on an attacker-owned domain Usually The domain can be categorized and blocked
A comment, review or reply on a trusted site No The site is allowed; the filter does not read content
A shared document or ticket in the organization's own tenant No The tenant is the most trusted domain of all
An email in the user's mailbox No Not a web request at all
An image on a trusted site with hidden text No Image content is not inspected for instructions

The middle rows matter most for enterprise agents, which work mostly inside the organization's own systems, whose content was written by customers, suppliers, applicants and the public. The most trusted domain on the allowlist holds the most third-party content.

How did one exploit route through an allowed endpoint?

EchoLeak is the documented case of an allowlist defeated from inside. Catalogued as CVE-2025-32711 and analyzed in a peer-reviewed paper, it targeted Microsoft 365 Copilot. An attacker's email, retrieved as context when a user asked an unrelated question, instructed the assistant to include a markdown image whose URL carried session data. The client automatically fetched the external image URL included by the attacker. A content security policy limited the domains the client would fetch from, so the attacker used an allowed Teams endpoint to get past it: the client requested a trusted domain, and the trusted domain made the onward request to the attacker (arXiv, 2025).

The lesson is general. Every large platform exposes endpoints that fetch, redirect, proxy or embed on behalf of a request: image proxies, link previews, open redirects, file conversion services, webhooks. Each is a legitimate feature and each can carry a payload encoded in a URL. An allowlist that includes a platform includes those endpoints, because they live on the same domain. The lethal trifecta analysis names the underlying condition: the ability to communicate externally includes any path that causes a request to leave, down to a request to load an image (Simon Willison, 2025).

Google's documented defense for Gemini responds at the right layer. One component is identifying and redacting external image URLs and suspicious links in model output, a control on what gets rendered and fetched rather than on which sites may be read (Google Workspace Admin Help, 2026). That is an output and egress control, and it is the kind of control that an allowlist alone does not supply.

What does an HR case record show about the gap?

Consider an HR case record in a human resources system. It shows the employee's name and identifier, department, manager, salary band, the nature of a grievance, and a thread of notes and attachments, including a statement the employee uploaded and a response pasted from an external counsel's email. An agent is asked to draft a case summary for the review board, and to check the organization's policy wiki, hosted on a collaboration platform, for the applicable procedure.

Every site the agent touches is on the allowlist: the HR system, the collaboration platform, the email system. Every one of them renders third-party text: the employee's statement, the counsel's email, wiki pages that many staff edit. If any of that text carries an instruction to include the employee's identifier and salary band in an image link, or to post the grievance details to a page the attacker can read, the URL filter sees a sequence of requests to trusted domains and allows every one. Blocking untrusted websites protected nothing, because the agent never visited one.

Two controls would have. If the record reaches the model with EMP_001 and BAND_001 in place of the identifier and salary band, the injected instruction produces tokens, and the data is protected without blocking the work. If posting to an external page or sending a message is a gated action that requires a named person to approve while seeing the destination, the exfiltration meets a checkpoint that a site list cannot provide. Neither control cares which domain the carrier page was on. Both key on what the agent holds and what it does, which is the pair of variables that a URL filter, by design, does not see.

Where do browser isolation and enterprise browsers fit?

They fit as the layer they were built to be. Remote browser isolation, as Cloudflare documents it, renders web content away from the endpoint so that browser-level threats stay off the device (Cloudflare, 2025). An enterprise browser such as the one Palo Alto Networks documents combines URL filtering, DLP inspection and isolation in a managed browser the organization controls (Palo Alto Networks, 2026). Both reduce what a hostile page can do to the browser and the device. Whether either inspects page content for instructions aimed at a model, or changes what a model sees on a rendered page, is not described in the pages reviewed.

The gap is one of object. These controls govern the browser; the agent-specific risk lives in the model's reading of the page and in the model's subsequent actions. A page rendered in an isolated browser is still read by the model in full, including the comment that carries the injection. A DLP policy that inspects outbound data for patterns catches a Social Security number typed into a form and misses an employee identifier the organization's own system issued, which no pattern library knows. Isolation and enterprise browsers are a reasonable foundation, and they leave the two agent variables, what the model holds and what it does, to be governed by something else.

NIST's zero trust architecture supplies the principle for that something else. Access is evaluated per request at a policy enforcement point, with no trust extended to a network location or a domain as such (NIST, 2020). Applied to agents, that means evaluating each consequential action, with its destination, at the moment it is attempted, rather than trusting every action on an allowed site. An allowlist is a perimeter. Zero trust is the argument for not relying on one.

What does a governed environment change?

In a governed environment, an injected instruction on an allowed site finds an agent that holds tokens rather than real values and cannot complete a consequential action without a named person, so the question moves from which sites the agent may visit to what it can hold and do on any of them.

The mechanism is a class of control on the agent's data and actions rather than on destinations. Sensitive values on the rendered page are replaced with consistent tokens before any model reads them, and the task runs on those tokens. Real values resolve only at an approved destination at the moment of an approved action, so a request that routes data to an image proxy or link preview on a trusted domain carries tokens. A named person confirms what is tokenized and approves consequential actions, including payments, submissions and record changes. Every page read as tokens, every action with its destination and every approval is recorded and exported to the organization's own logging.

This is the control the previous section asked a vendor to demonstrate on an allowed site with a real record open. EchoLeak left through a trusted Teams endpoint that carried the request onward (arXiv, 2025), and the Brave analysis showed a browsing agent operating with the user's full privileges after reading an ordinary site (Brave, 2025). An allowlist decides neither what the agent held in those cases nor whether a person stood between the injected instruction and the action. A governed environment decides both, and it evaluates each action rather than trusting a domain once.

The control does not change which sites are blocked, the applications, the user's permissions or the model; URL filtering still removes hostile destinations, and the environment governs what happens on the ones that remain.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design governs the two variables a site list does not see. Agents run in a governed environment in the customer's cloud. Substitution happens at the render layer, before any model reads the screen, so the HR case record described above reaches the model with EMP_001 and BAND_001 in place of the identifier and salary band, with consistent tokens for the whole run, whatever domain the page is on and whoever wrote the comment beside it. Real values resolve only at approved destinations at the moment of an approved action, so a trusted platform's image proxy is never a resolution point. A named person confirms the tokenization policy and approves every payment, submission and record change under Supervised Delegation, with the destination shown from the environment. 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 place an injected instruction in a comment on an allowed site, run the agent with a real record type open, and show what the model held, what it attempted and what the record captured. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on the peer-reviewed EchoLeak analysis presented at an AAAI symposium in 2025, Brave's published analysis of indirect prompt injection in a browsing agent, Palo Alto Networks Unit 42 reporting on web-based injection observed in the wild, vendor documentation from Cloudflare on browser isolation and from Palo Alto Networks on Prisma Browser, Google's Workspace administrator documentation on its layered defense for Gemini, the lethal trifecta analysis by Simon Willison, and NIST Special Publication 800-207 on zero trust architecture. Existing RedactSure research pages on protecting data without blocking work, seeing why a policy blocked an action, and protecting data from agents that navigate screens are cited as evidence for the design points they document. All sources were read as of October 16, 2026.

No hands-on testing of any gateway, browser, isolation service, agent or product was performed for this page. Vendor products are described from their own documentation; where a capability is described as "not described," that means it was not found in the pages reviewed, not that the vendor lacks it, and in particular no statement is made about whether any named product inspects content for model-directed instructions. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The HR case record and policy wiki examples describe record types, not any organization; no customer or prospect is described.

Whether a given deployment's web filtering, egress controls or handling of employee and other regulated data meets an organization's requirements is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Blocking untrusted websites protects an agent against the attacks a person would also face and leaves the agent-specific risk untouched. Injected instructions arrive through trusted sites, because trusted sites render content that strangers wrote, and exfiltrated data leaves through trusted sites, because trusted platforms expose endpoints that fetch and redirect on request; the one documented production exploit did exactly that through an allowed endpoint. URL filtering, isolation and enterprise browsers are a reasonable foundation and do not see what the model holds or what it does. Those two variables need their own controls, and render-layer substitution of the kind RedactSure describes governs the first on any site at all. The test is to name one agent and one task, place an instruction in a comment on a site you allow, and ask what the agent held and what it tried to do.

Frequently asked questions

Does URL filtering help at all with AI agents?

Yes, for the threats it was built for. It keeps the agent off domains known to be malicious, which removes the simplest attack, a page built to inject the agent on a domain the attacker owns. It does nothing about instructions in third-party content on allowed sites, and nothing about what the agent holds or does. Treat it as a foundation that handles the threats people also face, while other controls handle the ones that only an agent that reads and acts can create.

Why is a trusted site still dangerous to an agent?

Because trust in the site's operator is not trust in everyone who writes to it. Comments, reviews, replies, shared documents, tickets and wiki pages carry text that customers, suppliers, applicants and the public wrote. An agent reads that text in the same stream as the site's own content and cannot structurally tell a planted instruction from a legitimate note. The organization's own tenant holds the most third-party text of all.

How did EchoLeak get past the allowlist?

The client's content security policy limited fetches to allowed domains. The attacker's instruction made the assistant include an image URL that pointed at an allowed Teams endpoint, which proxied the request onward to the attacker's server. The client never contacted an untrusted domain. The lesson is that any allowed platform's proxies, redirects, link previews and webhooks are routes out, and they are allowed precisely because the platform is trusted.

Does remote browser isolation protect the agent?

It protects the device and the browser from what a page does at the browser level, which is what it was designed for. The model still reads the full page, including the comment that carries the injection, so isolation does not change what the agent is told or what it holds. Whether any isolation product inspects content for model-directed instructions is not described in the pages reviewed for this page.

Can DLP on outbound traffic catch what an injected agent sends?

Sometimes. Pattern-based inspection recognizes formats it knows, such as card numbers and government identifiers, and misses the identifiers an organization's own systems generate, which have no public format. It also inspects the sent data after the model has already held it. Bounding what the model sees on the screen, so that organization-issued identifiers reach it as tokens, works for exactly the values DLP cannot recognize.

What should govern the agent on allowed sites?

What it holds and what it does. Render identifiers as consistent tokens before the model reads any screen, so that a planted instruction on any site yields placeholders. Gate payments, submissions and record changes by action type and destination, approved by a named person who sees the real destination. Record every page read, every action and every approval and export it to the organization's own monitoring. None of these depends on the domain, which is the point: the control travels with the agent to every site it is allowed to visit.

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.