An Exposed OpenAI or Anthropic Key Is Someone Else's Bill on Your Card

You wired an AI feature into your app — a chatbot, a summarizer, something that calls OpenAI or Anthropic — and now you're wondering where your API key actually lives. If it's in your frontend, a stranger could be running requests on your account right now, and the bill lands on your card.

Unlike a Stripe publishable key or a Supabase anonymous key, an LLM API key (LLM = large language model, the AI behind OpenAI and Anthropic) is never public by design. It's a secret, it's metered, and exposing it has two real costs: someone runs up your bill, and they can siphon data through your account. This is one of the exposed-key cases that truly warrants action.

The reassuring part: it's fixable, usually in minutes, and you can cap the worst-case damage in advance. This post explains why these keys are dangerous when exposed, where they're supposed to live, how to check whether yours is out there, and how to lock it down.

⚡ TL;DR

• OpenAI and Anthropic API keys are secret and metered — unlike a Stripe pk_live or Supabase anon key, they are never meant for the browser.
• If yours is exposed, attackers can run requests that bill your account and reach data that flows through it. This is a real emergency, not a false alarm.
• These keys belong server-side only — a backend route or an edge function — never in frontend code.
• The fix is fast: rotate the key, set a hard usage limit, and move it server-side so it never ships to the browser again.

Why an exposed LLM key is a real problem

It's worth being clear about why this one is different from the false alarms. A lot of "exposed key" warnings are noise — public-by-design keys that are supposed to be in the browser. An OpenAI or Anthropic key is not one of those. Two things make it risky when exposed:

1. It's metered — every request costs money. These keys bill per use. Whoever holds your key can fire off requests as fast as they want, and you pay for all of it. Attackers actively scan for exposed LLM keys precisely because they're a free meter running on someone else's card. An exposed key with no spending cap is an open tab.

2. It can reach your data. An API key isn't just a payment method — it's authority on your account. Depending on the provider and how your account is set up, whoever holds the key can route requests through your account and access data that passes through it. The exposure isn't only financial; it's a foothold.

This is exactly what made the Moltbook incident so pointed. In January 2026, Wiz researchers found that a Supabase-backed AI social network had missing RLS (RLS = Row Level Security, the database rules that decide which rows each user can read). Through that gap, attackers could pull around 1.5 million API keys and roughly 35,000 user emails — and some of the app's private direct messages contained plaintext OpenAI keys that users had pasted in. Those are live, metered, secret keys sitting in the open. Anyone who scraped them could spend on those accounts and reach whatever those keys could touch. Someone else's bill, on someone else's card.

Where these keys must live

The rule is simple: OpenAI and Anthropic keys belong on a server you control, and nowhere a browser can see them.

In practice, that means one of:

• A backend API route on your own server.
• A serverless or edge function — a Supabase edge function, a Vercel or Netlify serverless function, a Cloudflare Worker. These run on the provider's servers, not in the user's browser, so the key stays hidden.
• A server-side environment variable that is never prefixed with VITE_, NEXT_PUBLIC_, or REACT_APP_. Those prefixes exist to ship values to the browser, which is the last thing you want for a secret.

The correct shape of an AI feature looks like this: your frontend sends the user's input to your server (or edge function); your server holds the secret key and calls OpenAI or Anthropic; your server returns the result. The key never leaves your backend. The browser only ever talks to you.

The wrong shape — and the one AI builders fall into when they optimize for a quick working demo — is calling OpenAI or Anthropic directly from the browser with the key embedded. It works instantly in a preview, which is exactly why it slips through. But it ships your secret to every visitor.

⚠️ Watch out

If your app calls api.openai.com or api.anthropic.com directly from the browser, your key is almost certainly exposed — even if you can't see it at a glance. The browser has to send the key to reach those endpoints, which means it's in your frontend code. Move the call server-side.

How a key ends up in your frontend

If your LLM key did leak, it likely took one of these routes — all common in AI-built apps, none of which mean you did anything foolish:

• The AI hardcoded it. You asked your builder to "add an AI chatbot," and the fastest path to a working demo was to drop the key into client-side code.
• It's behind a public build prefix. A key stored as VITE_OPENAI_KEY or NEXT_PUBLIC_ANTHROPIC_KEY gets baked into the frontend bundle by the build tool, exactly as the prefix instructs.
• It's in a published source map. If you shipped source maps to production, your original code — key included — can be downloaded and read even if it's not visible in the minified bundle.

