An OpenRouter API key sends requests to many language models through a single account, and every request is paid for from your prepaid credits. Whoever holds the key can spend those credits on any model your account can reach, including expensive ones. The risk is mostly financial and it grows fast, so the order of work is: delete the key, then look at what it spent.
Check your GitHub account for leaked secrets — free
- Provider
- OpenRouter
- Severity
- High
- Impact
- SaaS account access and billing
- Checked live by LeakWatch
- Yes
- Revoke at
- OpenRouter
What an OpenRouter API key looks like
OpenRouter keys start with sk-or-v1- followed by a long string of letters and digits:
sk-or-v1-…XXXX OpenRouter API key (masked)
The sk- start is shared with OpenAI keys, which causes mix-ups. An OpenRouter key has the or segment and a version number after it; an OpenAI key does not. A DeepSeek key is sk- followed by plain hex digits. If you are unsure, compare with the OpenAI API key and DeepSeek API key guides.
Because OpenRouter speaks the OpenAI request format, the key is frequently stored under OPENAI_API_KEY with a custom base URL. A value starting with sk-or- under that name is still an OpenRouter key.
How OpenRouter keys get leaked
- AI app templates. Starter projects for chat apps and agents with
OPENROUTER_API_KEYin a committed.env. - Open-source agent configs. Settings files for coding assistants and agent frameworks, where the key sits next to the model name.
- Front-end calls. A browser app calling OpenRouter directly, which exposes the key to every visitor.
- Notebooks and demos. A key set in a cell and shared along with its outputs.
- Logs. Debug output that prints request headers, or an issue that quotes a failing request including its
Authorizationheader. Chat apps that let users paste their own key can also leak it through analytics or error tracking.
What to do in the first hour
- Create a replacement key. In OpenRouter, go to Settings and the Keys page and create a new key. Give it a name, and set a credit limit on it if the option is offered, so a future leak has a ceiling.
- Deploy the new key to every app and agent that used the old one. Use one key per application, each with its own limit, so the next incident stays small.
- Delete the exposed key on the same Keys page. A disabled-but-present key is still a risk if it can be re-enabled; deletion is cleaner.
- Audit the activity. Open the Activity or logs view and check requests since the exposure: models you never call, a burst of requests, large token counts or unfamiliar client names are the signs.
- Check your credits. Compare the current balance with what you expect. If the balance dropped without a matching change in your own traffic, note the amount and the dates, and contact OpenRouter support with the key’s name. Whether a refund is possible is their decision.
- Turn off automatic top-ups until you finish checking. If auto top-up is enabled, a leaked key can keep draining a refilled balance. Review it on the credits page, and keep the balance low while you investigate.
Not sure what else leaked? Run a free scan.
- Then clean the repository: remove the value and rewrite history if you want to. See I accidentally pushed an API key to GitHub.
Revoke it at OpenRouter
Go to openrouter.ai/settings/keys, find the key by its name (the full value is shown only at creation), and delete it. If you use organization or provisioning features, check there too, as keys can be created from more than one place.
How LeakWatch detects it
The rule is called OpenRouter API Key. It matches the literal sk-or-v prefix, a version number, a dash, and at least 32 letters and digits, with word boundaries on both sides. The OpenAI rule explicitly excludes this prefix, so one key is not reported twice under two vendors. This type is checked live: LeakWatch can check whether a detected key is still active with a read-only request to the endpoint that returns information about the key itself. It never reads your data and never spends credits.
LeakWatch can check whether a detected key is still active with a read-only request to OpenRouter. It never reads your data or spends your credits.
FAQ
Does a credit limit on the key protect me?
It caps what that key can spend, which is why it is worth setting. It does not replace deletion after a leak: until the key is deleted, it can still use up whatever limit remains.
Can someone see my other keys or my account details?
An inference key calls models; it is not a login to your account. It does not let a stranger sign in, change your billing settings or read your other keys, but it can use your credits, so the checks above still apply.
I use OpenRouter through a library. Where is the key stored?
Check environment variables, the library’s config file and any secrets set in your hosting dashboard. A key that is still working after you deleted it from the repository is usually set in one of those places.