Table of contents

Quick answer: What is missing after agent link safety is runtime trust. URL allowlists, redirect controls, browser isolation, and approval gates reduce exposure — they do not decide whether the current workflow should still trust this particular next link, callback, destination, or outbound step after new context has accumulated. Sunglasses v0.2.37 ships 11 new tool_output_poisoning patterns (GLS-TOP-621 through GLS-TOP-630, plus GLS-OP-002) targeting forged tool receipts, provenance forgery, redaction drift, and order-dependent trust manipulation — the action-time decisions link safety leaves open.

Agent link safety is becoming a real buyer-facing security phrase. That matters because it means teams are no longer thinking only about prompt text or model outputs in the abstract. They are thinking about what an AI workflow does after it sees a link, receives a callback, follows a redirect, opens a support URL, pulls remote context, or hands work to another tool. That is progress.

It is also incomplete. Link filtering, safe browsing, redirect controls, URL validation, browser isolation, and approved-destination rules can narrow where an agent may go. They still do not fully answer the harder question: should the already-allowed workflow trust this next action path right now? A destination can look clean while the workflow inherits unsafe authority from callback instructions, decoded content, connector notes, retry behavior, or a quiet destination shift that no one meant to bless.

This is where Sunglasses fits. Not as a fake browser-isolation vendor. Not as a full access platform. And not as a claim that link safety does not matter. The real point is narrower and more useful: link safety narrows reach; runtime trust decides whether the workflow should still act across that link, callback, handoff, or outbound boundary now. If you already care about AI agent security fundamentals, the hardening manual, or MCP-connected tool risk, this is the next sentence your stack still needs.

The honest starting point is that link-safety controls solve real problems. They reduce drive-by browsing risk. They narrow open-ended crawling. They stop obvious malicious redirects, unapproved domains, and unsafe fetch behavior. They make it harder for an agent to wander into arbitrary infrastructure just because a document, email, or tool output mentioned a URL.

That is why the phrase is powerful. It sounds operational. Buyers understand links, redirects, destinations, and approvals faster than they understand vague claims about "secure AI." The stack is legible: URL parsing, allowlists, redirect limits, proxy mediation, browser isolation, approval for external fetches, and tighter connector policy. Those are all real security gains.

But they solve a different layer than Sunglasses does. Link safety answers where the workflow may go and under what structural conditions. Runtime trust answers whether the workflow should still believe the authority that is steering it there. Those two decisions overlap, but they are not the same. A workflow can remain inside a clean link-safety policy while still getting nudged into a bad action by content it wrongly treated as authoritative.

That distinction becomes more important as workflows get more agentic: multi-step retrieval, tool chaining, MCP handoffs, callback-heavy integrations, and coding loops that keep pulling fresh context before the next action. The safer the environment looks on paper, the easier it is to forget that the live authority model may still be drifting underneath it.

Plain-language explainer: where safe links stop and trusted action starts

Imagine an AI support workflow that can read internal documentation, look up customer state, open approved admin tools, and fetch only from a short list of sanctioned URLs. The links are filtered. Redirects are limited. High-risk requests need approval. The setup is good.

Now a user ticket contains a support article link. The article itself is on an approved domain. Inside the article, the workflow finds a note telling it to use a temporary callback URL for a migration-related step. That callback still resolves through a known provider. The request shape passes validation. Nothing looks obviously malicious. But the workflow just absorbed a new authority source. The important question is no longer only "is this domain approved?" It is "should the workflow trust this guidance enough to act on it now?"

The same thing happens in coding agents. A repository comment points to a remote document. The document points to another path. The next instruction changes which patch should be applied or which command should run. Safe setup matters. Sandboxing matters. Tool policy matters. Yet the live action can still be shaped by a trust-bearing link chain the team never meant to treat as decisive. That is exactly why link safety is necessary but not final.

The simplest version is this:

Why this matters for prompt injection and coding agents

This is not a separate problem from prompt injection defense. It is often the shape prompt injection takes after the instruction is already parsed. The attacker does not need to force the agent to visit a cartoonishly bad URL. They only need to influence how the workflow interprets the next approved link, callback, or action path.

