Secret Exposure Scan Prompt Template

This prompt is designed for security engineers and DevSecOps teams who need to scan source code repositories for hardcoded secrets, API keys, tokens, and credentials. It belongs in a CI/CD pipeline, a pre-commit hook, or a periodic security audit workflow. The prompt instructs an LLM to act as a security reviewer, analyzing code snippets or file contents to identify exposed secrets, classify their type, and provide actionable remediation guidance. Use this when static analysis tools like truffleHog or git-secrets need augmentation with contextual reasoning, or when you need a structured, human-readable findings report from raw code.

Do not use this as a replacement for deterministic secret scanning tools in production pipelines; it is a complementary review layer. The LLM's strength lies in reasoning about context—such as distinguishing a test fixture from a production credential or identifying a secret embedded in a multi-line string—but it is not a regex engine. You must ground its analysis by providing the raw file content and path as input. The prompt is most effective when applied to high-risk files flagged by a pre-scan, such as config/*.yaml, .env.example, or CI workflow definitions, rather than scanning an entire monorepo blindly.

Before integrating this prompt into an automated harness, define your risk tolerance for false negatives. Because LLMs are non-deterministic, a single pass may miss an obscured credential. Implement a validation layer that cross-references the LLM's findings against a known dictionary of secret patterns and requires a human reviewer to sign off on any finding classified as CRITICAL. The next section provides the exact prompt template you can adapt and embed in your security orchestration tooling.

This template is the core instruction set for an AI coding agent to perform a secret exposure scan. It is designed to be pasted into your AI harness, where you replace the square-bracket placeholders with the actual file contents, repository context, and output requirements for your specific scan. The prompt instructs the model to act as a security engineer, analyzing code for high-entropy strings and known credential patterns, and then structuring its findings into a machine-readable report. The strict output schema and constraints are critical for integrating the results directly into a security dashboard or automated ticketing system.

markdownCopy
You are a security engineer performing an automated secret exposure scan on a code repository. Your task is to analyze the provided file contents and identify any hardcoded secrets, credentials, tokens, or API keys.

## Input Data
- **File Path:** [FILE_PATH]
- **File Content:**

[FILE_CONTENT]

codeCopy
- **Repository Context:** [REPOSITORY_CONTEXT]

## Task
1.  Scan the `[FILE_CONTENT]` for any strings that match patterns of hardcoded secrets. This includes, but is not limited to:
    - High-entropy strings (e.g., base64, hex).
    - Known patterns for API keys (AWS, Google, Stripe, etc.).
    - Private keys (SSH, PGP).
    - Database connection strings with embedded credentials.
    - Authentication tokens (JWT, OAuth).
    - Generic passwords assigned to variables.
2.  For every potential finding, classify its `secret_type`, assess a `confidence` level (high, medium, low), and draft a `remediation_guidance` step.
3.  If no secrets are found, return an empty `findings` array.

## Output Schema
You must respond with a single JSON object conforming to this exact schema:
[OUTPUT_SCHEMA]

## Constraints
- **Do not** flag placeholder or example values (e.g., `your_api_key_here`, `xxxxxx`).
- **Do not** flag environment variable references (e.g., `os.getenv("DB_PASS")`).
- **Do** flag hardcoded strings that are clearly meant to be secrets, even if they are in comments or documentation.
- **Do** provide the exact line number and a snippet of the surrounding code for each finding.
- Base your analysis strictly on the provided `[FILE_CONTENT]` and `[REPOSITORY_CONTEXT]`.

## Examples
[EXAMPLES]

## Risk Level
This scan is for a [RISK_LEVEL] environment. Apply the following sensitivity:
- **Low:** Only flag high-confidence, critical-severity secrets.
- **Medium:** Flag high and medium-confidence secrets.
- **High:** Flag all potential secrets, including low-confidence findings for manual review.

To adapt this template, start by defining your [OUTPUT_SCHEMA] as a strict JSON schema that your downstream systems can parse. The [EXAMPLES] placeholder is crucial for calibrating the model's detection accuracy; provide at least one positive and one negative example. The [RISK_LEVEL] parameter allows you to control the scan's sensitivity without rewriting the prompt, acting as a simple toggle between a high-precision, low-recall scan for noisy repositories and a high-recall scan for sensitive codebases. After pasting the prompt, always test it against a known set of files containing both real and dummy secrets to validate the false positive and false negative rates before integrating it into your CI/CD pipeline.

Integrating a secret scanning prompt into a production workflow requires treating the LLM call as one step in a deterministic pipeline, not as a standalone security product. The prompt is designed to accept a code diff, file content, or repository snippet as [INPUT] and return a structured JSON report. The application layer must manage input assembly, output validation, retry logic, and human review gates. Because false negatives (missed secrets) carry high security risk, the harness must combine this AI scan with deterministic regex-based secret detection tools like detect-secrets, truffleHog, or gitleaks as a baseline. The LLM's value is in contextual classification—distinguishing a test key from a production credential—and in generating remediation guidance, not in being the sole detection mechanism.

The implementation should follow a strict sequence: (1) Pre-process the input to truncate or chunk content exceeding the model's context window, prioritizing recent changes and configuration files. (2) Run deterministic scanners first and attach their findings as [CONTEXT] in the prompt to help the model focus on classification and false-positive triage. (3) Call the model with the prompt template, setting temperature=0 and response_format to json_schema (or equivalent structured output mode) to enforce the expected finding schema. (4) Validate the output against the schema immediately; if validation fails, retry once with the validation errors included in a repair prompt. (5) Post-process findings by deduplicating against deterministic scanner results, flagging any LLM-only findings for mandatory human review. (6) Log every scan with a unique scan_id, the model version, input hash, and raw output for auditability. (7) Route all severity: critical and severity: high findings to a human review queue before automated ticketing or blocking a CI/CD pipeline. Never auto-remediate secrets based solely on LLM output.

For model choice, prefer models with strong code understanding and structured output support. Test across at least two model families (e.g., Claude 3.5 Sonnet and GPT-4o) to compare false-positive and false-negative rates on a golden dataset of known secrets. Build an eval harness that measures precision, recall, and classification accuracy per secret type (AWS keys, JWT secrets, private keys, database connection strings). Track failure modes: the model may hallucinate file paths, misclassify high-entropy strings, or miss secrets embedded in concatenated or encoded formats. Mitigate these by cross-referencing findings with file existence checks, entropy scoring, and decoding pre-processing. When the prompt is used in CI/CD, gate the pipeline on the deterministic scan results and treat the LLM findings as an advisory review layer, not a blocking control, until the eval metrics meet your security team's thresholds.