AI Agent Web Search Leaks Data to Search Engines: What Goes Out

Yes. When an AI agent runs a web search or fetches a URL, the query text, and anything the model copied into it such as names, emails, customer details, internal hostnames, ticket text or code, leaves your environment. It goes to the search provider and to every site fetched, and each of them logs it under its own retention policy, not yours.

That is not a bug in any one product. A search engine cannot answer a question it never receives, and a website cannot serve a page without seeing the request. The risk is what the model decides to put in that request. This guide covers what goes out, who sees it, what providers say about retention in their own documentation, how prompt injection turns search into a leak, what GDPR, CCPA and HIPAA expect, and the controls that work.

Key takeaways

• Every agent search sends a query the model wrote, and every fetch sends a full URL with its parameters. Both can carry personal data the model lifted from your conversation.
• The model provider, the search engine behind the tool, each fetched site and the CDNs in front of it can all see that request.
• Zero data retention with your model provider does not extend to third parties. Anthropic's documentation says website publishers "might retain any parameters passed to the URL" even in a ZDR-eligible setup. OpenAI says data sent to third-party services "is subject to their data retention policies."
• Google states that Grounding with Google Search stores queries derived from end user prompts for up to three days, and "there is no way to disable" it. Microsoft states that Grounding with Bing Search moves the search query outside the Azure compliance boundary.
• Indirect prompt injection, ranked LLM01 in the OWASP Top 10 for LLM Applications 2025, can steer an agent into writing private data into a query or URL. Sensitive information disclosure is LLM02.
• GDPR data minimisation, HIPAA minimum necessary and CCPA's proportionality rules all apply to what your agent sends to a search engine.
• Controls that work: web tools off unless needed, domain allow lists, redaction before the tool call, an egress proxy you control, logged tool inputs, and separate agents for sensitive data.

What actually leaves your environment when an agent searches

On the wire, an agent search is an ordinary request to someone else's server, and every field in it is visible to a third party.

The query string the model wrote

With a search tool, the model writes the query. Anthropic's web search documentation shows it in the response as a server_tool_use block whose input contains the query text. The model builds that string from whatever is in its context: the user's question, the system prompt, documents you attached, and the results of earlier tool calls.

That is where accidental disclosure starts. Ask an agent "why did customer Jane Doe's invoice INV 20391 fail with error E-17 on our billing host" and a helpful model may search for most of that sentence. The search provider now has a customer name, an invoice number and possibly a hostname. Nothing malicious happened; the model was trying to be precise.

URLs and their parameters

A fetch tool sends a full URL. The path and query parameters reach the destination site, its logs and any CDN or reverse proxy in front of it. An email address or order number in a query string now sits in someone else's access log. Anthropic's own server tools page warns: "Even when web fetch is used in a ZDR-eligible configuration, website publishers might retain any parameters passed to the URL if Claude fetches content from their site."

Headers, IP address and user agent

Every HTTP request carries a source IP, a user agent, language headers, and sometimes cookies or authorization headers. Where that metadata points depends on who runs the tool:

• Server-side tools run by the model provider. Anthropic describes web search and web fetch as server tools: "the API fetches the content during the request and inserts the results into the conversation." The destination sees a request made from the provider's systems, not directly from your office network, but it still sees the full query or URL.
• Client-side tools you build, such as a fetch_url function. The request leaves from your network with your IP address and whatever headers your HTTP library sends by default.
• Browser-based agents can carry the browser's cookies and signed-in sessions with every request.

Location hints and parameters you set

Anthropic's web search tool takes an optional user_location (city, region, country, timezone), OpenAI's accepts an approximate location, and Microsoft's Bing grounding tool takes market and set_lang. Each is another fact about your user passed to a search provider. Set them only when the task needs them.

Who can see the query, and for how long

Here is the chain for a typical agent search and fetch, and where each party's retention terms come from.

Below is what each provider's own documentation says on the date reviewed. These are summaries, not comparisons, and terms change.

Anthropic: web search and web fetch tools

Anthropic's web search documentation says "Claude determines when to search based on the prompt" and "The API runs the searches and provides Claude with the results," possibly several times per request. Its API and data retention page says "Conversation content (your prompts and Claude's outputs) is not retained by default," except for listed Covered Models that require 30 day retention, and that retained data "is never used for model training without your express permission." Its feature eligibility table lists:

