API Keys Exposed in AI-Generated Code? What To Do First

If you have found an API key in AI-generated code, treat it as a real exposure until proven otherwise. Do not paste the key into another AI chat, public forum or screenshot. Work out where the key appears, whether it reached a browser bundle, public repository, deployment log or shared screen, then rotate or revoke it where the provider allows. The goal is not panic. The goal is to stop further exposure, understand the blast radius and move secrets into a safer server-side setup.

What an exposed API key means

An API key is a credential used by an app to talk to another service. It might connect to OpenAI, Stripe, Supabase, Firebase, Google Maps, an email provider, a payment service, analytics, storage or another API. Some keys are designed to be public with strict restrictions. Many are not. If a private key is placed in frontend code, committed to a public repository, included in a screenshot or shipped inside a browser bundle, anyone who can see that output may be able to use it.

That does not always mean an attacker has used it. It does mean the key can no longer be treated as secret. A careful AI app security check should separate a visible but low-risk public token from a private credential that can spend money, read private data, send emails or access an admin-level API.

Why frontend code is not private

AI-generated apps often blur the boundary between client-side code and server-side code. A component may work in preview because the key is available locally, but once the app is built for the browser, anything included in the client bundle can be inspected. Minifying the file does not make the secret private. Hiding a value in a variable does not protect it. Client-side checks are useful for user experience, but they are not a safe place for private credentials.

This is why moving secrets server-side matters. A browser should usually call your own protected API route or server function. That server-side code can then use the private key without sending it to every visitor. If the app also has deployment issues, environment variable handling may need to be reviewed alongside production environment variables.

Where AI-generated code commonly exposes keys

Common exposure points include React or Next.js components, frontend utility files, public environment variables, configuration examples, build logs, public repositories, browser network requests, source maps and pasted screenshots. AI tools may also produce placeholder-looking code that a non-technical builder later replaces with a real value. The app appears to work, so the risk is easy to miss.

Examples include payment keys in checkout code, email service tokens in contact-form handlers, database service keys in browser files, OpenAI keys in chat widgets, map keys without restrictions and storage keys used directly from public pages. The exact response depends on what the key can do, where it was exposed and whether the provider offers usage logs or rotation controls.

What to check first without exposing the key further

Start by recording safe evidence. Note the filename, route, deployment platform, commit, screenshot source or browser location where the key appeared. Do not copy the full key into notes if you do not need to. You can usually record the provider name, the first few non-sensitive characters if already visible, and where it was found. If the key is in a public repository, check whether the repository is still public and whether the commit history also contains it.

Next, check the provider dashboard for usage, spending, access logs and rotation options. Do not run random online scanners with the key. Do not paste it into AI to ask whether it is real. If the key controls billing, private data or privileged access, rotate it promptly and update the app to use the new value only from a safe environment.

When to rotate or revoke a key

Rotate the key when a private credential may have reached a browser, public repository, shared screenshot, public support chat, untrusted contractor, build log or client-side bundle. Revoke it immediately if there are suspicious charges, unknown requests, unexpected data access, signs of abuse or if the provider recommends revocation for that key type. Rotation creates a replacement. Revocation disables the old value. Some providers let you do both in stages so the app does not break for users.

After rotation, do not simply paste the new key into the same frontend file. That repeats the mistake. Move the sensitive value into server-side environment variables, API routes, server functions or provider-side configuration. If generated code keeps reintroducing secrets into the browser, a focused AI code repair pass may be needed.

What not to paste into AI tools

Do not paste full API keys, service role keys, database passwords, private tokens, customer data, billing logs, raw request headers or complete environment files into AI tools. You can ask for help using redacted examples. Replace sensitive values with labels such as REDACTED_OPENAI_KEY or REDACTED_SUPABASE_SERVICE_ROLE. Share structure and error messages without sharing the credential itself.

Also avoid screenshots that show keys, customer records, payment details or private dashboard data. If you need technical help, send a safe description of where the key appears and what the app is meant to do. A professional review can ask for access through an appropriate channel instead of a public prompt.

When the exposure is launch-blocking

The issue is launch-blocking when the exposed key can access private data, spend money, send messages, control payments, bypass database rules or perform admin actions. It is also launch-blocking if you do not know what the key can do. A public map token with strict domain restrictions may be lower risk than a database service key in client code, but both still deserve review before real users rely on the app.

If the app is already live and the key may affect payments, user records or production data, pause feature work and consider urgent website help. If the app is not live yet, a calmer diagnosis can identify whether the issue is isolated or part of a wider client/server boundary problem.

API key exposure checklist

• Identify which service the key belongs to and what the key can access.
• Check whether it appears in frontend code, browser bundles, public repos, screenshots or logs.
• Review provider usage logs, spending and recent activity where available.
• Rotate or revoke private credentials that may have been exposed.
• Move private keys to server-side environment variables or protected server functions.
• Remove the old value from current code and review commit history if the repo was public.
• Do not paste secrets, logs with secrets or private data into AI tools.
• Retest the app after rotation so forms, payments, AI features and APIs still work.

What evidence to collect for help

Useful evidence includes the app URL, the affected service, where the key appears, whether the repository was public, whether the app is already live, whether usage changed, what deployment platform is used and whether the key is referenced in frontend or server-side code. You do not need to send the key itself. If user data may be involved, describe the data type without sending records.

If the exposure is part of a broader AI-built app launch, compare it with the checks in the AI app security checklist. Exposed secrets often sit next to weak auth, open database rules or API routes that trust client-side checks too much.

Short conclusion

An exposed API key is not something to ignore, but it is also not a reason to blindly rewrite the whole app. Preserve safe evidence, rotate or revoke the credential where appropriate, move secrets out of the browser and get the app reviewed before real users, payments or private data depend on it.