You typed a few prompts, watched an AI assistant scaffold your app in minutes, and shipped it. It works. Users are signing up. Everything feels fine.
Then someone opens your browser's developer tools, clicks the Network tab, and finds your OpenAI key sitting in plain text in a JavaScript file anyone can download.
This isn't a rare edge case. It's one of the most common outcomes of AI-assisted app development, and it's happening at a scale that security researchers are still trying to fully measure. Tools like Cursor, Lovable, Replit, Bolt, and various "vibe coding" platforms are extraordinarily good at producing working software quickly. What they're not good at, by default, is producing software that keeps secrets secret.
If you built an app with heavy AI assistance in the last year or two, there's a real chance it's exposing credentials right now without you knowing it.
Why AI Coding Tools Leak Keys So Often
AI code generators optimize for one thing above all: getting the feature to work. When you ask an assistant to "connect this app to the Stripe API" or "add a weather widget using this API key," the fastest path to a working demo is often to paste the key directly into the code that calls the API. If that code runs in the browser, the key ships with it.
This isn't a hypothetical failure mode. Industry secret-scanning data has tracked a sharp rise in exposed credentials tied to AI-assisted development. GitGuardian's 2026 State of Secrets Sprawl report found that commits produced with AI assistance leaked secrets at roughly twice the rate of human-written commits, and that credentials tied specifically to AI services climbed sharply year over year. Separate research scanning mobile apps built with AI tools found hardcoded API keys and tokens in a large share of the apps tested.
A few patterns explain most of the damage:
Client-side calls to paid APIs. The AI writes a fetch request straight from the frontend to a third-party service, embedding the API key in code that ends up in the user's browser or the compiled mobile app.
Hardcoded secrets instead of environment variables. Rather than referencing a .env file, the generated code contains the literal key string, which then gets committed to version control.
Missing .gitignore entries. The AI creates a .env file correctly, but never adds it to .gitignore, so the first git push sends it straight to a public GitHub repository.
Default-open backend configurations. Backend-as-a-service platforms like Firebase and Supabase are secure only once access rules are explicitly configured. AI-generated code frequently skips that step, leaving not just API keys but entire databases readable by anyone with the URL.
None of these mistakes require a sophisticated attacker to exploit. They just require someone to look.
Real Incidents, Not Theoretical Risk
Skeptics sometimes assume this is an overstated problem. The incident record says otherwise.
In 2025, a vulnerability affecting apps built on the Lovable platform came from a missing Supabase security setting: generated applications weren't enabling row-level security, the access control layer that determines who can read or write database records. A scan of over a thousand public Lovable apps found hundreds of vulnerable endpoints leaking user data across roughly 10% of the platform's publicly accessible projects.
Around the same time, a popular app used unauthenticated cloud storage to hold user-uploaded files. Tens of thousands of images, including identity verification documents, were exposed with no login required, followed days later by a second flaw that exposed over a million private messages through an API endpoint with no access checks at all.
In early 2026, an AI-built social platform whose founder said he hadn't written a single line of code himself leaked more than a million API authentication tokens along with tens of thousands of user email addresses, all within days of launch. A separate scan of iOS apps built with AI tools found that the overwhelming majority contained some kind of security misconfiguration exposing sensitive data.
What these cases have in common isn't sophisticated hacking. It's the absence of a code review step that would have caught a basic configuration mistake before real users ever touched the product.
How to Check If Your App Is Leaking Keys
You don't need a security team to run a first pass on your own app. Here's a practical order of operations.
- Search your own frontend code
Open your app's compiled JavaScript, or the source if you have it, and search for terms like key, secret, token, and Bearer. If you see a real-looking string sitting next to one of these terms in a file that ships to the browser, that's a leak. Anything that runs client-side is visible to anyone who opens dev tools, regardless of how the AI tool structured the request.
- Check your browser's Network tab
Load your app, open dev tools, and watch the Network tab while you use every feature. Look at the request headers and URL parameters for outgoing calls to third-party APIs. If a key appears anywhere in a request your own browser is sending, it's already exposed to every user.
- Scan your Git history, not just your current code
Deleting a secret from your latest commit doesn't remove it from your repository's history. Anyone can check out an old commit and find it. Tools like git log -p combined with a search for common secret patterns, or dedicated secret-scanning tools such as truffleHog or Gitleaks, can surface keys buried in past commits, even ones you thought you'd cleaned up.
- Review your backend access rules directly
If you're using Firebase, Supabase, or a similar backend-as-a-service platform, log into the console and manually review the security rules or row-level security policies. Don't assume the AI configured them correctly just because the app functions. A database can serve data perfectly while being completely open to the public internet.
- Look for exposed .env files
Try navigating directly to yourapp.com/.env in a browser. Misconfigured servers sometimes serve this file as plain text instead of blocking it, handing over every environment variable your app depends on.
- Check whether your repository is public
If your code lives on GitHub, confirm the repository's visibility setting. AI coding assistants sometimes initialize new projects with a public repository by default, and it's easy to miss during a fast build.
If you'd rather not do all of this manually, or you want a second check after fixing what you find, a service like PrivacyReport can scan a live app and flag exposed credentials, open API endpoints, and other data-leak indicators you might otherwise miss, which is a useful sanity check before you consider a launch complete.
What to Do If You Find a Leaked Key
Finding an exposed key is unpleasant but fixable. Speed matters more than perfection here.
Revoke the key immediately. Every major API provider has a dashboard where you can invalidate a compromised key in seconds. Do this before anything else, even before you've fixed the underlying code.
Issue a new key and store it server-side. Never place the replacement in frontend code either. Route the API call through your own backend, which holds the key privately and forwards requests on the user's behalf.
Remove the secret from Git history. Deleting it from the current file isn't enough. Use a tool like git filter-repo or BFG Repo-Cleaner to strip it from every commit, then force-push the cleaned history.
Check usage logs for abuse. Most API providers show recent usage. Look for unfamiliar spikes, unexpected geographic activity, or usage that doesn't match your own traffic, since leaked keys are often found and abused by automated scanners within hours.
Fix the access control gap, not just the symptom. If a database or storage bucket was open, don't just add one rule. Review the entire set of permissions to make sure nothing else was missed in the same generation pass.
Building AI-Generated Apps More Safely Going Forward
The tools aren't going away, and they don't need to. The fix isn't avoiding AI-assisted development. It's adding a review step that AI tools don't currently do on their own.
A few habits meaningfully reduce risk on future projects:
Never let an AI assistant place a real API key in code you haven't personally inspected. Ask it to use environment variables from the start, and verify that it actually did.
Treat every backend-as-a-service setup as insecure until proven otherwise. Explicitly check row-level security, storage rules, or equivalent access controls before writing a single line of frontend code that depends on them.
Run a secret scanner before every push, not just before launch. Pre-commit hooks using tools like Gitleaks catch most hardcoded secrets before they ever reach a remote repository.
Keep sensitive API calls on a server you control. If a request needs a paid or sensitive API key, it belongs in backend code, never in anything the browser downloads.
Budget time for a manual security pass, even on a small project. A single afternoon spent checking the items above catches the overwhelming majority of the mistakes described in this article.
AI coding assistants are remarkably good at making software that works. Making sure it also keeps its secrets is still, for now, a job that falls to the person who ships it.
Top comments (1)
This is an important warning for anyone building with AI tools. An environment variable is not secret if it gets bundled into frontend code, and deleting a key from the latest commit does not remove it from Git history. My minimum check includes the browser Network and Sources panels, repository history, backend permissions, and public storage rules. If exposure is possible, rotating the key immediately is safer than waiting for proof of misuse.