[FEATURE] Mechanism to redact secrets/PII from the context window
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
The context window in Claude Code is append-only and permanent. Once sensitive data enters the context — whether inbound (a tool result echoes a secret or reads a credentials file) or outbound (a model response summarizing that data) — it remains in every subsequent API call for the lifetime of the session. There is no way to remove or redact it.
Concrete examples of how secrets enter the context permanently:
- A shell command runs
echo $API_KEYor bareenv— the secret value appears in the tool result and is carried forward in every future API message. - Claude reads a file that happens to contain credentials (can be as innocent looking as
notes.txt) — the content is now in the context indefinitely. - A model response summarizes sensitive output — even if the original tool result is "forgotten" by truncation, the summary persists.
- A tool fetches the user's personal info (PII data) and print into the output — that info now may be sent over the Internet at every prompt later.
Hooks like PreToolUse and PostToolUse can help block dangerous commands before they run, but they cannot redact the data. Once data is in the context, there is currently no recourse.
What's Missing
There is no mechanism — first-party or third-party — to redact or remove sensitive content from the context window as soon it is being added.
- UserPromptSubmit hook can only detect and block if a user puts in sensitive data. It cannot sanitize and let the prompt to through.
- BeforeToolUse / PostToolUse hooks can only block and detect, but they cannot sanitize. Sensitive data can still go through if allowed.
This matters for:
- Accidental leakage: A script outputs more than intended; the secret is now baked into the session.
- Supply-chain attacks: A malicious skill deliberately triggers a tool result that captures a secret into context, from where it will be included in every subsequent API call without any additional outbound command.
- Compliance: Organisations with PII or secrets-handling policies have no way to enforce redaction at the agent layer.
Desired Capability
Whether implemented as a first-party feature (built-in secret scanning and redaction) or as an interface for third-party tools, the capability needed is: the ability to remove or mask specific content (secrets, PII patterns) from the context window so it is not included in future API calls.
This might make more sense to be a 1st party feature as it directly links to customer trust for Claude. If customers find out their secrets or PII are passed as part of the context window repeatedly, it greatly erodes trust. If they see the sensitive info are captured and redacted, however, the trust only grows. Customers won't necessarily install 3rd party tools or plugins.
Options to Consider
Option 1: Claude Code (or even Claude models) 1st party handling
Claude Code or Claude send the prompt and any tool response to a dedicated Anthropics server for sanitiization and data redaction.
Flow
Prompt Submitted
|
Claude Intercepts Prompt -> Send To a Dedicated Anthropic Server to Sanitize Prompt
|
Sanitized Prompt Enters Context
|
Tool Called with Sanitized Prompt
|
Tool Execution
|
Tool Returns Response
|
Claude Intercepts Response -> Send To a Dedicated Anthropic Server to Sanitize Response
|
Sanitized Response Enters Context
|
Process Response
Pros
- Works for all Claude/Claude Code users by default.
- Uses an LLM to redact data - much more versatile than pattern-matching, often the solution from 3rd party tools.
- Builds trust. Customers don't see their secrets/PII in chats. Privacy as first-class citizen.
Cons
- Additional maintainence and operational cost on Anthropic.
- Less flexible for customers who may prefer to have their sensitive data in the context
- Mitigation: 1) Allow turning off the feature with a flag; 2) Today Claude already refuses to pull secret keys, passwords, etc. This might be a non-issue.
- Sensitive data might still get sent to Anthropic server once
- Mitigation: Dedicate the server/service for sanitization. Isolate and lock down the server access for maximum privacy.
Option 2: Allow plugins and 3rd party to intercept and sanitize through hooks
Implement hooks to allow plugins and 3rd party tools to modify the prompt and tool responses before they can make it into the context window.
Flow
Prompt Submitted
|
Prompt Transformation Hook -> Invoke Tools to Sanitize Prompt
|
Sanitized Prompt Enters Context
|
Tool Called with Sanitized Prompt
|
Tool Execution
|
Tool Returns Response
|
Claude Intercepts Response -> Invoke Tools to Sanitize Response
|
Sanitized Response Enters Context
|
Process Response
Pros
- Flexibility. Users can use whatever implementations they want.
- Less maintainence overhead for Anthropics.
Cons
- May not as effective as a 1st party solution.
- If the plugin/tool relies on pattern matching -> far less versatile than LLM.
- If the plugin/tool sends the data to another provider -> additional leakage potential.
Option 3: Option 1 + 2
Implement option 1 as the default, and expose the option 2 hooks in the process (hooks are likely needed for option 1 anyway), allowing for customization. This is similar to how PreToolUse works today: default is to ASK, and users can override with their own rules via hook.
This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