I built a local prompt scanner to catch secrets before they reach AI chats

#security #privacy #ai #webdev

I kept seeing the same uncomfortable workflow:

Copy an error log, .env fragment, config file, webhook payload, or database URL.
Paste it into an AI chat to debug something faster.
Realize there might have been a key, token, signed URL, phone number, email, or credential-bearing connection string hiding in the paste.

So I built Prompt Leak Guard, a small browser extension and free web demo that tries to catch that mistake before the prompt leaves the browser.

The scanner is intentionally boring: no backend, no analytics SDK, no remote model call, and no account connection. It uses local JavaScript pattern matching in the browser.

Free demo:
https://site-mocha-three-50.vercel.app/prompt-leak-guard-demo

Field notes:
https://site-mocha-three-50.vercel.app/prompt-leak-guard-field-notes

What it checks for

The current QA build has 87 local detector rules. The important categories are:

common AI provider keys and API tokens
AWS, Azure, and GCP credential patterns
signed URLs and SAS-token-style URLs
private key blocks
Slack, Discord, Telegram, and webhook URLs
GitHub, GitLab, Hugging Face, npm, PyPI, Docker Hub, CI/CD, and deployment tokens
Stripe, Twilio, Resend, Postmark, Sentry, Datadog, New Relic, and similar service keys
credential-bearing database, cache, and broker URLs
authorization headers, cookie/session patterns, and URL secret parameters
optional private-data patterns like emails, phones, card-like numbers, and dashed US SSNs

The extension can also generate a redacted version of the text locally.

The false-positive problem was the real work

The first version was easy to make noisy.

The annoying cases were not the obvious secrets. They were things like:

UUID-shaped trace IDs
placeholder values like your_api_key_here
masked values like ********
official documentation examples
Stripe test cards
invalid JWT-looking strings
bare database URLs without embedded credentials
public query IDs that only look scary out of context

So the work turned into making the scanner conservative enough that a warning actually means something.

Some examples from the QA pass:

UUID-only trace IDs stay clear.
Bearer headers containing UUID-shaped request IDs stay clear.
Placeholder config values stay clear.
Bare database URLs stay clear unless credentials are embedded.
Dashed US SSNs without nearby sensitive context are downgraded instead of treated as a guaranteed high-risk secret.
The private-data toggle excludes emails, phones, and SSN-like patterns when a user only wants credential scanning.

What it is not

This is not DLP.

It cannot guarantee that every possible secret format will be detected. Some providers have ambiguous raw tokens with no stable prefix. Some values only become sensitive because of surrounding context. If a real key, token, password, private key, or credential URL may already have been exposed, the answer is still to rotate it.

The goal is narrower: catch common and high-signal leaks before they get pasted into an AI chat.

Why local-only matters here

For this specific tool, a remote scanner felt backwards.

If the point is “do not send this suspicious text somewhere else,” then the scanner should not upload the suspicious text to inspect it.

The browser demo and extension scan locally. The installable extension stores only settings and an offline license code. It does not send prompt text, scan results, or browsing history to a backend.

What I would love feedback on

I am looking for practical detector feedback, especially from people who paste logs/configs into AI tools a lot:

Are there common token formats I am missing?
Are there noisy false positives you would hate seeing in a real workflow?
Should private-data warnings stay separate from credential warnings?
What prompt surfaces besides ChatGPT, Claude, Gemini, and Perplexity would be worth supporting?

Again, the demo is here:
https://site-mocha-three-50.vercel.app/prompt-leak-guard-demo

Disclosure: I used AI coding assistance while building and editing this project, and then manually/automatically tested the product against the cases above. The scanner itself is pattern-based local JavaScript, not an AI model.