Identify what a secrets scanner blocks in user input

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.