API Key and Secret Leak Detection in User Input Prompt

This prompt is designed for platform security engineers, DevRel teams, and API gateway operators who need to scan user-submitted text for accidentally exposed credentials. It belongs at the ingress layer, before user input reaches model context, application logs, error reporting systems, or internal databases. The prompt identifies API keys, access tokens, passwords, connection strings, private keys, and internal endpoint URLs, then outputs a structured detection report with redacted previews and recommended remediation actions. Use this when you need a fast, LLM-based secret scanner that can catch patterns regex-based scanners miss, including credentials embedded in natural language, code snippets, or formatted messages.

Deploy this prompt as a pre-processing guard in your request pipeline. It is ideal for AI platform builders who accept free-text user input and need to prevent secret leakage into training data, log aggregators like Splunk or Datadog, or downstream model context windows. For example, a developer pasting an error log into a support copilot might accidentally include a Bearer token or an AWS AKIA key. This prompt will detect the secret, redact it, and return a structured alert so your application can block the request or sanitize it before it propagates. It is not a replacement for client-side secret scanning in CI/CD pipelines (like git-secrets or truffleHog) or runtime secret management; it is a safety net for user-generated text entering your AI systems.

Do not use this prompt as your sole defense for compliance with standards like PCI-DSS or SOC 2. It is a detection layer, not a prevention control. False negatives are possible, especially with heavily obfuscated or non-standard credential formats. Always pair this with deterministic regex scanning for known patterns and a human review queue for high-confidence detections in production. If your application handles highly regulated data, ensure that any redacted input is still subject to your standard data retention and encryption policies before it is logged or stored.

This prompt template is designed to be integrated into an input sanitization layer, scanning user-submitted text for exposed secrets such as API keys, access tokens, passwords, connection strings, private keys, and internal endpoint URLs. The primary job is to identify and flag these secrets without ever outputting the full secret value, thereby preventing accidental logging, storage, or model context poisoning. Adapt the placeholders to fit your specific secret taxonomy, confidence thresholds, and remediation workflows.

textCopy
Scan the following user-submitted text for exposed API keys, access tokens, passwords, connection strings, private keys, and internal endpoint URLs. Identify each detected secret by type, provide a redacted preview showing only the first 4 and last 4 characters, assess confidence, and recommend a remediation action. Do not output the full secret value under any circumstances.

[INPUT]

[CONSTRAINTS]
- Never output the full secret value.
- Use a redacted preview format: first 4 characters + '...' + last 4 characters.
- If no secrets are detected, return an empty list.
- If the input is ambiguous, flag it with lower confidence and recommend human review.

[OUTPUT_SCHEMA]
{
  "findings": [
    {
      "secret_type": "string (e.g., 'stripe_api_key', 'github_pat', 'jwt_token', 'password', 'connection_string', 'private_key', 'internal_endpoint')",
      "redacted_preview": "string (e.g., 'sk_l...abc1')",
      "confidence": "float (0.0 to 1.0)",
      "remediation": "string (e.g., 'revoke_and_rotate', 'quarantine_input', 'human_review')"
    }
  ]
}

[EXAMPLES]
Input: "My API key is sk_live_abc123xyz789"
Output: {"findings": [{"secret_type": "stripe_api_key", "redacted_preview": "sk_l...z789", "confidence": 0.98, "remediation": "revoke_and_rotate"}]}

Input: "The connection string is Server=db.internal.net;User=admin;Password=SuperSecret123;"
Output: {"findings": [{"secret_type": "connection_string", "redacted_preview": "Serv...t123", "confidence": 0.95, "remediation": "quarantine_input"}, {"secret_type": "password", "redacted_preview": "Supe...t123", "confidence": 0.90, "remediation": "revoke_and_rotate"}]}

Input: "Here is a random string: abc123xyz"
Output: {"findings": []}

[RISK_LEVEL]
High. Leaked secrets in model context or logs can lead to unauthorized access and lateral movement. Always require human review for ambiguous findings.

To adapt this template, replace the example secret types in the secret_type enum with your organization's specific taxonomy. Adjust the remediation actions to map to your internal incident response playbooks, such as automated key revocation via your secrets manager or ticket creation in your security queue. For high-throughput production systems, consider adding a [TOOLS] section that allows the model to call a quarantine API directly. Always pair this prompt with a post-processing validator that confirms the output JSON schema and rejects any response containing a full secret value.

This prompt is designed to operate as a pre-processing guard in your application's ingress layer. It should be invoked before user input is written to any persistent log, stored in a database, or passed to downstream models and tools. The ideal integration point is an API gateway middleware, a reverse proxy filter, or a serverless edge function that inspects the raw request body. The prompt expects a single user input string and returns a structured JSON object indicating whether secrets were detected, what type, a redacted preview, and a recommended action. Because the prompt itself processes potentially live credentials, you must ensure that the model endpoint you call for this check is hosted in a trusted environment with access controls equivalent to your production secret store.

Wiring the prompt into your application involves a synchronous HTTP call to your model provider with a strict timeout (recommend 2–5 seconds). The request should include the prompt template with the [USER_INPUT] placeholder replaced by the raw text. The response must be parsed against a strict JSON schema. If the model returns action: "block", your gateway should return a 422 Unprocessable Entity or 400 Bad Request to the client without echoing the input. If action: "redact", strip the detected secrets from the input before forwarding it. If action: "allow", proceed normally. Implement a retry policy with exponential backoff (max 3 attempts) for transient model errors, but fail closed: if the detection service is unavailable, either queue the input for async review or reject it based on your risk tolerance. Never fail open and allow un-scanned input through.

Validation and logging require extreme care. The model's output JSON must be validated field-by-field: check that action is one of the allowed enum values, detected_secrets is an array, and each secret object contains a type, redacted_preview, and confidence score. If validation fails, treat the input as potentially dangerous and route it for human review. When logging detection events, never log the redacted_preview field if there is any chance it contains a partial secret. Instead, log only the detection type, confidence, and action taken. For audit trails, store a hash of the original input and the detection result, not the input itself. In high-security environments, run this prompt in an isolated execution environment where the model's context window is cleared between requests to prevent cross-request secret leakage.

Model choice and cost optimization matter at scale. This classification task works well with smaller, faster models (e.g., Claude 3 Haiku, GPT-4o-mini, or a fine-tuned open-weight model) because the output structure is constrained and the reasoning is pattern-matching rather than generative. If you process high volumes, consider batching multiple inputs into a single prompt with clear delimiters, but be aware that a single detected secret in a batch may require discarding the entire batch's context for safety. For latency-sensitive paths, deploy a regex-based pre-filter that catches obvious patterns (AWS key formats, JWT headers, connection strings) before calling the LLM. Only send inputs that pass the regex filter but still look suspicious to the model for deeper semantic analysis. This two-tier approach reduces cost and latency while maintaining detection coverage for obfuscated or non-standard secret formats.