That is why the OpenAI-style cluster around prompt-injection resistance, coding-agent safety, and agent link safety is strategically important. It teaches the market to care about the right operational surfaces. It still leaves a clean gap for Sunglasses to explain: filtering, hardening, and safer setup still do not decide whether the already-allowed workflow should take the next tool call, callback hop, patch, or outbound request now. Sunglasses v0.2.37 hardens this exactly: 11 new tool_output_poisoning patterns target the trust-bearing surfaces — forged tool receipts, postprocessor rewrites, order-dependent ranking — that decide what a workflow believes after the link already passed the filter.

For coding agents, this gap is especially sharp. A safe coding workflow may review diffs, restrict repositories, isolate execution, and route outbound actions through approved tooling. That is excellent hygiene. But a code comment, issue text, fetched artifact, or linked runbook can still quietly reshape what the agent believes it should do next. Safe operation is not only about where the agent can run. It is about what the workflow is trusting at the moment it acts.

Three concrete attack examples

1) Approved destination, unsafe callback authority

An agent follows an approved help-center link and receives callback guidance telling it to use a migration endpoint for the next step. The endpoint still sits behind a familiar provider and passes domain checks. The real change is that the callback text just became the new authority source for the action. Link safety did not fail. The trust boundary moved. The tool_output_poisoning category — specifically the GLS-TOP-623 (Tool Output Shadowing) pattern shipped in v0.2.37 — targets the prefix/role forgery that lets callback text impersonate authoritative tool output.

2) Clean redirect chain, dirty destination meaning

A redirect stays inside the allowed policy shape. The hostname looks normal. The browser or fetch stack sees no obvious problem. But the meaning of the destination changed: a backup route, a new path, or a delegated service is now effectively steering the workflow. The link remained structurally safe. The workflow's decision basis did not. GLS-TOP-626 (Tool Result Provenance Forgery) catches the kind of forged executor identity and freshness-token replay that makes a redirected destination look like a legitimate authority signal.

3) Coding-agent fetch turns into action steering

A coding agent pulls a linked document, then uses its instructions to choose a patch, a command, or an outbound request. Repository permissions may still be correct. Execution may still be sandboxed. The agent can still be operating inside a narrow environment. But the fetched content just influenced the next live action. The critical question is no longer just "was the document reachable?" It is "should the workflow trust the newly inherited guidance enough to execute now?" GLS-TOP-625 (Tool Output Redaction Drift) targets a sharp form of this: placeholders or masked snippets treated as canonical on-disk values, causing the next action to write garbage where real config was expected.

How Sunglasses catches it

Sunglasses fits this stack as a provider-agnostic runtime-trust layer. It treats ordinary-looking text and metadata as part of the live authority model around an agent workflow. That includes prompts, YAML, tool descriptions, callback instructions, connector notes, policy fragments, issue text, pull-request context, fetched docs, retry guidance, and other content that can quietly steer a workflow after the first permissions decision already passed. The how-it-works page walks through the three-stage pipeline; the CVP runs show the same trust-boundary logic evaluated against Claude's own runtime decisions.

That is useful precisely because many real failures arrive wrapped in convenience rather than obvious exploit code. A redirect looks operational. A linked doc looks helpful. A callback feels like plumbing. A retry note sounds like resilience. A fetched coding guide looks normal. If those surfaces are never treated as trust-bearing, a team can have solid link filtering and still let the wrong action happen.

Sunglasses helps teams inspect those surfaces before they become production decisions. It is not pretending to replace gateway policy, browser isolation, or link filtering. It is useful at the moment a team needs to ask: the route is allowed, but should the workflow still trust this action path now?

For teams that want the smallest practical starting point, the path stays simple:

pip install sunglasses
sunglasses scan <path>

Then look closely at the places where link-following becomes authority inheritance: callback notes, redirect logic, fetched docs, issue text, endpoint-selection guidance, connector metadata, and the trust-bearing text that sits between one approved action and the next one. The FAQ covers the most common adoption questions.

Operator checklist: safer links for AI agents

The short version: safe links reduce exposure; runtime trust decides whether the workflow should still act.

Related reading