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, and so far we’ve found 1,929 of them.
Beyond keys — catastrophic data & source exposure
The same passive radar now confirms the highest-impact web exposures — an open .git repo, a database dump, a Spring Boot heap dump, a private key, or an application log — each found with a single anonymous, read-only request. We confirm the resource is served; we never download it, clone it, or log in.
By provider — and what the key unlocks
How they're leaking
- an exposed .git repo — full source downloadable709
- a cloud/credentials file (.aws, .npmrc, docker)179
- html-inline124
- a database dump — full data72
- js-bundle47
- open-s3-bucket39
- an application log — PII, tokens, stack traces19
- .env served on the public web11
- open-gcs-bucket7
- an exposed .git/config5
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.
Frequently asked questions
What is the Exposed AI Keys & Config Radar?
It finds live web apps that serve their own .env, config or build files to the public internet, leaking API keys for OpenAI, Anthropic, AWS, databases and more. EchelonGraph detects these passively and publishes only aggregate, host-redacted counts.
How does an API key end up in an exposed .env file?
A misconfigured deployment serves the project directory — including .env, config files, or source-map and build output — over HTTP. Anyone who requests a path like /.env downloads the secrets directly. No hacking is involved; the app hands them out.
How does EchelonGraph detect leaking apps?
It passively requests common config and secret paths on public web apps and validates that the response actually looks like a live secret. It is detect-only and never uses any key it finds. Findings are reported in aggregate, with hosts redacted.
My app might be leaking secrets — how do I fix it?
Stop serving dotfiles and config (block /.env, /.git and /config at the web server or CDN), move secrets into environment variables or a secret manager, and rotate every exposed key immediately — assume any key that was publicly reachable is already compromised.
EchelonGraph-<Radar>/1.0 (+echelongraph.io/responsible-disclosure; support@echelongraph.io) and a From: support@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.