In every case the secret reaches the browser, where anyone can read it. Minifying your code doesn't hide it — a simple text search across your bundle finds key patterns like sk- and sk-ant- in seconds. We walk through exactly how that extraction works in how attackers extract secrets from JS bundles, and the broader picture lives in the pillar guide, exposed secrets and API keys in frontend code.

How to check your own app

You can find out whether your LLM key is exposed in about ten minutes.

1. Open your live app and open browser developer tools (right-click → Inspect, or F12).
2. Search the loaded JavaScript (Ctrl/Cmd-Shift-F in dev tools) for sk- (OpenAI) and sk-ant- (Anthropic). Finding either in browser-delivered code means your key is exposed.
3. Check the Network tab while you use the AI feature. If you see requests going straight to api.openai.com or api.anthropic.com from the browser, the key is shipping client-side. Look at the request headers — the key rides along in the Authorization header.
4. Search your code and environment variables for any LLM key behind a VITE_, NEXT_PUBLIC_, or REACT_APP_ prefix. Those ship to the browser.
5. Look for published source maps (readable, un-minified code or .map files in the Sources tab), where a key can hide even when it's absent from the bundle.

This catches the common cases. It won't catch a key buried in a lazily-loaded chunk or a third-party script, which is the gap an automated scan closes.

How to fix it: rotate, cap, relocate

If you found an exposed LLM key, here's what to do. It's fixable, and the steps are quick.

1. Rotate the key now. In your OpenAI or Anthropic dashboard, create a new API key and revoke the old one. Revoking is what makes the exposed key worthless, so do this first. Until the old key is revoked, it's still a live meter.
2. Set a hard usage limit. Both providers let you set spending or usage caps on your account. Set one now, before you do anything else with the new key. A cap means that even if a key leaks again, the worst-case bill is bounded instead of open-ended. This is the single best protection against the cost risk.
3. Move the new key server-side. Don't paste it back into frontend code — that recreates the leak. Put it in a backend route or an edge function, stored in a server-only environment variable, and have your frontend call your server instead of the AI provider directly.
4. Check your usage logs. Look at your provider's usage dashboard for spikes or unfamiliar activity while the old key was exposed. Unexpected usage tells you the key was being abused; if you contact the provider about fraudulent charges, that record helps.
5. Re-check your bundle. Confirm the new key isn't shipping to the browser the same way the old one did.

For the full, provider-agnostic playbook — rotate, then audit, then monitor, in that order — see a key just leaked: rotate, audit, monitor.

FAQ

Can someone really run up my OpenAI bill with a leaked key?

Yes. OpenAI and Anthropic keys are metered, so every request made with your key bills your account. Attackers scan for exposed keys specifically to spend on someone else's card. This is why setting a hard usage cap matters — it bounds the worst case — and why you should rotate an exposed key immediately.

Is my OpenAI or Anthropic key safe in the frontend if I obfuscate it?

No. Obfuscation and minification don't hide a key — anyone can read your shipped JavaScript with browser dev tools and find key patterns like sk- or sk-ant- with a text search. The only real protection is to keep the key off the frontend entirely and call the provider from your server.

Where should I store my LLM API key?

On a server you control — a backend API route, a serverless function, or an edge function — in an environment variable that is never prefixed with VITE_, NEXT_PUBLIC_, or REACT_APP_. Your frontend calls your server; your server holds the key and calls OpenAI or Anthropic.

I rotated my key and set a limit. Am I safe now?

Rotating revokes the exposed key, and a usage cap bounds future risk — those are the two big moves. After that, move the new key server-side so you don't recreate the leak, check your usage logs for any abuse while the old key was out, and keep scanning, because a new deploy can reintroduce the same gap.

The bottom line

An exposed OpenAI or Anthropic key is one of the exposed-secret cases that's worth acting on — not a public-by-design false alarm. These keys are secret and metered, so a leak means strangers spend on your account and can reach data flowing through it, exactly as the Moltbook DMs showed. The fix is fast and fully in your control: rotate the key, set a hard usage limit, and move it server-side. An attacker can find an exposed LLM key in your bundle in minutes. The point is to find it first, and to keep checking, because your AI ships new code on every deploy.