API Key and Secret Scrubbing Prompt for Code Snippets

This prompt is designed for a single, security-critical job: detecting and replacing API keys, cloud credentials, and high-entropy secrets inside code snippets before those snippets are sent to a large language model. The ideal user is a developer building an AI coding assistant, a security engineer hardening a pre-inference data pipeline, or a platform engineer responsible for preventing secret leakage in a multi-tenant SaaS product. The prompt expects a raw code block as input and returns the same code block with all detected secrets replaced by descriptive placeholder variables such as [REDACTED_AWS_ACCESS_KEY]. It is not a general-purpose PII redaction tool, a log sanitizer, or a natural-language document scrubber—use the sibling PII Detection or Context Sanitization prompts for those tasks.

You should use this prompt when code is the primary input modality and the risk is exfiltration of programmatic credentials to a third-party model provider. The prompt is tuned to catch common secret formats: AWS AKIA... keys, Azure connection strings, GCP service account JSON, GitHub ghp_... tokens, Stripe sk_live_... keys, and generic high-entropy base64 or hex strings that match the structural fingerprint of secrets. It also handles secrets embedded in environment variable assignments, config files, and CLI examples. The output is a drop-in replacement for the original code, preserving syntax and structure so that downstream tasks—code explanation, refactoring, test generation—still function correctly. Do not use this prompt if you need cryptographic guarantees of redaction; a regex-based pre-filter combined with this LLM-based scrubber provides defense-in-depth, but neither replaces a dedicated secret scanning platform for production audit trails.

Before wiring this into your application, gather the following: a representative sample of your codebase's secret formats (including internal patterns like company_secret_*), a golden dataset of code snippets with known secrets for evaluation, and a clear policy on what should happen when the model is uncertain. The prompt includes a [CONFIDENCE_THRESHOLD] variable that lets you control the trade-off between false positives (over-redaction that breaks code) and false negatives (missed secrets that leak). Start with a threshold of 0.7 and adjust based on your eval results. If your application handles code in multiple languages, test the prompt against each language's common secret-loading idioms—Python's os.getenv(), Node's process.env, Go's os.LookupEnv—to ensure the scrubber recognizes secrets regardless of how they are referenced.

When to choose a different approach: If your primary concern is PII in natural language (names, emails, SSNs) rather than programmatic secrets, use the PII Detection Prompt Template instead. If you need to sanitize the entire assembled prompt context—not just code blocks—before tool dispatch, the Context Sanitization Prompt is a better fit. If you are building a final pre-inference gate that must catch everything that slipped through earlier redaction layers, deploy the Prompt Assembly Guard Prompt as a last line of defense. This prompt is a specialized component in a larger sensitive-data handling architecture, not a standalone solution.

This prompt template is designed to be integrated into a pre-processing pipeline for any developer tool, AI coding assistant, or internal platform that processes user-submitted code before it reaches an LLM. The template accepts a raw code snippet and a configurable list of secret patterns to scan for, then returns a scrubbed version of the code with all detected secrets replaced by descriptive placeholder variables. The output also includes a structured audit map so downstream systems can verify what was changed and, if needed, rehydrate the original values in a secure execution environment.

textCopy
You are a security-focused code sanitizer. Your task is to scan the provided code snippet for API keys, access tokens, connection strings, private keys, and other secrets. You must replace every detected secret with a descriptive placeholder variable while preserving all other code structure, comments, and formatting exactly.

## INPUT CODE

[CODE_SNIPPET]

codeCopy

## SECRET PATTERNS TO DETECT
[SECRET_PATTERNS]

## INSTRUCTIONS
1. Scan the input code line by line.
2. Identify any string literal, variable assignment, config value, or hardcoded credential that matches a known secret pattern or exhibits high entropy typical of keys and tokens.
3. For each detected secret:
   - Replace the secret value with a descriptive placeholder in the format `[REDACTED_<TYPE>]` where `<TYPE>` is a short, descriptive label (e.g., `AWS_ACCESS_KEY`, `GITHUB_TOKEN`, `DATABASE_URL`, `STRIPE_SECRET`).
   - If the same secret appears multiple times, use the same placeholder consistently.
   - Do not alter variable names, only the assigned values.