• Web search: eligible for zero data retention (ZDR) and for HIPAA readiness. Dynamic filtering for web search "is not eligible for ZDR or HIPAA."
• Web fetch: eligible for ZDR but not for HIPAA readiness. The table adds: "Website publishers might retain request data (such as fetched URLs and request metadata) according to their own policies."

The server tools page explains the exception: _20260209 and later versions filter results with code execution, which is stateful. Setting "allowed_callers": ["direct"] "restricts the tool to direct calls only, bypassing the internal code execution step," which keeps them ZDR eligible.

The retention page also says ZDR does not cover "Data processed by third-party websites, tools, or other integrations," and that if content is flagged by automated trust and safety systems, Anthropic "may retain inputs and outputs for up to 2 years." Web search is "enabled for your organization unless an administrator has disabled it in the Claude Console," and admins can turn off web fetch and set domain lists on the same Capabilities page.

OpenAI: web search tool and data controls

OpenAI's web search guide says the model decides whether to search, and documents two controls:

• A filters parameter that can hold "up to 100 allowed_domains or up to 100 blocked_domains."
• An external_web_access setting. Setting it to false runs the tool in an offline, cache-only mode; the default is live access.

OpenAI's data controls page says "data sent to the OpenAI API is not used to train or improve OpenAI models" unless you opt in, and "abuse monitoring logs are generated for all API feature usage and retained for up to 30 days." Zero Data Retention needs prior approval. It also says "Web Search with live internet access is not HIPAA eligible and is not covered by a BAA," and "Data transmitted to third-party services over network connections is subject to their data retention policies."

Google: Grounding with Google Search on Vertex AI

Google bills "for each search query that is generated by Gemini and sent to Search," the same pattern again. Its Vertex AI zero data retention page is direct about logging. Under Grounding with Google Search, it says Google "collects and stores logs" containing "queries derived from End User prompts and contextual information that Customer may provide along with the prompts" for up to three days, used "for debugging of systems that support Grounding with Google Search." It adds: "There is no way to disable the storage of this information if you use Grounding with Google Search. If you require zero data retention, we recommend using Web Grounding for Enterprise."

The same page says Grounding with Google Maps stores prompts, context and output for thirty days, also with no way to disable it.

Microsoft: Grounding with Bing Search in Foundry agents

Microsoft's documentation for Grounding with Bing Search in Foundry Agent Service says "only the Bing search query, tool parameters, and your resource key are sent to Bing, and no end user-specific information is included," and that the resource key is sent "solely for billing and rate limiting purposes."

It also states that "your customer data is transferred outside of the Azure compliance boundary to the Grounding with Bing Search service," that the service "is not subject to the same data processing terms (including location of processing)," and that "It is your responsibility to assess whether use of Grounding with Bing Search in your agent meets your needs and requirements."

Note the gap. The platform adds no user identifiers, but the model writes the query; if it copies a customer's name in, that name crosses the boundary.

What the providers agree on

The documentation lines up on three facts: the model writes the query and it goes to a search service; your model provider's promises, including ZDR, do not bind that service or fetched sites; and fetched sites keep URLs under their own policies. The reliable control point is before the query is sent.

How prompt injection turns a search tool into an exfiltration channel

Accidental disclosure is common. The deliberate case is worse: someone plants instructions in content your agent reads.

The pattern, without the payload

OWASP's Top 10 for LLM Applications 2025 lists prompt injection as LLM01. It defines it as a vulnerability that "occurs when user prompts alter the LLM's behavior or output in unintended ways," and separates two forms. Direct injection comes from the user. "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files."

Web tools are the textbook source of indirect injection. NIST AI 600-1, the Generative AI Profile published in July 2024, describes the same thing: indirect attacks happen when adversaries "exploit LLM-integrated applications by injecting prompts into data likely to be retrieved," and it notes that researchers "have already demonstrated how indirect prompt injections can exploit vulnerabilities by stealing proprietary data."

The exfiltration step works like this, at a conceptual level:

1. The agent has something sensitive in its context: a document, a customer record, a code snippet, an earlier tool result.
2. It reads a web page, email or file that contains hidden instructions.
3. The instructions ask it to take the sensitive value and place it inside an outbound request: a URL to fetch, an image link for the chat interface to render, or a search query.
4. The request leaves. Whoever controls the destination reads the value out of their logs.

OWASP's own example is a summarizer that reads a page with hidden instructions and inserts an image link to an attacker's URL, leaking the conversation when the image loads. The lesson is the shape: any free-text field that leaves your network is a channel, and the model fills it in.

