Your AI agent just wrote an API key directly into the code. Can your users see it?

Mik Bry · 2026-08-25 · ~8 min read · KB · Launch Readiness

Your AI coding tool needed to talk to Stripe, or OpenAI, or some other service, so it asked you to paste in an API key — and then it wired that key into the code. Reasonable enough. What's not obvious, if you don't code, is that "wired into the code" sometimes means "wired into the code your users' browsers download." Not stolen. Not breached. Just sitting in plain text, one right-click away.

This is the check I keep coming back to when I look at an AI-built app, because it's fast, it's zero-code, and it's the one where "I didn't touch anything" isn't actually the reassurance it sounds like.

01 — What is it?

An API key is a password, except it's not for you — it's for one piece of software talking to another. When your app needs to charge a card through Stripe, or call OpenAI to generate some text, it has to prove it's allowed to make that request. The API key is that proof: a long string your app sends along with every request, the same way you'd type a password to prove it's really you logging in. It's a handshake between two systems, not between a person and a system.

That framing — machine password — covers most of it, but the details of what kind of key matter. A house key is the simplest case: whoever holds it gets in, full stop. Some API keys work exactly like that. Others behave more like a library card: it gets you into the building and lets you borrow books, but not into the manager's office or the cash register — the access is scoped to specific things. Good key design uses library-card keys wherever possible. An AI-generated integration may use a broader credential than the task actually requires, and a founder reviewing the result rarely has a way to tell which one it is.

Here's the part that actually differentiates this from "don't commit your .env file" advice you may have already heard. A particularly easy leak to create in an AI-built frontend is a key built directly into the code your users' browsers run, not into a file that got pushed to GitHub by accident. Frameworks like Next.js and Vite have a specific naming convention for this: any environment variable prefixed NEXT_PUBLIC_ or VITE_ gets bundled into the public JavaScript your site ships, by design — that's documented, intended behavior, not a bug. It exists because some values genuinely need to reach the browser. The problem is an AI agent reaching for that prefix out of habit, for a value that was never meant to leave your server, because it's the fastest way to make an error go away.

02 — Why should you care if you don't code?

Because the consequence isn't abstract — it's a bill, or it's your users' data. If your OpenAI key is sitting in your public JavaScript, anyone who opens dev tools can copy it and start making calls on your account, and you find out when the invoice arrives, not before. If it's a Stripe key with the wrong scope, someone can potentially read payment data that belongs to your users, not you. This isn't an edge case reserved for large companies. It's also one of the easiest findings to make concrete, because an exposed value can sometimes be shown directly in the browser.

There's a precision worth getting exactly right, because the intuitive version of it is wrong: an API key doesn't behave like an interactive password. You'd notice if someone logged into your email — there's a session, a device, maybe a "new sign-in" email. API-key use usually doesn't produce the same user-facing sign-in signals as an interactive login. Unlike an interactive password, an API key may stay usable until it expires or someone revokes or rotates it — so a leaked key can keep working quietly, for weeks, without anything that looks like "someone logging in." Nobody has to breach anything. The key was already sitting there, working exactly as designed, for whoever found it.

This pattern is easy to create when an agent is optimizing for a demo that works. That makes it worth checking explicitly rather than assuming a working integration kept every credential in the right place.

03 — What does good look like?

You don't need to read code to get most of the way here. Look for:

• Secrets live server-side only — API keys for Stripe, OpenAI, or any paid service should never be readable from a file your browser downloads.
• Sensitive credentials stay on your server, not on the user's device. If your app needs to talk to a paid or private API (payments, LLMs, email, storage), the credential should live on your server. Your app calls your server; your server calls the paid API on the app's behalf and passes back only the result. This applies to browser code, mobile-app bundles, and desktop-app code alike — anything running on someone else's machine is extractable, regardless of framework or file naming. NEXT_PUBLIC_ / VITE_ prefixes are one common way this rule gets accidentally broken, but they're not the only one.
• Keys are scoped, not universal — a library-card key where a library-card key is available, rather than a house key handed out by default.
• There's a plan for revoking or rotating a key, not just for issuing one — since a key can keep working long after it should have stopped.

And here's the zero-code first check, the one you can run yourself in under a minute: open your live site, right-click anywhere, choose "View Page Source" (or press F12 to open developer tools and look at the page's source), and search — Ctrl+F or Cmd+F — for key, sk-, and token. If any of those turn up a long string that looks like a real credential sitting in plain text, that's worth investigating immediately.

I want to be precise about what that check actually tells you, because it's easy to over-read: this is a first check, not proof that nothing is exposed. A clean result means the easy, obvious version of this problem isn't visible on the one page you searched — not that no secret anywhere in your app is exposed. Keys can be built into JavaScript files loaded from other pages, other bundles, or behind a login you didn't check from. Treat a clean F12 search as "nothing jumped out," not as a certificate.

References: Fencer's "How to Secure Your Vibe Coded App" (fencer.dev) walks through this exact self-test for AI-built apps. On the framework side, see the official Next.js environment variables docs and the Vite env & mode guide for how each framework decides what gets bundled into public code. For the broader discipline, OWASP's Secrets Management Cheat Sheet and GitHub's push protection documentation are both worth a read if you want the fuller picture.

04 — What can you safely ask your AI agent?

You don't have to run the search yourself — you can ask your AI coding tool to do it, with wording that keeps the same "not found ≠ doesn't exist" honesty as the F12 check above. Paste this in as-is:

Read what it finds before acting on it. If it lists secrets that ship to the browser, that's your priority list — but this article stops at "here's what I found," not "here's how to fix it," on purpose. Moving a key server-side, reissuing it, and revoking the exposed one is real work worth getting right, and it's a conversation for whoever's technically responsible for this project, not a follow-up prompt you paste in on your own. Anthropic's own guidance on API key best practices is a good primer if the key in question is for an AI provider specifically.

This is one article in the Launch Readiness KB series, which walks through what a Trust Report scan actually looks for before you launch, hire, or raise on an AI-built app — one concept per article, always ending in something safe to ask your agent, never something that changes your code.