WebSearch/WebFetch: option to scrub PII from queries before sending

Problem

Claude Code's WebSearch and WebFetch tools construct queries from conversation context. That context may contain personal information — the model can inadvertently include names, locations, medical details, or other sensitive data in search queries sent to external providers.

This makes the permission decision harder than it needs to be:

• Always allow is convenient but means trusting that the model will never put anything sensitive in a query string — a guarantee nobody can make
• Ask every time is safe but high-friction in research-heavy sessions

Users who work with any personal or client data in their projects face this tradeoff constantly.

Proposed Solutions

Option A: Isolated query composer

Instead of letting the main agent (which has full conversation context) write search queries directly, delegate query composition to a minimal-context subagent that receives only:

• The abstract search intent (e.g., "find attorneys who offer X service in Y region")
• No personal details, file contents, or conversation history

This is architecturally simpler than post-hoc scrubbing because PII never enters the query generation path. The bottleneck is before the query is composed, not after. This is similar to how a user would manually rephrase a search to avoid typing personal info into Google.

Option B: Post-generation PII filter

Add an optional filter that sanitizes queries after the model generates them but before the HTTP request fires:

1. Detect likely PII in the short query string (proper names, addresses, phone numbers, emails, etc.)
2. Strip or generalize detected PII while preserving search intent
3. Optionally show the sanitized query to the user for verification

This is more of a safety net — catches cases where the model includes something it shouldn't, but is harder to get right without breaking valid queries.

These could be complementary

Option A prevents PII from entering queries by design. Option B catches leaks when it slips through anyway. Either alone would be a major improvement over the status quo.

Why This Complements Permission Scoping

Issues like #26345 address when to prompt for approval. This addresses what gets sent — even with broad approval, queries should be safe by default. Better permission scoping reduces approval friction; PII scrubbing reduces the risk of each individual query.

Prior Art

• LLM guardrail frameworks (Guardrails AI, NeMo Guardrails) implement PII detection on model outputs
• Privacy-focused search engines strip identifiers at the provider level, but that doesn't help if PII is in the query text itself
• The isolated-agent pattern is analogous to how browsers isolate cross-origin contexts to prevent data leakage