Code and Configuration Secret Redaction Prompt Template

This prompt is a post-generation safety net for DevSecOps and platform engineering teams. Its primary job is to scan model-generated code, configuration files, Dockerfiles, and Infrastructure-as-Code (IaC) templates for hardcoded secrets before these artifacts enter version control, CI/CD pipelines, or production environments. Use it when a coding agent or LLM produces files that may inadvertently contain API keys, database connection strings, private tokens, or internal service endpoints. The prompt performs language-aware scanning, distinguishes real secrets from placeholder values, and produces a redacted output with an audit trail of changes.

This prompt is not a replacement for pre-commit hooks, secret scanning tools like truffleHog or git-secrets, or CI/CD pipeline security gates. Instead, it is a repair layer for AI-generated content that bypasses those controls—for example, when a coding agent writes a config file directly to disk without triggering a pre-commit hook, or when an LLM generates a Dockerfile inside a chat interface that a developer copies and pastes. The prompt expects the full file content as input and returns a redacted version where secrets are replaced with safe placeholder values. It is designed to be wired into an automated pipeline where model outputs are intercepted and sanitized before they reach any persistent storage or execution environment.

Do not use this prompt for real-time streaming output, for scanning entire repositories, or as a primary security control. It is a targeted repair tool for individual files or small batches of model-generated content. For high-risk environments, always pair this prompt with human review of the redaction audit trail, especially when the model flags borderline cases or when the file contains complex templating syntax that may confuse pattern-based detection. The next section provides the copy-ready prompt template you can adapt for your specific language and secret format requirements.

This template is designed to be placed directly into your system instructions or used as a post-generation repair step in your AI pipeline. It instructs the model to act as a security-focused code reviewer, scanning generated artifacts for hardcoded credentials, tokens, and internal endpoints. The prompt uses language-aware heuristics to distinguish real secrets from placeholder values, and it produces a structured, machine-readable report that your application can parse to either block, redact, or flag the output for human review.

markdownCopy
You are a DevSecOps security scanner. Your task is to analyze the provided [INPUT] for hardcoded secrets, credentials, and internal endpoints. The [INPUT] may be source code, a Dockerfile, an IaC template, or a configuration file. The expected language or format is [LANGUAGE].

# SCANNING RULES
1. **High-Severity Secrets (Block):** Flag any literal strings that match the pattern of API keys, private keys, tokens, or database connection strings. This includes patterns like `sk-...`, `ghp_...`, `AKIA...`, `-----BEGIN RSA PRIVATE KEY-----`, and `mongodb+srv://user:pass@...`.
2. **Medium-Severity Secrets (Warn):** Flag hardcoded passwords, even if they don't match a known service pattern, and internal hostnames or IPs in non-local ranges (e.g., `10.x.x.x`, `192.168.x.x`).
3. **False Positive Disambiguation:** Ignore placeholder values like `YOUR_API_KEY_HERE`, `test_secret`, `password123`, or `localhost`. Do not flag environment variable references like `${API_KEY}` or `os.getenv('SECRET')`.
4. **Safe Replacement:** For every flagged secret, suggest a safe replacement, such as a reference to an environment variable or a secret manager call.

# OUTPUT FORMAT
You must respond with a single valid JSON object conforming to this [OUTPUT_SCHEMA]:
{
  "status": "PASS" | "WARN" | "BLOCK",
  "findings": [
    {
      "severity": "HIGH" | "MEDIUM",
      "type": "API_KEY" | "PASSWORD" | "PRIVATE_KEY" | "INTERNAL_ENDPOINT" | "CONNECTION_STRING",
      "line_number": <integer>,
      "redacted_snippet": "<string with the secret masked>",
      "safe_replacement": "<string with the suggested fix>"
    }
  ],
  "summary": "<A brief, one-sentence summary of the scan results.>"
}

# CONSTRAINTS
- Do not output the full, unmasked secret in your response.
- If no secrets are found, return an empty `findings` array and a `status` of `PASS`.
- The [RISK_LEVEL] for this scan is [HIGH/MEDIUM/LOW]. If set to HIGH, you must err on the side of caution and flag anything suspicious.

To adapt this template, replace the square-bracket placeholders with your specific values. [INPUT] should be the code or configuration text to scan. [LANGUAGE] helps the model apply correct pattern-matching heuristics (e.g., python, yaml, dockerfile). [OUTPUT_SCHEMA] can be tightened or loosened based on your downstream parser's tolerance. The [RISK_LEVEL] parameter is a critical control: set it to HIGH for production deployment pipelines where a leak is a critical incident, and MEDIUM or LOW for internal development tools where a false positive is more acceptable than a missed secret. After pasting this prompt, always run it against a golden dataset of known secrets and benign placeholders to calibrate its performance before production use.

This prompt is not a standalone security product; it is a post-generation safety net that sits between a model's output and any downstream system—a code repository, a CI/CD pipeline, a logging aggregator, or an internal review UI. The implementation harness must treat the model as an unreliable detector and build defense-in-depth around it. The core loop is: receive raw model output, run the redaction prompt, validate the response schema, apply the redactions, log an audit record, and route high-risk or low-confidence findings for human review before the output is considered safe.

Start by wrapping the prompt in a strict JSON schema validator. The expected output is an object with a redactions array, each containing original, redacted, type, confidence, and location fields. If the model returns malformed JSON, missing required fields, or a confidence value outside 0.0–1.0, reject the response and retry with a repair prompt that includes the schema error. Implement a maximum of two retries before escalating to a human review queue. For model choice, prefer a low-latency, instruction-following model (such as gpt-4o-mini or claude-3-haiku) for cost efficiency, but route files flagged with [RISK_LEVEL] = high to a more capable model. The [CONTEXT] placeholder should be populated with language-specific secret patterns—for example, a Python scanner should look for os.environ.get bypasses, while a Terraform scanner should flag hardcoded access_key and secret_key values.

Logging and audit trails are non-negotiable. Every redaction event must be logged with a unique scan_id, the model version used, the raw and redacted snippets, the confidence scores, and the final disposition (auto-redacted, escalated, or cleared). Store these logs in a tamper-evident store separate from the application logs. Before deploying, build an eval harness with a golden dataset of known secrets—AWS keys, GitHub tokens, JWT secrets, database connection strings, and benign lookalikes—and measure both recall (did we catch the real secrets?) and precision (did we flag safe code?). A recall below 0.95 on known secret patterns is a release blocker. Finally, never allow auto-redacted code to merge to main without a human-in-the-loop approval step for any finding with confidence < 0.90 or type in a critical category like private_key or production_credential.