How to Detect API Keys Before Text Reaches an LLM
Detect likely API keys, JWTs, private keys, and cloud credentials before logs, code, tickets, or retrieved text are sent to an LLM.
Short answer
Scan the text before the outbound model call, block or redact when findings are present, and return only secret types and positions to the orchestration layer. Never echo suspected secret values into logs or alerts.
The failure this prevents
Agents routinely handle code snippets, configuration, logs, support tickets, and retrieved documents. A credential copied into any of those surfaces can travel into prompts, traces, vector stores, or third-party tools unless the pipeline checks first.
Recommended workflow
- Place the scan immediately before every boundary where text leaves its current trust zone.
- Pass the candidate text to a deterministic detector.
- If findings are present, block the transfer or route the text through redaction.
- Report finding types and positions without copying the suspected value.
- Maintain application-specific detectors for proprietary credential formats.
Working starting point
curl https://api.scrubmytext.com/v1/detect-secrets \
-H "Authorization: Bearer smt_live_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"PASTE_TEXT_TO_CHECK_HERE"}'Relevant product: DetectMySecrets · Browser + REST + MCP
Decision rule
Do not send the original text downstream when a finding is unresolved. Detection and redaction are different jobs: detection tells you whether to block; redaction produces transformed text.
Good fit
- Agents process logs, repositories, tickets, or configuration.
- Text may be stored by another model, vendor, or observability system.
- You need findings that avoid returning the suspected credential value.
Use another approach when
- You require full repository history scanning or credential revocation; use dedicated secret-management tooling as well.
- Your credential formats are entirely proprietary and no custom detector exists.
- You are treating a clean scan as proof that no secret is present.
Options compared
| Option | Strength | Important limitation | Best fit |
|---|---|---|---|
| DetectMySecrets | Finds likely secret patterns without returning values | Cannot know every custom credential format | Block-or-review gates |
| RedactMyText | Produces transformed text for downstream use | May remove useful text and is still pattern-based | Continue-after-redaction workflows |
| Repository scanner | History, commits, and developer workflow coverage | Not designed for every runtime prompt | Source-control protection |
| Secret manager | Controls legitimate credential storage and access | Does not inspect arbitrary text by itself | Credential lifecycle and retrieval |
Implementation cautions
- Rotate a real exposed credential; removing it from a prompt does not undo exposure.
- Scan before logs and traces, not only before the model call.
- Treat high-entropy custom tokens as an application-specific extension.
Frequently asked questions
Why not return the matching value?
Returning the value would replicate the secret into another response, log, or agent context. Types and positions are safer for orchestration.
Is secret detection the same as secret management?
No. Detection finds likely accidental inclusion; a secret manager controls authorized storage, issuance, rotation, and access.
What happens after a finding?
Block, redact, or require review. If the credential may already be exposed, rotate it through its issuing provider.
Related decisions
Next step
Use the product page for exact limitations and access requirements, then copy the corresponding REST or MCP workflow.