The API key your AI app is serving to the world
AI apps ship fast — and a startling number serve their own .env, config, or build output straight to the public web, leaking live OpenAI, Anthropic, AWS and database keys. There’s no exploit: anyone who loads the URL gets the key — and with it, drained API budgets, hijacked models, and access to your data. We find these passively — a single anonymous, read-only request, exactly what a browser makes loading the page.
Why this is dangerous
An API key in a served .env isn’t a vulnerability that needs an exploit — it’s a password sitting in public:
- • LLM keys get drained instantly. Bots scrape exposed OpenAI/Anthropic keys and resell the access — you get the bill, often thousands of dollars before you notice.
- • Cloud keys become a foothold. A leaked AWS/GCP key can read your storage, spin up compute to crypto-mine, or pivot deeper into your infrastructure.
- • It’s the classic “vibe-coded” mistake — shipping the real
.envinto thepublic/,dist/orbuild/folder, or leaving.gitexposed. Automated scrapers find these within minutes.
What the radar has done so far
We refuse to inflate the count. Most public .env paths on the internet are honeypots or copied templates serving the same fake keys — we filter every one of those out. A confirmed exposure is a unique, real secret served by a single host.
No confirmed live exposures in the current sample — and that’s the honest result of filtering hard. We’ve scanned 2,311 domains and discarded 104 honeypots and copied templates serving fake keys. Confirmed exposures appear here as the radar rotates through more of the internet.
Are you exposed?
Check whether your app is serving a .env, config file, or secret-bearing bundle — a free, passive scan of your own internet-facing surface, no signup.
How it works
How do you detect this without hacking anything?
A single anonymous, read-only GET of a public URL — the exact request a browser makes loading a page. If a path that should never be public (like /.env) returns config-shaped content containing a real secret, that’s the finding. We never log in, run exploits, or write anything.
Do you ever use or test the keys you find?
Never. Validating a key against its provider would be unauthorized use — and could run up the victim’s bill. We detect the key’s shape and entropy, store only a redacted fingerprint (never the raw value), and notify the owner so they can rotate it.
Why is the count sometimes low?
Because we refuse to inflate it. The internet is full of honeypots and copied starter-templates that serve the same fake keys on /.env; we filter every one of those out. A finding is counted only when a unique, real secret is served by a single host — so the number is small but honest.
Why don't you list the affected hosts?
Publishing them would be a target list. We keep host details private for responsible disclosure to affected owners and publish only aggregate counts. Use the scanner above to check your own exposure.
EchelonGraph-<Radar>/1.0 (+echelongraph.io/responsible-disclosure; security@echelongraph.io) and a From: security@echelongraph.io header. It is a single, passive, read-only check — we never log in, exploit, write, or read your data. Who we are, how we confirm exposures read-only, and how to opt out → Genuine requests also carry a signed receipt you can validate at /verify-scan.