I built a local scanner for secrets in AI prompts

Dankerbadge Tools — Thu, 28 May 2026 13:03:16 +0000

I built Prompt Leak Guard because the risky workflow is ordinary now:

Copy a stack trace, .env fragment, config file, webhook payload, database URL, support note, or client snippet.
Paste it into an AI chat or coding agent to debug faster.
Notice too late that the text may have included a key, token, signed URL, credential-bearing connection string, email, or other private detail.

So I made a small local-first scanner for the moment before the paste.

Free scanner:
https://site-mocha-three-50.vercel.app/ai-prompt-secret-scanner?utm_source=devto&utm_medium=community&utm_campaign=free_scanner

Product page:
https://site-mocha-three-50.vercel.app/prompt-leak-guard?utm_source=devto&utm_medium=community&utm_campaign=prompt_leak_guard

What it checks

The public scanner uses local JavaScript heuristics for common patterns like:

OpenAI-style API keys
GitHub tokens
AWS access key IDs
private key blocks
Slack webhooks
credential-bearing database URLs
Stripe keys
JWT-looking tokens
signed URLs
suspicious api_key, secret, token, and password assignments
optional private-data patterns like emails and payment-card-shaped numbers

It also produces sanitized output locally, so the next step is not just "warning: bad". You can copy a safer draft with the detected values replaced.

What changed in v0.1.4

The useful part was not only matching patterns. It was making the next action obvious.

v0.1.4 adds risk receipts. A scan now tries to answer four questions:

What matched?
Why does it matter?
What should I do next?
What would a safer prompt look like?

That matters because "secret found" is too vague when someone is in the middle of debugging. The scanner should help them decide whether to redact, rotate, replace with a placeholder, or describe the system without copying the raw sensitive value.

What it is not

This is not DLP and it is not a guarantee that text is safe to share.

Some providers use ambiguous token formats. Some values are only sensitive because of surrounding context. If a real credential may already have been exposed, the correct answer is still to rotate it.

The goal is narrower: catch common, high-signal leaks before they leave your browser.

Why local-only

For this specific tool, a remote scanner felt backwards.

If the point is "do not send this suspicious text somewhere else," the scanner should not upload the suspicious text to inspect it. The free scanner runs in the browser. The browser utility is also designed as a local warning layer.

Feedback I want

I am trying to find out whether this is actually useful enough to keep improving, so blunt feedback is more useful than vague encouragement.

If you paste logs/configs into AI tools, I would like to know:

Which token formats are missing?
Which false positives would make you stop using it?
Should private-data warnings stay separate from credential warnings?
Which AI prompt surfaces are worth supporting beyond the obvious chat/coding-agent workflows?

The paid package is $4.99 and includes the browser utility/checklist/install notes, but the free scanner is the best way to judge whether the idea is useful first.

Disclosure: I used AI coding assistance while building and editing parts of this project, then tested the scanner behavior against seeded examples. The scanner itself is pattern-based local JavaScript, not an AI model.

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

Dankerbadge Tools — Mon, 18 May 2026 20:29:58 +0000

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.

DEV Community: Dankerbadge Tools

I built a local scanner for secrets in AI prompts

What it checks

What changed in v0.1.4

What it is not

Why local-only

Feedback I want

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

What it checks for

The false-positive problem was the real work

What it is not

Why local-only matters here

What I would love feedback on