Why the search query is a channel even with fetch restrictions

Anthropic built a specific defence into its web fetch tool. Its documentation says: "Claude cannot fetch URLs that appear only in its own output. Claude can only fetch URLs that have previously appeared in the conversation." It also refuses "a URL that appears to contain a credential, such as an API key or a password, unless that credential appears in the system prompt or in the text of a user message." That blocks the simplest version of step 3, where the model invents a new URL with data appended.

Anthropic is clear that this is not the end of the matter: "there is still residual risk that you should carefully consider when using this tool." Its warning box opens with: "Enabling the web fetch tool in environments where Claude processes untrusted input alongside sensitive data poses data exfiltration risks."

Two residual paths apply to any provider:

• The search query itself. A query is free text by design. An injected instruction that gets the model to search for a sensitive string sends it to the search provider. The attacker usually cannot read those logs, but it is still your data in someone else's logs.
• Tools you built. The URL rules above apply to Anthropic's server-side fetch tool. A client-side HTTP tool, browser automation tool or MCP server that makes outbound requests has whatever rules you gave it, often none.

OWASP's LLM02:2025, Sensitive Information Disclosure, covers the outcome: "Personal identifiable information (PII) may be disclosed during interactions with the LLM." Its mitigations include input validation "to detect and filter out potentially harmful or sensitive data inputs" and access controls that "limit access to sensitive data based on the principle of least privilege," including limiting model access to external data sources.

What the regulations expect

None of these laws names AI web search, but a query containing personal data is a disclosure to a third party. This is general information, not legal advice.

GDPR: data minimisation, processors and by default

Article 5(1)(c) of the GDPR requires that personal data be "adequate, relevant and limited to what is necessary" for the purposes of processing. A search query that includes a customer's full name and account number, when the task only needed a product error code, fails that test.

Article 28 requires controllers to use only processors giving sufficient guarantees, and bars processors from engaging another processor without the controller's prior written authorisation. A search engine your model provider calls may not be a processor under your contract at all; Microsoft says Grounding with Bing Search "is not subject to the same data processing terms" as the agent service. Data sent to an independent party needs its own lawful basis.

Article 25(2), data protection by default, is the most practical hook. The European Data Protection Board's Guidelines 4/2019 on Article 25 restate the requirement that "by default, only personal data which are necessary for each specific purpose of the processing are processed." Web search switched on for every agent, for every task, is the opposite of a privacy-protective default.

If queries are processed outside the EEA, the Chapter V transfer rules apply too.

CCPA and CPRA

The California Attorney General's CCPA page explains that the CPRA "amends the CCPA; it does not create a separate, new law," and lists consumer rights including "The right to limit the use and disclosure of sensitive personal information." It describes sensitive personal information as "a specific subset of personal information that includes certain government identifiers," along with items such as financial account credentials, precise geolocation and genetic data.

The statute requires collection, use, retention and sharing of personal information to be reasonably necessary and proportionate to the purpose, which convenience searches with customer data struggle to meet. The page also notes "The CCPA treats service providers differently than the businesses they serve," and a search engine reached through a tool is not automatically your service provider.

HIPAA: minimum necessary

HIPAA's minimum necessary standard, at 45 CFR 164.502(b), says that when using or disclosing protected health information, a covered entity or business associate "must make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request." The exceptions are narrow, such as disclosures to a provider for treatment.

A clinical agent that searches with a patient's name or diagnosis in the query discloses PHI to a party that usually has no business associate agreement with you. OpenAI says live web search "is not HIPAA eligible," and Anthropic's table marks web fetch as outside HIPAA readiness while listing web search without dynamic filtering as eligible. The query still reaches a search service either way, so the safe rule is that PHI never appears in a query.

NIST AI 600-1

NIST's Generative AI Profile lists Data Privacy as one of its twelve risks: "Impacts due to leakage and unauthorized use, disclosure, or de-anonymization of biometric, health, location, or other personally identifiable information or sensitive data." It also warns that models can "correctly infer PII or sensitive data that was not in their training data nor disclosed by the user by stitching together information from disparate sources." Agents with web search stitch in both directions.

Decision table: what may go into an agent's web query

Use this as a starting policy. Adjust the middle column to your own data classification scheme.

The rule behind the table: the search engine only needs the technical question. It almost never needs to know whose problem it is.

Controls that work

Layer these from cheapest to most involved.

1. Turn web tools off where they are not needed

