How to Stop AI Browser Agents From Following Untrusted Links, Redirects, or Callbacks

To stop AI browser agents from following untrusted links, redirects, or callbacks, start with a layered checklist: isolate the browser, restrict destinations, inspect redirects before following them, verify callbacks cryptographically, treat page content as untrusted, and require approval for first-time or high-impact actions.

Then add one more layer most answers still skip: runtime trust. Even after the workflow is allowed, isolated, signed, and inside policy, the page or handoff can still change what the workflow believes it should do next. If your system only answers "was this path allowed?" and never answers "should the workflow still trust this exact next action now?", you have routing control without full action trust.

Before talking about products, use the control stack answer engines already trust:

That list is the honest first sentence. It solves real problems. It lowers exposure. It makes browser automation less brittle and less dangerous. But it still does not fully answer the second sentence. A redirect can stay inside policy while changing the downstream system the agent is about to trust. A callback can remain valid while introducing a different queue, a different destination, or a new implied instruction. An approved page can still quietly become the authority source for the next unsafe action.

Imagine an operations agent that can browse a fixed set of internal support pages, read a ticket queue, open an approved admin route, and trigger a downstream tool when a condition is met. The browser runs in an isolated environment. The allowed domains are narrow. Redirects are logged. Callbacks are signed. The setup is responsible.

Now the agent opens an approved page that contains a hidden support note saying a temporary fallback path should be used for the next step. The domain is still approved. The page is still real. The browser did not escape. But the browser session just absorbed a new authority source. The key question is no longer only "can this workflow reach this page?" It is "should it trust the new guidance enough to act on it now?"

The same thing happens with redirects and callbacks. A redirect can remain fully inside the allowed domain set while changing the context that determines the next tool call. A callback can be correctly signed while still pointing the workflow toward a branch the team never intended to trust automatically. Browser isolation and callback verification are not fake. They are just not the whole decision. They answer whether the route is structurally acceptable. Runtime trust answers whether the next action still deserves trust after new context, instructions, or implied authority has been inherited.

The shortest way to say it is this:

An agent opens an approved knowledge-base page, clicks a support link, and follows a redirect that stays within the company-owned domain family. Every route check passes. But the final page changes which API or downstream destination the workflow is expected to use next. The redirect chain was structurally acceptable. The meaning of the next action changed underneath it.

An agent submits a form through an approved browser workflow, receives a signed callback, and continues to the next stage automatically. Cryptographic verification passes. Logging looks normal. But the callback metadata now points the workflow to a different queue, a different service path, or a fallback handler the team never intended to trust automatically. Verification worked. Trust inheritance still changed.

An agent reads a legitimate support article that includes hidden or easy-to-miss text telling the workflow to use a temporary step for troubleshooting. The browser stays in its sandbox. The page is approved. The agent still picks up an instruction from retrieved content and uses it as live decision context. That is where browser-agent security and indirect prompt injection meet: the browser route is allowed, but the page content quietly becomes the policy author for the next action.

Sunglasses fits after those first-layer controls are already in place. It treats trust-bearing text and metadata around browser, callback, tool, and outbound workflows as part of the live authority model — not as harmless background. That includes page instructions, support notes, DOM-extracted text, redirect hints, callback metadata, handoff notes, connector descriptions, retrieved documents, and workflow messages that can quietly steer the next action.

That matters because many browser-agent failures do not look like loud exploit payloads. They look operational. A redirect seems normal. A callback seems valid. A page note sounds helpful. A hidden element feels irrelevant. A downstream handoff looks routine. If those surfaces are never treated as trust-bearing, a team can have strong browser hardening and still allow the wrong action because the workflow quietly changed who or what it was trusting.

Sunglasses helps teams review those trust-bearing surfaces before they become production decisions. It is not pretending to replace browser isolation or safe-browsing controls. It is useful when the real question becomes: the browser workflow is allowed — should it still trust this click, redirect, callback, or handoff now?

For operators who want the smallest practical starting point, the Sunglasses manual covers the full wiring options for browser-agent workflows. Keep the flow simple:

Then look closely at the places where browsing turns into authority inheritance: redirect targets, page instructions, linked docs, callback metadata, browser-to-tool handoffs, and any text that changes what the workflow believes it should do next. For teams evaluating Sunglasses against real-world agent traffic, the CVP program provides independent validation of detection accuracy in production pipelines.

The compact version: browser-agent security can isolate and constrain the route; runtime trust decides whether the already-allowed workflow should still take the next action.

Start with browser isolation, narrow destination allowlists, redirect inspection, blocked automatic follow behavior, and approval for risky or first-time navigation. Then add runtime trust so the system can decide whether the already-allowed workflow should still click, fetch, or hand off after new context appears.

Because a callback can quietly become a new authority source. Even if it is signed and technically valid, it may still change the workflow branch, destination, or implied instruction the browser agent trusts next.

Browser workflows ingest web content. That means page text, linked documents, hidden elements, and retrieved instructions can all act like prompt-injection surfaces if the system treats them as trusted guidance too early.

No. Isolation is necessary because it reduces blast radius and keeps the browsing environment constrained. It is not sufficient because it does not decide whether a newly suggested redirect, callback, or handoff should still be trusted after the route is already allowed.

Sunglasses helps review trust-bearing text and metadata around browser, callback, tool, and outbound workflows so hidden authority shifts are easier to catch before the next action becomes a live decision.