4. Preserve all code structure, indentation, comments, imports, and surrounding logic exactly as-is.
5. Do not redact non-secret strings such as public identifiers, file paths, library names, or user-defined variable names.
6. If no secrets are detected, return the original code unchanged.

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "scrubbed_code": "<the full code snippet with secrets replaced>",
  "replacements": [
    {
      "placeholder": "[REDACTED_<TYPE>]",
      "secret_type": "<type classification>",
      "line_number": <integer>,
      "original_length": <integer>
    }
  ],
  "secrets_detected": <integer>,
  "scrubbed": <boolean>
}

## CONSTRAINTS
- Never output the original secret values in any field of the response.
- The `original_length` field must record only the character count of the redacted value, not the value itself.
- If the input code is empty or contains only whitespace, return an empty scrubbed_code and set secrets_detected to 0.
- Do not add explanatory text outside the JSON object.

To adapt this template for your environment, replace [CODE_SNIPPET] with the raw code block submitted by the user or extracted from a repository. The [SECRET_PATTERNS] placeholder should be populated with a structured list of the specific credential formats you need to catch—such as AWS AKIA* keys, GitHub tokens (ghp_*, gho_*, ghu_*, ghs_*), Azure connection strings, JWT tokens, Stripe sk_live_* keys, and generic high-entropy base64 strings. For production use, pair this prompt with a regex pre-filter that catches unambiguous patterns before calling the LLM, reducing both latency and the risk of the model accidentally echoing a secret in its response. Always log the replacements array for auditability, and never send the original [CODE_SNIPPET] to an external model endpoint without this scrubbing layer in place.

Integrating this prompt into an application requires treating it as a deterministic pre-processing step, not an advisory check. The prompt should be called before any code snippet enters a model's context window, a tool's argument list, or a logging pipeline. The harness must enforce a strict contract: the input is a raw code block, and the output must be a structurally identical code block with all detected secrets replaced by descriptive placeholders. Any deviation in code structure—such as reformatting, line reordering, or comment removal—constitutes a failure and must trigger a retry or fallback. The system should never pass the original, unscrubbed code to a downstream model.

The implementation should wrap the LLM call in a validation layer that performs at least three checks. First, a structural diff between the input and output code must confirm that only secret-bearing lines changed and that the AST (abstract syntax tree) remains equivalent modulo literal values. Second, a high-entropy regex scan must run on the output to verify that no strings exceeding a configurable entropy threshold (e.g., 4.5 bits per character) remain. Third, a known-pattern check must confirm that common secret formats—AWS access keys (AKIA...), Azure connection strings, GCP service account keys, GitHub personal access tokens, and common OSS library patterns like SECRET_KEY = assignments—are absent from the scrubbed output. If any check fails, the harness should retry with a more explicit prompt variant that includes the specific failure reason, up to a maximum of two retries before escalating to a human review queue.

Model choice matters for this workflow. A smaller, faster model (such as Claude 3 Haiku or GPT-4o-mini) is usually sufficient because the task is pattern-matching with structured replacement, not open-ended reasoning. The harness should log every scrubbing operation with a trace ID, the original code hash, the scrubbed code hash, a diff summary, and the model version used. For high-security environments, consider running the prompt through two different model families and comparing outputs; any disagreement should block the pipeline. Never log the original secrets themselves—log only their detected presence, location, and the placeholder used. When deploying in CI/CD pipelines, integrate this prompt as a pre-commit hook or a pre-inference gateway that fails closed: if the scrubbing service is unavailable, the pipeline must block code from reaching any model endpoint rather than falling back to unscrubbed input.