Summarising a document, drafting a reply or refactoring code rarely needs live web access. On the Anthropic API, an admin can disable web search or fetch for the organization; requests that include a disabled tool then fail with a 400 error. Make tools opt-in per agent in your own framework too.

2. Allow-list domains, and know how matching works

• Anthropic's web search and fetch tools accept allowed_domains or blocked_domains, not both. Subdomains are included automatically; web search supports paths, but "Web fetch matches on the domain only." Wildcards are allowed only in the path. Request-level allow lists must be a subset of the organization-level list set in the Console.
• Anthropic's documentation also warns that "Unicode characters in domain names can bypass domain filters through homograph attacks" and recommends ASCII-only entries.
• OpenAI's web search tool accepts up to 100 allowed or blocked domains through filters.

An allow list limits where the agent reads. It does not stop the query from going to the search provider.

3. Cap the number of calls

Anthropic's tools accept max_uses; for web fetch "There is currently no default limit," so set one. It also limits how far an injected instruction can push an agent in one turn.

4. Restrict where fetchable URLs may come from

Anthropic's url_sources parameter can set client_tool_results to none, so URLs that appear only in your tools' output, which may echo text the model wrote, cannot be fetched. Anthropic lists it among mitigations "If data exfiltration is a concern."

5. Redact personal data before the tool call

The model writes the query from its context, so keep sensitive values out of that context or replace them with placeholders first. Detection is never perfect; treat it as one layer.

6. Route agent traffic through an egress proxy you control

Force client-side tool traffic through a proxy that enforces an allow list and logs requests. Server-side tools do not cross your network, so there your controls are provider settings plus anything you enforce before the API call.

7. Log every tool input

Every query and fetched URL should land in a log you own, tied to user, session and agent. Anthropic's responses include each server_tool_use block with its input.

8. Separate agents by data sensitivity

OWASP's LLM01 guidance calls for least privilege and human approval of high-risk actions. Run a research agent with web access and no customer data, and a records agent with customer data and no web access.

9. Ask before searching on sensitive context

Show the proposed query and ask before sending it. Users spot a customer's name in a query quickly.

Step by step: lock down an agent's web tools

The examples below are configuration, not exploits. Adapt names and domains to your environment.

Step 1: Inventory which agents have web tools

List every agent, its tools and its data sources. If an agent does not need live web access, remove the tool.

Step 2: Configure the Anthropic web tools narrowly

This request enables search and fetch, limits both to a small set of documentation domains, caps calls, stops URLs from client tool output counting as fetch sources, and keeps search on the direct call path that Anthropic documents as ZDR eligible.

{
  "model": "claude-opus-5-5",
  "max_tokens": 2048,
  "tools": [
    {
      "type": "web_search_20260209",
      "name": "web_search",
      "allowed_callers": ["direct"],
      "max_uses": 3,
      "allowed_domains": ["docs.python.org", "nodejs.org", "developer.mozilla.org"]
    },
    {
      "type": "web_fetch_20250910",
      "name": "web_fetch",
      "max_uses": 3,
      "allowed_domains": ["docs.python.org", "nodejs.org", "developer.mozilla.org"],
      "url_sources": { "client_tool_results": { "type": "none" } },
      "max_content_tokens": 20000
    }
  ],
  "messages": [
    { "role": "user", "content": "How do I set a timeout on urllib.request.urlopen?" }
  ]
}

Leave user_location out unless needed, and set the organization-level allow list in the Console so no request can widen it.

Step 3: Configure OpenAI web search narrowly

In the Responses API, domain filtering goes in filters:

{
  "tools": [
    {
      "type": "web_search",
      "filters": {
        "allowed_domains": ["docs.python.org", "nodejs.org"]
      }
    }
  ]
}

Where cached results are enough, OpenAI documents external_web_access: false for an offline, cache-only mode; the guide says web_search_preview ignores it.

Step 4: Redact before the agent sees the text

This simple filter replaces common identifiers with placeholders before text reaches a web-enabled agent. Pattern matching misses names and free text, so pair it with classification or a human check for high-risk workflows.

import re

PATTERNS = {
    "EMAIL": re.compile(r"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}"),
    "PHONE": re.compile(r"\+?\d[\d\s().-]{8,}\d"),
    "US_SSN": re.compile(r"\b\d{3}-\d{2}-\d{4}\b"),
    "CARD": re.compile(r"\b(?:\d[ -]?){13,19}\b"),
    "IPV4": re.compile(r"\b(?:\d{1,3}\.){3}\d{1,3}\b"),
    "INTERNAL_HOST": re.compile(r"\b[a-z0-9-]+\.(?:internal|corp|local)\b", re.I),
}

