Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Lakera Guard Protect Agents That Browse Websites?
No: Guard screens prompts, tool calls and tool responses only when the harness sends them to its API, and a browsing agent's page content reaches the model whether or not that call happens. Ask what the model received from the rendered page, and who approved the change it made there.
A browsing agent opens a clinic's billing portal and reads what the page draws: a member ID, a date of birth, the card on file. The guardrail bought for that run is called over HTTP by something else in the stack, so the page's values can be in the model's context before any filter is consulted. Guard is an API that screens a request, and the request is assembled by whatever code drives the browser, so coverage follows the integration rather than the vendor's policy list. What is at stake for the security team is the value a hijacked or merely careless run carries out of the page, and no setting in the guardrail removes a value the model already holds. Agentic AI, in the working definition of one industry review, pursues goals autonomously "without constant human oversight," so what a page shows it becomes the exposure (MIT Sloan Management Review, 2025). The guard's policy list decides what it does with a request it receives, and the harness decides whether it receives one at all. Two integrations produce two answers on the same portal, so a team should compare the prompt text each run produces.
Key findings
- For Guard to protect a browsing agent, the values on the rendered screen would have to be replaced with consistent tokens before any model reads them, with real values released only at the approved destination (Screen-Level Tokenization vs API Filtering for AI Agents).
- It would also require a named person approving each record change the agent proposes, and a record of what the model received on each screen (What Is the Lethal Trifecta for AI Agents?).
- Check Point's Guard pages describe screening, blocking and masking on the request path, and they do not describe replacing a value on the page an agent opens (Check Point, Introduction, 2026).
- Check Point says Guard "secures the AI applications and agents your organization builds and deploys," with "real-time detection and flagging of prompt attacks, data leakage, content violations, and off-policy agent behavior through the Guard API" (Check Point, Introduction, 2026).
- AgentDAM tested web agents and found them "prone to inadvertent use of unnecessary sensitive information," the failure it brings to every page (Zharmagambetov et al., 2025).
- Twelve published defenses fell to adaptive attacks with an "attack success rate above 90% for most," the bar a detector has to clear on the day of the attempt (Nasr et al., 2025).
What does a browser agent read on a page that never reaches Guard?
The Guard API is called by something else. Check Point's documentation tells an AI gateway or the GenAI application to "make an API request to the Guard API for each user interaction or agent step," which puts the check on the request a piece of code assembles (Check Point, Introduction, 2026).
The record for this page is a clinic portal's patient billing page, opened by an agent asked to update the card on file. The page renders a member ID, a date of birth and the last four digits of the card. The harness drives the browser itself and sends the rendered text to a model provider on its own connection, so nothing in that path calls Guard, and the page's values sit in the model's context.
A governed browser environment covers what the agent reads and does on a rendered page, a portal's billing page included; it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP (Should AI Agents Use Screens, APIs or MCP?). What the model receives from that page is the exposure, and the code that hands the page over, not the guardrail, decides it (Does an AI Agent Browse With My Real Browser Profile?).
What does Guard receive when a page is routed through it?
Routing changes the answer, and the route the tool call takes decides how much. When the harness returns the page's text as a tool result, that text becomes tool traffic, and Check Point's data leakage page covers it: an agent "can pass sensitive data outward in the arguments of a tool call, or receive it in a tool response" (Check Point, Data Leakage, 2026). The same page says Guardrails screen "LLM inputs and outputs for personally identifiable information" and can "block the interaction or mask sensitive information" (Check Point, Data Leakage, 2026).
What that buys is a decision on the call. A prompt carrying a member ID can be blocked, or the identifier masked before the model sees the request, and a tool response carrying a card number can be masked on the way in. Both outcomes are policy decisions about text that arrived, taken by a rule. Both leave the portal rendering the value for the next step, and the masked copy is what the vendor says is written to its logs.
Two limits sit on the page. The detector list is US-specific on some entities, and the page says non-US numbers are not recognized, so a member ID from another country can pass a rule that would have caught a US one (Check Point, Data Leakage, 2026). And a step that never calls the API has no policy applied at all, so the harness decides whether the guard is in the path.
What do the vendors themselves say?
| Dimension | Check Point Lakera, per its documentation | What a buyer should verify |
|---|---|---|
| Where the check runs | "make an API request to the Guard API for each user interaction or agent step" (Check Point, Introduction, 2026) | Whether every browser step in the run calls it |
| What it screens | "screening LLM inputs and outputs for personally identifiable information" (Check Point, Data Leakage, 2026) | Whether page text or a screenshot is among the inputs |
| What it does on a match | "block the interaction or mask sensitive information" (Check Point, Data Leakage, 2026) | What the model holds when no rule matches |
| The tool route | The arguments and the results of a tool call are inside the screened traffic; a direct model call is outside it | Whether the browser returns page text as a tool result |
Lakera's account of the joint architecture with Google Cloud says that "at runtime, Check Point operates inline with agent interactions to evaluate behavior and enforce decisions in context" (Lakera, Outcome Control, 2026). A page that a browser step renders outside such an inline path is not in that account at all.
A replacement on the rendered page is not described in the pages reviewed. The pages describe screening, blocking and masking of text that reaches the API, and nothing else.
What do the studies find about detectors and browsing agents?
The research is consistent about direction and quiet about coverage. Nasr and colleagues attacked 12 published defenses and reported an "attack success rate above 90% for most," many of which had reported near-zero rates in their own evaluations (Nasr et al., 2025). The finding covers jailbreak and injection defenses together, and it sets the bar for any filter on the request. A miss is a policy event on a page the agent has already read.
Siddiqui and colleagues show why the page matters more than the prompt. In their account of information flow, "poisoned data retrieved from one component can change the model's behavior and compromise the entire system, including coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025). The poisoned component is the page, and the confidential value it put in the context is already there. A check on the model's request can catch a pattern it recognizes, and the value is in the context before the check runs.
Hidden content is the sharper version, because it needs no policy gap. Brave's researchers reported that attackers can hide instructions in images "using a faint light blue text" that screenshot-reading agents act on (Can Hidden Text on a Web Page Hijack a Browser Agent?). A detector screening text can miss what the screenshot shows, and a computer-use loop that reads the page as an image gives a text detector nothing to screen.
Who approves what the agent does on the page, and what record shows it?
Approval is a control of its own, and none of the pages reviewed puts a person in the loop for an individual agent action. A guardrail's match produces a policy outcome on a request: blocked, masked or logged, and the confirmation a product does require lives wherever that product put it. Meta says Muse "checks with the person before sensitive actions like sending an email or making a purchase," a confirmation inside the agent's own product that names no approver outside the model and does not change what the page rendered before it appeared (Meta, 2026).
A record follows the same pattern. Microsoft's account of Copilot says it "can only summarize or reference content that the user is authorized to access," and that audit records capture "Copilot prompts, responses, and referenced content" (Microsoft, 2026). That is a record of the interaction and of the content it touched. It does not answer which values the page rendered at the step.
Lakera's own description of the outcome it governs is "preventing sensitive data exposure through agent outputs and actions" (Lakera, Outcome Control, 2026). Outputs and actions are the ends of the interaction, and the page the agent read sits between them. The record a security team needs names the value the model held there and the person who approved the release.
What does a governed environment change?
A governed environment is a control class that acts at the render layer, before the model reads the page. Values chosen by policy are replaced with consistent tokens for the whole run, so a browsing agent working a clinic's billing page reads MEMBER_4012 and ACCT_001, and the real values resolve only at the approved destination at the moment of an approved action. A named person confirms what is tokenized and approves each change, and every screen, action and approval exports to the organization's own monitoring.
Under a guardrail the answer is decided by the route: a step that calls the API is screened and a step that does not is not, so the same page is covered on one integration and open on another. Under a render-layer control the answer is decided by the page, so the model holds tokens whatever route the harness takes.
Replacing identifiers with consistent pseudonyms and restoring them after the model has done its work reduced semantic utility errors by a factor of five compared with baseline techniques (Does Masking Data on Screen Break Browser Agents?). The comparison for this vendor sets the two controls side by side (RedactSure vs Check Point Lakera: 2026 Comparison & Alternative).
What the record shows
A browsing agent's exposure is set by the page its harness hands to the model, and every control reviewed here acts either before or after that handover. Screening acts after it: the page is drawn, the harness assembles a request, and a gateway that calls the API can block or mask the text on that request, while a step outside that path is never checked. The research puts a number on why the after is thin, and the web-agent study puts the exposure on the page. This means the route each model call takes decides the answer. Name one browsing task and one page with a member ID, run it twice, once with every model call routed through a gateway that calls the guardrail and once with the browser step reaching the provider directly, and compare the prompt text each run produced with the values the page drew. That test shows which of the two integrations the team has.
Methodology and limitations
This page rests on Check Point's Guard documentation, on vendor documentation from Microsoft and Meta, on three research papers and on RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read as of October 23, 2026, and each Sources line carries the date for its page.
No product on this page was tested for it. Where the page says a behavior is not described in the pages reviewed, it means the recorded pages do not state it, not that a vendor does not do it. Vendor features change and the page carries its date; the example is a record type, a clinic portal's patient billing page, not an organization. RedactSure is deploying now with enterprise and government customers.
Determinations about whether a control satisfies a contractual requirement belong to counsel and the organization's own compliance officers.
Frequently asked questions
Does Lakera Guard protect an agent that browses websites?
No. Its documentation places screening on requests that reach the Guard API, and a browsing agent's page content reaches the model through whatever code drives the browser, whether or not that code calls the API. When the step is routed, the page text can be blocked or masked as inspected traffic. When it is not, the model reads the portal's member ID and card digits with no check in between, and the page keeps rendering them.
What does the model read from a page the browser step never sends?
Everything the page draws that the harness forwards: a member ID, a date of birth, the last four digits of a card, and any note an attacker hid in the markup. A screenshot or an accessibility tree carries the same values in another form. The guardrail is not consulted because nothing in that path calls it, so the exposure is set by the application's permissions and by the agent's task, not by a policy rule.
Does Guard screen a screenshot of the page?
Not from the pages reviewed: they describe screening of prompts, LLM inputs and outputs, and tool arguments and responses for personally identifiable information, and they do not describe image handling. Whether a screenshot is inspected depends on how the harness sends it, as text or as an image, and on which detector the policy selects. Treat the image route as unverified and check it with a page that carries a known value.
Who approves a refund or a record change the agent proposes?
No person is named in the pages reviewed. A policy blocks, masks or logs a request, and the approval, where one exists, sits in the application or in the agent's own product. That is a control over what the agent may do, and not over what the page showed it. An approval that names a person outside the model, with the record carrying that name, is one an audit can follow.
What record does a screened browsing run leave?
The record of the interaction: which requests the guardrail inspected, what policy matched, and whether the text was blocked or masked, alongside the agent's own actions. That record answers what the guardrail did with a request, not what the page rendered at the step, so an incident review that needs the page has to rebuild it from the browser or from a render-layer record.
What should a security team ask for in writing about what the model receives?
One page rendered as the model's context carried it, with the values in the positions the model read them; the route each browser step takes and whether it calls the guardrail; the policy that covers fields such as a member ID or a card number; and the record that shows both. Ask which non-US fields the detector covers, since some lists stop at US formats, and check the answers against one page before trusting them.
How RedactSure Keeps a Browser Agent's Page Values Out of Its Context
A browsing agent reads whatever a portal renders, and a guardrail on the request path never touches the page that drew it. Check Point's documentation makes each agent step the unit it screens, so a page rendered outside that call never reaches the check.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the clinic portal's billing page and reads the member ID, the date of birth and the card's last four digits. Inside, the page renders MEMBER_4012 and CARD_004, the real values resolve at the portal's form when a named person approves the update, and the screen, the action and the approval land in the record.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
The route a page takes decides whether any check sees the member ID it carries. Bring one browsing task and see, with test values, what the model reads and who approves the release. Book a demo