Credential and Secret Leakage Repair Prompt Template

This prompt is designed for platform and DevSecOps engineers who need a post-generation safety net to prevent secret exposure in production AI systems. The primary job-to-be-done is to scan model outputs—whether free text, structured JSON, or generated code—and reliably detect, redact, and audit any leaked credentials, API keys, tokens, connection strings, or private keys before those outputs reach logs, databases, or user-facing surfaces. The ideal user is someone integrating this prompt into an AI gateway, logging pipeline, or CI/CD output validator, where a missed secret is a security incident and a false positive creates operational noise.

Use this prompt when you have model-generated content that could inadvertently include secrets, and you need a structured repair output that preserves the original content's utility while masking sensitive material. It is particularly effective when combined with regex-based pre-scanning for known secret formats (AWS access keys, GitHub tokens, JWT patterns, connection strings) and when you need contextual disambiguation to distinguish real credentials from benign placeholder strings like example-api-key or test_password. The prompt expects a clear [INPUT] containing the suspect text, an optional [CONTEXT] describing the expected content domain, and a [CONSTRAINTS] block specifying your masking strategy and audit requirements. Do not use this prompt as your sole defense—it is a repair layer, not a replacement for input sanitization, least-privilege credential management, or secret scanning in CI/CD pipelines.

Avoid this prompt when you need real-time streaming redaction with sub-50ms latency, as the model inference time may exceed your budget. It is also inappropriate for binary file scanning, encrypted payload inspection, or scenarios where the model itself lacks the context to distinguish a test credential from a production one. In high-security environments, always pair this prompt's output with a deterministic post-processing validator that confirms no known secret patterns remain, and route any ambiguous cases to a human review queue. For regulated industries, ensure your audit trail captures the original hash, the redaction decision, and the reviewer identity before the sanitized output enters any persistent store.

This template is designed to be dropped into a post-generation repair loop. It receives a raw model output that may contain leaked credentials, API keys, tokens, connection strings, or private keys. The prompt instructs the model to scan the input, identify secrets using pattern matching and contextual disambiguation, apply a configurable masking strategy, and return a sanitized version alongside an audit trail. The template uses square-bracket placeholders that you replace with your specific inputs, output schema requirements, and operational constraints before wiring it into your application.

textCopy
You are a security-focused output sanitizer. Your task is to scan the provided model output for leaked credentials and secrets, then return a sanitized version with an audit trail.

## INPUT TO SCAN
[INPUT]

## SECRET PATTERNS TO DETECT
Scan for the following categories using both pattern matching and contextual analysis:
- API keys (AWS, GitHub, OpenAI, Stripe, and other common service key formats)
- OAuth tokens and bearer tokens
- Passwords and passphrases in plaintext
- Connection strings (database, Redis, message queues, etc.)
- Private keys (SSH, TLS/SSL, PGP, JWT signing keys)
- Internal hostnames, IPs, and endpoints that should not be exposed
- Environment variables containing secrets
- Hardcoded credentials in code snippets or configuration blocks

## DISAMBIGUATION RULES
- Do NOT redact placeholder values, example keys, or test credentials that are clearly documented as non-production (e.g., "sk-test-", "EXAMPLE_API_KEY", "your-key-here")
- Do NOT redact public identifiers, public hostnames, or well-known endpoints
- If a string matches a secret pattern but appears in a comment, documentation, or educational context, flag it as [NEEDS_REVIEW] rather than automatically redacting
- For ambiguous cases, assign a confidence score (HIGH/MEDIUM/LOW) and include reasoning in the audit trail

## MASKING STRATEGY
Apply the following masking rules based on [RISK_LEVEL]:
- If [RISK_LEVEL] is "strict": Replace all detected secrets with "[REDACTED]"
- If [RISK_LEVEL] is "preserve-format": Preserve the first 4 and last 4 characters with asterisks between (e.g., "sk-ab****xy12")
- If [RISK_LEVEL] is "audit-only": Do not mask, but flag all detections in the audit trail

## OUTPUT SCHEMA
Return a valid JSON object matching this schema:
[OUTPUT_SCHEMA]

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Scan the entire input systematically, line by line
2. For each detection, record: the matched string, the secret type, the line or field location, confidence score, and disambiguation reasoning
3. Apply the masking strategy consistently across the entire output
4. If no secrets are detected, return the original output unchanged with an empty findings array
5. Do not modify any content that is not a detected secret
6. Preserve all formatting, whitespace, and structure of the original output