def redact(text: str) -> tuple[str, dict]:
    found = {}
    for label, pattern in PATTERNS.items():
        def _sub(match, label=label):
            key = f"[{label}_{len(found) + 1}]"
            found[key] = match.group(0)
            return key
        text = pattern.sub(_sub, text)
    return text, found

safe_text, mapping = redact(user_ticket_text)
# Send safe_text to the web-enabled agent.
# Keep mapping on your side if you need to re-insert values in the final answer.

Never send the mapping dictionary to the model. Re-insert real values only in your own code, after the agent's web work is finished.

Step 5: Log every query and URL the model sent

With the Anthropic API, server tool calls appear in the response content. This snippet pulls each search query and fetched URL into your audit log.

import json, logging

audit = logging.getLogger("agent.egress")

def log_server_tool_calls(response, session_id: str, user_id: str):
    for block in response.content:
        if block.type == "server_tool_use" and block.name in ("web_search", "web_fetch"):
            audit.info(json.dumps({
                "session": session_id,
                "user": user_id,
                "tool": block.name,
                "tool_use_id": block.id,
                "input": block.input,   # {"query": ...} or {"url": ...}
            }))

Sample these logs, alert on patterns that look like personal data, and keep them under your own retention policy.

Step 6: Force client-side tool traffic through an allow-list proxy

A minimal Squid configuration that allows a few documentation domains and denies everything else:

# /etc/squid/squid.conf (excerpt)
acl agent_hosts src 10.20.0.0/24
acl docs_sites dstdomain .python.org .nodejs.org .mozilla.org
http_access allow agent_hosts docs_sites
http_access deny all

# Log full requests for audit
access_log daemon:/var/log/squid/agent_access.log squid

Block direct outbound traffic from agent hosts at the firewall so the proxy is not optional, and point the agent's HTTP client at it:

export HTTPS_PROXY=http://egress-proxy.example.net:3128
export HTTP_PROXY=http://egress-proxy.example.net:3128
export NO_PROXY=localhost,127.0.0.1

For HTTPS, a plain forward proxy sees the host but not the path or query string. Inspecting those needs TLS inspection, which brings its own key management and privacy obligations.

Step 7: Split agents and add approval

If a workflow needs both data and the web, have the records agent produce a sanitised technical question, show it to a human, and pass only that to the research agent.

Step 8: Test it

Run tickets with fake names, emails and invoice numbers, plus a test page you control with a benign instruction to include the user's email in the next search. If a fake identifier shows up in any logged query or URL, a layer failed.

Where Safeguard fits, honestly

Safeguard is a software supply chain security platform. Most of the controls above are provider settings and your own architecture, and they work without us.

Three Safeguard capabilities are relevant, and all three are early access today, so treat them as available to evaluate rather than as finished products. The AI Gateway, an LLM firewall, runs as a guardrail proxy and can sit on the egress path of agent tool traffic; it includes PII egress guardrails and indirect prompt injection checks, and it runs in monitor mode by default, with enforce mode as an explicit choice. MCP Guardrail generates guardrail proxy URLs for MCP servers, so agent tool calls to those servers pass through a governed path instead of going direct. DSPM classifies PII, PHI and PCI data in connected data stores, which helps you decide which data sources should never be reachable by a web-enabled agent. None of these replaces the provider settings above, and none can see a server-side search that your model provider runs on its own infrastructure. If you are evaluating them, ask which agent frameworks and MCP servers are covered in your environment.

Common mistakes

• Assuming ZDR covers the search engine. ZDR is an arrangement with your model provider. Anthropic, OpenAI and Google all say, in different words, that third parties keep their own logs.
• Treating a domain allow list as a privacy control for queries. It controls where the agent reads. The query still goes to the search provider.
• Giving one agent customer data and open web access. That is the setup indirect prompt injection needs. Split them.
• Building a custom fetch tool with no URL rules. Provider-side protections such as "only fetch URLs already in the conversation" do not apply to tools you wrote.
• Not logging tool inputs. Without logs you cannot answer a regulator's or customer's question about what was sent.
• Forgetting dynamic filtering's retention profile. On the Anthropic API it is not ZDR or HIPAA eligible; set allowed_callers to ["direct"] when that matters.
• Relying on the model to "be careful." OWASP notes no prevention method is foolproof. Put hard controls outside the model.

