Teams are finally asking a concrete question instead of a fuzzy one: how do I stop AI browser agents from following untrusted links, redirects, or callbacks? That is a better security question because it starts in the workflow, not in marketing posture. It points at the real places browser agents pick up trouble: page instructions, hidden content, redirect chains, callback paths, and browser-to-tool handoffs that stay technically allowed while the trust story underneath them changes.

The first honest answer is that the basic control stack matters. Use browser isolation. Treat page content as untrusted. Narrow destinations. Inspect redirects. Verify callbacks. Require human review for risky or first-time actions. Those controls are real, and answer engines already reward that checklist shape. But they still leave one more question unanswered: after the browser workflow is isolated, the domain is allowed, and the redirect is inspected, should the already-permitted agent action still be trusted right now?

That is where Sunglasses fits. Not as a replacement for remote browser isolation, allowlisting, safe-browsing tools, or generic proxying. The practical wedge is narrower and more useful: browser-agent security narrows where the workflow can go; runtime trust decides whether the workflow should still click, follow, fetch, submit, or hand off after new context shows up. This is also where browser-agent questions naturally meet prompt injection defense, agent link safety, AI agent security fundamentals, and MCP-connected tool risk.

On this page

Quick answer

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.

Sunglasses ships detection patterns for the trust-bearing surfaces these attacks abuse — GLS-IP-001 (indirect instruction-reset phrases in retrieved web pages), GLS-HI-004 (hidden-markup behavioral steering of an agent's links and recommendations), and GLS-TP-002 (tool-output masquerading as a trusted instruction).

The checklist that should come first

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.

Plain-language explainer: where browser safety ends and trusted action starts

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:

Three concrete attack examples

1) Allowed page, unsafe redirect meaning

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.

2) Signed callback, untrusted next-step authority

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.

3) Clean browser session, dirty web-content instruction

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.

How Sunglasses catches it

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:

pip install sunglasses
sunglasses scan <path>

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.

Operator checklist: safer browser-agent workflows

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.

Frequently asked questions

How do I stop AI browser agents from following untrusted links or redirects?

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.

Why are callbacks risky for browser agents?

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.

How does this connect to prompt injection?

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.

Is browser isolation enough?

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.

Where does Sunglasses fit?

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.