Adaptation guidance: Replace [INPUT] with the raw model output you need to scan. Set [RISK_LEVEL] to match your operational requirements—use "strict" for user-facing surfaces, "preserve-format" for debugging workflows where partial visibility is needed, and "audit-only" for pre-commit hooks or CI pipelines where you want detection without modification. Define [OUTPUT_SCHEMA] as a JSON schema that includes at minimum a sanitized_output field and a findings array with type, location, confidence, and action fields. Use [CONSTRAINTS] to add domain-specific rules, such as preserving specific log formats or excluding certain fields from scanning. Populate [EXAMPLES] with 2-3 few-shot examples showing correct detection, disambiguation, and masking for your specific secret types. For high-risk production environments, always route NEEDS_REVIEW findings to a human approval queue before the sanitized output is released downstream.

This prompt is not a standalone security product; it is a post-generation safety net that must be embedded inside a broader application harness. The harness is responsible for receiving model output, calling the repair prompt, validating the result, and deciding whether the sanitized output is safe to forward to downstream systems. Because credential leakage can lead to immediate security incidents, the harness must treat every repair decision as high-risk and must default to blocking or quarantining output when the prompt cannot make a confident determination. The implementation pattern follows a detect–repair–validate–audit loop: the model output enters the harness, the repair prompt identifies and masks secrets, a post-repair validator checks that no known secret patterns remain, and every action is logged for audit.

Wire the prompt into your application as a synchronous post-processing step that runs after the primary model call and before any logging, database insertion, or user-facing rendering. In pseudocode, the integration looks like: raw_output = primary_model.complete(prompt); repaired = credential_repair_prompt.run(raw_output, context={...}); if validator.scan(repaired.output).has_secrets(): quarantine(raw_output, repaired); else: forward(repaired.output). The context object should include the expected output format, a list of known benign test patterns (e.g., placeholder keys used in documentation), and the required masking strategy—such as REDACT, HASH, or REPLACE_WITH_PLACEHOLDER. The validator must use deterministic regex and entropy-based checks as a secondary layer, because the repair prompt may miss secrets or hallucinate a clean bill of health. If the validator finds any remaining high-entropy strings that match known secret formats, the output must be blocked and the incident escalated.

Model choice matters. Use a fast, instruction-following model for the repair step—such as Claude 3.5 Haiku, GPT-4o-mini, or a fine-tuned small model—because this prompt runs on every primary model response and latency adds up. Avoid routing the repair prompt to the same model instance that generated the original output, as this creates a single point of failure where the same model that leaked a secret is asked to find it. For high-sensitivity environments, run the repair prompt on a separate model provider or a locally deployed model to reduce the risk of the repair step itself leaking secrets to an external API. Retries should be limited to one or two attempts with escalating instructions; if the repair prompt repeatedly fails to produce a clean output, quarantine the original and alert the on-call security channel rather than looping indefinitely.

Logging and audit trail requirements are non-negotiable. Every invocation of the repair prompt must produce a structured audit record containing: the original output hash (never log the raw output itself), the repair prompt version, the list of detected secret types, the masking actions taken, the validator result, and a human-readable justification. Store these records in a dedicated, access-controlled audit log separate from application logs. For regulated environments, ensure the audit trail supports downstream review workflows where a security engineer can sample repair decisions, verify that no secrets were missed, and tune the detection rules. Human review should be triggered automatically when the repair prompt detects a secret with confidence below a configurable threshold, when the validator disagrees with the repair prompt, or when the output contains patterns that match high-severity credential types such as private keys or long-lived access tokens.

What to avoid: Do not treat this prompt as a replacement for preventing secret generation at the source. It is a defense-in-depth layer, not a guarantee. Do not log the raw model output before the repair step runs—this defeats the purpose. Do not use the repair prompt's output directly in user-facing surfaces without the validator confirming the result. And do not assume that pattern-based detection catches everything; secrets that do not match known formats (e.g., proprietary API tokens) will pass through undetected. The harness should be paired with complementary controls: prompt instructions that discourage secret generation, output length limits that reduce the blast radius, and periodic red-team exercises that test whether the repair pipeline catches novel leakage patterns.