FAQ

Does ChatGPT or Claude web search send my data to Google or Bing?

It sends a query the model wrote to whatever search service the tool uses. Anthropic's and OpenAI's tool docs reviewed here do not name that service; Google's and Microsoft's grounding tools send it to Google Search and Bing. Either way, it reaches a search service with its own logs.

Can search engines keep the queries my AI agent sends?

Yes. Google's Vertex AI documentation says Grounding with Google Search stores queries derived from end user prompts for up to three days and that storage cannot be disabled. Microsoft says Bing grounding moves the query outside the Azure compliance boundary under Bing's terms. Fetched websites keep URLs under their own policies.

Does zero data retention stop web search data from being stored?

Only on the model provider's side. Anthropic says ZDR does not cover data processed by third-party websites, tools or integrations, and that publishers may keep URL parameters. OpenAI says data sent to third-party services follows their retention policies.

What is the difference between web search and web fetch for privacy?

Search sends a query to a search provider. Fetch sends a full URL, parameters included, to the site and anything in front of it, and brings page content into context, where indirect prompt injection comes from.

Can a malicious website make my AI agent leak data?

It can try, through indirect prompt injection (OWASP LLM01). Protections such as Anthropic's rule that web fetch only uses URLs already in the conversation reduce this, but Anthropic says residual risk remains.

Is it GDPR compliant to let an AI agent search the web with customer data?

It has to meet data minimisation under Article 5(1)(c), needs a lawful basis, and may involve a third party that is not your processor. Article 25(2) points toward web tools being off unless needed. Ask counsel to review your setup.

Can I use AI web search with patient data under HIPAA?

Keep PHI out of web queries entirely. Minimum necessary applies, OpenAI says live web search is not HIPAA eligible, and the search service receiving the query is a separate party even where the model provider's side is covered.

How do I restrict which websites my AI agent can visit?

Use allowed_domains on Anthropic's web tools (plus the Console list) or filters on OpenAI's web search tool. For your own tools, enforce an allow list at an egress proxy.

How do I see exactly what my agent searched for?

On the Anthropic API, each search or fetch appears as a server_tool_use block with its input. OpenAI documents a sources field listing URLs retrieved. For your own tools, log at the proxy.

Should I turn off web search for internal AI agents?

For agents handling customer, health or financial data, yes, unless a task needs it. Use a separate research agent and pass it only sanitised questions.

Fix it without waiting for upstream

AI agents are built from open source: SDKs, HTTP clients, MCP servers, HTML parsers and the frameworks that wire them together, and a flaw in any of them can widen the egress path described above. Keeping those components at fixed, current versions is part of keeping an agent's web traffic under control.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos shows a web search guardrail. They show the principle behind this guide: an agent gets only the tools it needs, and a person approves what it does. To try the CLI, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

The first demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. That selection step is least privilege in practice: the agent gets the tools a task needs, and you can see and change the list.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. Asked to fix the lodash CVE in a repo, it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. Those approval prompts are the human-in-the-loop pattern OWASP recommends for high-risk agent actions. You can read more about the assistant in the Safeguard CLI as a security aware coding assistant.

Click through it at your own pace, or open it full screen.

The third demo shows the desktop app sending work to a computer running the CLI, with each command approved before it runs. Keeping the decision with a person at the moment of action is the simplest control on what an agent sends out.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Anthropic: Web search tool
• Anthropic: Web fetch tool
• Anthropic: Server tools (ZDR, allowed_callers and domain filtering)
• Anthropic: API and data retention
• OpenAI: Web search guide
• OpenAI: Data controls in the OpenAI platform
• Google Cloud: Grounding with Google Search
• Google Cloud: Vertex AI and zero data retention
• Microsoft Learn: Grounding with Bing Search in Foundry Agent Service
• OWASP GenAI: LLM01:2025 Prompt Injection
• OWASP GenAI: LLM02:2025 Sensitive Information Disclosure
• NIST AI 600-1: Generative AI Profile
• EUR-Lex: Regulation (EU) 2016/679 (GDPR)
• EDPB: Guidelines 4/2019 on Article 25, Data Protection by Design and by Default
• California Attorney General: California Consumer Privacy Act
• eCFR: 45 CFR 164.502, uses and disclosures of protected health information

Last reviewed: 23 October 2026. Provider tool settings and retention terms change; check the linked documentation for the latest wording.