OpenAI’s link-safety update prevents agents from automatically fetching unverified URLs that could conceal private data in query strings. Agents fetch links only if they already exist on the public web (per an independent crawler index); otherwise users see a warning and can choose whether to proceed.

The specific risk: URLs can exfiltrate data

When an agent loads a link, the full URL (including query parameters) is sent to the destination and often logged. Attackers can prompt an agent to include sensitive context—like an email or doc title—in that URL, creating a silent leak (even via redirects, images, or previews).

Why simple allow-lists aren’t enough

Allow-listing “trusted sites” fails when those sites redirect or embed third-party content; it also creates friction that users learn to ignore. OpenAI instead targets the URL itself: is this exact address already public?

The control: only auto-fetch public URLs

OpenAI uses an independent web index (separate from user conversations) to verify whether a URL is publicly known.

• Match found: agent can load automatically.

• No match: agent avoids auto-fetch; users may see a warning and choose to proceed or ask for alternatives.

What users will see

For unverified links, ChatGPT can display a “Check this link is safe” dialog: “not verified,” “may include information from your conversation,” and options to copy or open anyway. This makes the “quiet leak” visible and keeps the human in control.

What this does—and doesn’t—cover

This defence focuses on URL-based exfiltration. It doesn’t guarantee page trustworthiness or remove all prompt-injection risks, so OpenAI layers it with model-level mitigations, product controls, monitoring and red-teaming as part of a defence-in-depth approach.

Implications for builders and security teams

• Reduce silent leaks: Adopt a similar “public-URL-only auto-fetch” policy in custom agents and instrument warnings for unverified links.

• Harden against injections: Pair link-safety with prompt-injection mitigations and guided tool-use patterns in Agent Builder/AgentKit.

• Balance UX and safety: Keep users informed without blocking legitimate browsing; use human-in-the-loop for high-risk actions.

• Evolve your guardrails: Treat agent safety as an ongoing programme—add controls as you observe new evasion attempts.

Bottom line: Link safety doesn’t replace other controls, but it removes a common, subtle path for context leakage—and sets a strong default for agent browsing.

FAQ

Q1. What is URL-based data exfiltration in agents?
When an agent loads a link that embeds private context in the URL’s query string, that data can be logged by the destination—leaking information silently.

Q2. How does OpenAI’s link safety work?
Agents auto-fetch only URLs previously observed on the public web by an independent crawler. Unverified links trigger a user warning before opening.

Q3. Does this stop prompt injection?
It reduces one prompt-injection outcome (forced URL fetch with secrets), but broader injection risks remain and are mitigated via model-level and product safeguards.

Q4. What should developers copy from this?
Implement public-URL verification, explicit warnings, and human approval for risky actions; combine with established safety best practices and HITL.

Q5. Is this available in ChatGPT today?
OpenAI describes this as a shipped safeguard for ChatGPT/agentic experiences and indicates it will continue to evolve as attackers adapt.