ChatGPT Search Now Uses the site: Operator at Scale — What Defenders Must Do About AI-Driven Site Enumeration

In August 2026, Promptwatch — a Generative Engine Optimization (GEO) vendor that automates tracking of responses across ChatGPT, Claude, and Gemini — published aggregate data showing a notable behavioral change in ChatGPT search aligned with the GPT-5 rollout: the product is now issuing site: operator queries at scale when fulfilling user prompts. On the surface, this is a search-engine mechanics story. For defenders, it is an attack-surface story.

When a consumer AI product can programmatically constrain retrieval to a specific domain — and does so routinely, invisibly, and at scale — every piece of content your organization exposes to the public web becomes queryable, extractable, and summarizable through an interface you do not control, with none of the logging, rate limiting, or DLP enforcement you have on your own perimeter. Worse, because retrieval is mediated by a large language model, your indexed content is now an injection vector: anything an attacker can get into your indexed pages (or into pages ChatGPT retrieves alongside yours) can influence what the model tells your employees, customers, and competitors.

This is not a vulnerability with a CVE. There is no patch. The exposure is architectural, and it demands an architectural response.

Technical Analysis

What changed

Per Promptwatch's tracking, ChatGPT search's query fan-out behavior — the sub-queries the model issues behind the scenes when answering a prompt — now heavily features the site: operator. Previously, site:-scoped retrieval appeared to be an occasional tactic; the new data suggests it has become a systematic part of how GPT-5-era ChatGPT search narrows retrieval to authoritative domains.

Key implications of that design shift:

• Domain-scoped extraction is now a first-class capability. A user (or an automated workflow) can steer ChatGPT to mine a specific domain's public content far more effectively than before. Competitive intelligence gathering, personnel reconnaissance, and technology-stack fingerprinting against your web properties just got cheaper and more reliable.
• Retrieval happens server-side, inside OpenAI's infrastructure. Your WAF, CDN bot rules, and rate limiters see the crawler (OAI-SearchBot / ChatGPT-User), but the querying — the actual enumeration logic — happens after ingestion. Traditional web-layer controls do not govern how indexed content is later sliced by site: queries.
• The model is the new reader. Content is not just listed; it is interpreted, summarized, and blended with other sources. Errors, outdated pages, staging content, and inadvertently public documents will be confidently paraphrased to users with no link guarantee and no correction mechanism you control.

Threat model from a defender's perspective

Three concrete abuse scenarios follow directly from this change:

1. Accelerated reconnaissance (MITRE ATT&CK T1593 — Search Open Websites/Domains). Adversaries already scrape target domains; site: fan-out at scale means the AI does the scraping and the analysis. Expect pre-attack recon against your documentation portals, career pages (which leak your tech stack via job reqs), and help-center content to be more thorough.
2. Indirect prompt injection via indexed content. If an attacker can plant content on pages ChatGPT retrieves — compromised third-party sites, SEO-poisoned pages, or even user-generated content on your domain (forums, comment sections, wiki pages) — that content can steer model output. With site: scoping, an attacker who poisons one page on your domain can influence answers that users believe are authoritative summaries of your site.
3. Exposure of inadvertently public data. Staging subdomains, legacy documentation, PDF metadata, directory listings, and forgotten microsites are all fair game for domain-scoped retrieval. If it is indexable, it is now conversationally queryable.

Exploitation status

There is no CVE, no in-the-wild exploit chain, and no CISA KEV entry associated with this change — it is a product design behavior, not a software flaw. The risk is realized through misuse of intended functionality and through the well-documented indirect prompt injection class of attacks against retrieval-augmented generation (RAG) systems. Treat it as a standing condition to be governed, not an incident to be closed.

Executive Takeaways

Because this is an architectural exposure rather than a technical vulnerability, the appropriate response is governance and hardening — not detection rules that would fire on every crawler hit in your environment.

1. Re-run your external content inventory with AI retrieval in mind. Enumerate everything publicly indexable under your domains — including staging, legacy, and forgotten subdomains. If you would not want it read aloud to a stranger by a confident assistant, take it offline or authenticate it. Prioritize job postings (tech-stack leakage), support documentation (internal tool names), and PDF metadata.

2. Make an explicit, documented decision on AI crawler access. Decide per-property whether OAI-SearchBot, ChatGPT-User, ClaudeBot, and PerplexityBot are allowed via robots.txt. Understand the tradeoff: blocking search crawlers reduces your exposure but also removes your legitimate presence from AI answers — which creates vacuum that attackers and SEO poisoners will fill. For most organizations, the right answer is selective: allow marketing properties, block portals, docs, and anything adjacent to customer data.

3. Lock down user-generated content pipelines. Anything a third party can publish on your domain — comments, forums, profile fields, review sections — is now a potential prompt injection vector against people asking ChatGPT about you. Apply output encoding, moderation, and content-length/structure limits, and treat UGC injection attempts with the same seriousness as stored XSS.

4. Monitor what AI assistants say about you. Whether via a GEO vendor like Promptwatch or internal automation, track how ChatGPT, Claude, and Gemini answer high-value prompts about your brand, products, and executives. Sudden shifts in those answers are an early-warning indicator of poisoning, impersonation, or leaked content surfacing.

5. Extend your shadow-AI and DLP policy to cover this direction of flow. Most AI governance focuses on data employees paste into chatbots. Add policy for the reverse: employees consuming AI-summarized content about your own infrastructure may act on injected or fabricated claims. Include AI-mediated reconnaissance in your threat intelligence assumptions.

6. Brief your incident response playbooks. Add indirect prompt injection and AI-answer manipulation to your IR taxonomy. When a customer reports that "ChatGPT said your product does X," your team needs a defined process: verify the claim, identify the source content the model retrieved, and determine whether your indexed content was manipulated.

Remediation

There is no vendor patch for this exposure — remediation is entirely on the asset-owner side. Concrete steps:

• Crawler governance: Publish and enforce a deliberate robots.txt stance on AI crawlers. Example posture — allow search indexing on marketing, disallow on everything else:

# Verify what AI crawlers can currently reach
# Check robots.txt posture
curl -s https://yourdomain.com/robots.txt | grep -iE 'OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|GPTBot'

# Audit access logs for AI crawler activity over the last 30 days
grep -iE 'OAI-SearchBot|ChatGPT-User|GPTBot|ClaudeBot|PerplexityBot' /var/log/nginx/access.log \
  | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -50

A sample restrictive stance for sensitive properties:

# robots.txt for portals/docs/staging — not for your main marketing site
# User-agent: OAI-SearchBot
# Disallow: /
# User-agent: ChatGPT-User
# Disallow: /
# User-agent: GPTBot
# Disallow: /
#
# NOTE: robots.txt is advisory. Enforce with auth on anything truly sensitive.

• De-index and authenticate: For staging and legacy properties, do not rely on robots.txt or noindex alone — put them behind SSO/VPN. Crawlers and AI retrievers are under no obligation to honor directives, and content that has already been ingested may persist in AI products' retrieval indexes.
• Takedown and correction channels: Establish contacts and processes with OpenAI and other AI vendors for reporting manipulated or incorrect retrieval of your content. Document this in your IR runbooks before you need it.
• Validate UGC defenses: Have your penetration testing team explicitly test indirect prompt injection payloads in every user-controllable field that ends up on a public, indexable page. This belongs in your standard web assessment scope in 2026.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub