An input secrets-scanner uses regular expressions and entropy heuristics to detect strings that look like , for example AWS access keys, GitHub tokens, JWT secrets, and database connection strings, and either redacts them or blocks the request before the model ever sees the value.
An **input secrets-scanner** sits in the request path before the LLM call. Its job is to detect strings in the user's prompt that look like **secrets**, credentials your business cares about not leaking, and either redact them or block the request entirely.
The two main detection techniques are:
- **Regular expressions** for known credential formats. AWS access keys start with AKIA followed by 16 uppercase alphanumerics. GitHub personal-access tokens start with ghp_, ghs_, or github_pat_. JWTs are three base64 segments separated by dots. Stripe secret keys start with sk_live_ or sk_test_. Each provider publishes the format and good scanners ship hundreds of these patterns.
- **Entropy heuristics** for unknown formats. A random 32-character string has high Shannon entropy compared to English prose. A scanner flags any token in the input whose entropy exceeds a threshold as a candidate secret.
When a secret is detected, the scanner has two actions: **redact** (replace with [REDACTED] or [API_KEY]) or **block** (refuse the request and tell the user). Redact preserves the user's flow at the cost of slightly degraded model context; block is safer for highly regulated environments.
The layer matters because anything the user puts in the prompt is forwarded to a third-party API (OpenAI, Anthropic, AWS Bedrock), logged in observability tools, and sometimes retained in conversation history. Stripping secrets at the gateway prevents downstream exposure.
An **input secrets-scanner** is a regex plus entropy classifier that runs before the LLM call to detect and redact credentials in user input. The category covers API keys (AWS, GCP, Azure, GitHub, Stripe, OpenAI, Anthropic), authentication tokens (JWT, OAuth bearer), database connection strings with embedded passwords, SSH private keys, and high-entropy strings that match no known format but look secret-shaped.
The detection runs two passes:
- **Pattern pass.** A library of provider-specific regexes (the same patterns GitHub's push-protection and TruffleHog use) matches known credential formats. This catches the long tail of common provider tokens with high precision.
- **Entropy pass.** For tokens not matched by a known pattern, the scanner computes Shannon entropy and flags anything above a threshold (typically 4.5 bits per character for base64-style alphabets). This catches custom internal credentials whose format the scanner does not know.
The action on detection is configurable. **Redact** replaces the secret with a placeholder ([REDACTED_AWS_KEY]) so the conversation continues. **Block** refuses the request and surfaces a message to the user. Most production deployments choose redact for low-risk patterns and block for high-risk ones (private keys, banking tokens).
Why it matters: every prompt is forwarded to a third-party API, logged in observability tools (Langfuse, Helicone, Datadog), retained in conversation history, and sometimes used for training feedback. A secret in the prompt becomes a secret in all of those places. The input scanner is the single chokepoint where you can strip it before it propagates.
Quick reference
TL;DR
Secrets-scanners detect API keys, tokens, and credentials in user input via regex and entropy heuristics, then redact or block before the prompt reaches the model.
Imagine you have a smart helper who reads every message you send, then forwards it to a stranger across town to get an answer. One day you accidentally paste your house key, your bank PIN, and your safe combination into the message. The stranger now has all of them. A secrets-scanner is a friend standing at the door who recognises what house keys and PINs look like (the shape, the length, the weird mix of characters), and either covers them with a black marker or refuses to send the letter at all. The friend cannot prevent you from pasting them in, but they can stop the leak before it reaches the stranger.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Strictly internal deployments where the model is fully on-premise and no third-party API is involved The exfiltration surface is much smaller; logging and conversation-store controls may dominate
Use cases where the user legitimately needs to provide a credential (developer-tooling assistants that test API keys) Blocking the legitimate use case breaks the product; a context-aware policy is required instead of unconditional scanning
Prompts that have already been validated by an upstream gateway with the same scanner Duplicate scanning adds latency without additional coverage; configure the boundary once
Quick scan · 2–4 min
Everything important, quickly.
5 minutes: what categories of secrets the scanner detects, the regex plus entropy detection model, where it runs in the request path, and how it composes with output-side PII redaction.
Real-world examples
Real products, models, and research that use this idea.
1GitHub push-protection uses the same regex library to detect secrets in commits before they reach the remote repository
2AWS Bedrock Guardrails sensitive-information filter includes regex patterns for AWS credentials, AKIA-prefix keys, and IAM tokens
3Lakera Guard ships a dedicated secrets-detection module with about 200 provider patterns plus entropy fallback
4Protect AI Rebuff includes secrets-scanning as part of its input-rail composition for LLM applications
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you tune a secrets-scanner to minimise false positives without missing critical credentials in a multi-tenant SaaS?
Sign in or go Pro to see the approach for this follow-up.
QA developer pastes a real production API key into a chat prompt. The scanner redacts it. What other systems need to know the leak happened?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Relying only on the model's RLHF to refuse to repeat secrets, rather than scanning the input before it reaches the model and a third-party API.