Redacting Secrets Before the Prompt Leaves Your Process: A Pre-Send Filter for One Key

Why a Pre-Send Filter Matters

When you use a single API key to call multiple models (Claude, GPT, DeepSeek, Qwen, GLM, Kimi), every prompt leaves your process and travels to an external backend. Any secrets, tokens, or personally identifiable information (PII) embedded in that prompt become part of the request payload. A local scrub layer catches these before transmission, reducing exposure without sacrificing functionality.

This filter operates entirely within your process—no network calls, no third-party dependencies. It sits between your application code and the API client, inspecting and transforming the prompt just before the request is sent.

Core Components

A practical pre-send filter has three parts:

• Detectors: pattern matchers for API keys, tokens, passwords, email addresses, phone numbers, and other sensitive strings.
• Placeholder generator: a reversible mapping that replaces each detected secret with a unique placeholder (e.g., [[SECRET_1]]).
• Restorer: a post-processing step that substitutes placeholders back with original values in the model's response, if needed.

Designing Detectors

Start with high-confidence patterns for common secret formats:

• API keys: long alphanumeric strings with prefixes like sk, pk, or AKIA.
• Tokens: JWTs (three base64url segments separated by dots), OAuth tokens, and bearer tokens.
• Passwords: strings following password= or passwd: in configuration-like text.
• PII: email addresses, phone numbers (with country codes), and credit card numbers (Luhn-validated).

Use regular expressions with word boundaries and context clues (e.g., key=, token:) to reduce false positives. Avoid overly broad patterns that might redact benign text.

Reversible Placeholder Scheme

Each detected secret gets a unique placeholder that encodes its type and an index:

• [[APIKEY1]]
• [[EMAIL_2]]
• [[PHONE_3]]

Maintain a mapping dictionary from placeholder to original value for the duration of the request. This mapping stays in memory only and is never sent to the API.

When the model's response arrives, scan for placeholders and replace them with the original values. This keeps the conversation coherent—the model sees placeholders and can refer to them, and you restore meaning locally.

Integration with the API Client

Wrap your API calls with a function that:

1. Serializes the prompt (or messages array) to a string.
2. Applies detectors and replaces matches with placeholders.
3. Sends the scrubbed prompt to the chosen model via your aggregator endpoint.
4. Receives the response and restores placeholders using the mapping.
5. Returns the restored response to your application.

Because the aggregator uses one API key for all models, you only need to implement this filter once at the client level. The same scrubbing logic applies regardless of whether you call Claude, GPT, DeepSeek, Qwen, GLM, or Kimi.

Handling Edge Cases

• Nested structures: If your prompt includes JSON or code blocks, apply detection recursively to string values.
• Partial matches: Use lookarounds to avoid redacting substrings of larger benign identifiers.
• Placeholder collisions: Ensure placeholders are unlikely to appear naturally; use double brackets and a reserved prefix.
• Streaming responses: For streaming, buffer chunks until a placeholder is complete before restoring, or disable restoration for streaming and handle it client-side after full assembly.

Testing and Maintenance

Build a test suite with sample prompts containing known secrets and PII. Verify that:

• All sensitive strings are replaced.
• Benign strings remain untouched.
• Restoration yields the original response.

Review and update patterns as new secret formats emerge. Keep the filter local and deterministic—no external calls, no logging of original secrets.

Conclusion

A pre-send filter adds a layer of safety when using a multi-model API aggregator. By redacting secrets and PII locally and using reversible placeholders, you maintain functionality while reducing the risk of leaking sensitive data to external backends. Implement it once, and it protects every request across all supported models.