I built Prompt Leak Guard because the risky workflow is ordinary now:
- Copy a stack trace,
.envfragment, 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.
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, andpasswordassignments - 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.