🤖 Ghostwritten by GPT 5.4 · Fact-checked & edited by Claude Opus 4.6 · Curated by Tom Hundley
An AI coding assistant will paste a secret key right into your code if you let it. That is not a weird edge case — it is a normal failure mode. These tools learned from millions of public code examples, and a depressing number of those examples included real or fake-looking keys jammed directly into files. If you are vibe coding and you do not actively block this behavior, you are one autocomplete away from a leak, a giant bill, or both.
The problem is not only that a key can get exposed. Once a secret lands in your code, it can spread into version history, screenshots, chat transcripts, debug logs, cloud logs, and backups. Deleting it later does not magically un-ring that bell.
This piece covers the gap most articles miss: not just why hardcoded secrets in AI code are bad, but how to train your AI tool to stop offering them in the first place — and what to do in Cursor, Replit, Bolt, Lovable, and similar tools right now.
TL;DR: AI coding assistants suggest unsafe secret handling because they were trained on piles of examples where humans did the lazy thing.
Imagine teaching a teenager to cook by giving them 10,000 recipe cards, except a bunch of those cards say "store raw chicken on the counter overnight." The teenager is not evil. They just learned a bad pattern because they saw it over and over.
That is what is happening with hardcoded secrets in AI-generated code. A secret is a private value that unlocks something: payment tools, AI services, email senders, databases, file storage. In normal human life, this is your house key. In software, it is a long weird string.
AI tools often paste that string directly into a source file because public tutorials, sample repos, forum posts, and throwaway demos did exactly that. It is faster. It is easier. It also leaves your front door key taped to the outside of your house.
GitHub has reported that secret exposure in repositories is common enough to justify automated secret scanning across the platform. That alone should tell you this is not rare-user behavior — it is common enough that one of the biggest code hosting platforms on earth built products around detecting it.
Recently discussed vulnerabilities in AI coding tools matter for the same reason: if an AI coding tool can be tricked into unsafe actions, you cannot assume "the assistant knows better." It doesn't. You need guardrails.
As I explained in Building Intuition: What AI Gets Wrong (How to Predict It), AI failure is usually patterned, not random. Hardcoded secrets are one of the most predictable failures in the whole stack.
TL;DR: Once a secret touches code, it can persist in history, logs, backups, and shared tools long after you "remove" it.
This is the part vibe coders underestimate.
You paste a key into a file. Later, maybe your AI assistant or a more security-aware friend tells you to delete it. Great. Except the secret may already exist in:
The API-key-in-git-history problem is brutal because version history is designed to remember old states. That is its whole job. If a key was ever committed, it remains recoverable unless you deliberately clean history and rotate the key.
Google's official documentation tells developers not to embed API keys in source code and to rotate exposed credentials. GitHub also warns that once a secret is committed, the right response is to revoke or rotate it — not just delete the line. You do not control who already cloned it, indexed it, cached it, or scraped it.
Then there is debug logging. AI-generated code loves cheerful little lines that print everything for "troubleshooting." If that includes your secret, congratulations: you just copied your house key onto a billboard. If your app runs in a cloud platform, those logs may sit in a dashboard for days or weeks.
If you have not read Git Folder Exposure: Fix This Before You Deploy, read it after this. Different leak path, same ugly theme: stuff you thought was hidden often is not.
Diagram: Create a cinematic isometric cyber-noir cross-section of a small app project on a dark charcoal background with electric teal and warning red accents. On the left, show a glowing secret key embedded inside a source file. From that file, bright trails branch outward into three clearly separated zones
TL;DR: If you use AI to build apps without giving it security rules, it will optimize for "works now," not "safe later."
You do not need a computer science degree to understand this. You just need the right mental model.
Your AI assistant is like an eager intern. It wants to finish the task. If you say "Make this work," it may grab the fastest ugly shortcut. Hardcoding a key is a shortcut. Printing secrets in logs is a shortcut. Dropping everything into one file is a shortcut.
That means AI coding assistant security is not about trusting the model. It is about giving clear house rules.
Here is a quick comparison of common secret-handling patterns for vibe coders:
| Approach | Easy today? | Safe later? | Main risk |
|---|---|---|---|
| Paste key directly into code | Yes | No | Exposed in code, history, screenshots, and sharing |
| Put key in a notes file in project folder | Yes | No | Easy to upload or commit by accident |
| Print key in logs for debugging | Yes | No | Leaks into cloud logs and support screenshots |
| Store key in platform secrets/settings | Usually | Yes | Safer if you never copy it back into code |
| Use a local .env file kept out of sharing | Yes | Yes | Safe if ignored properly and never logged |
The definitive rule: Secrets do not belong in source code, screenshots, prompts, or logs.
If you are using Replit, Bolt, Lovable, Cursor, or similar tools, look for the place where the platform stores "Secrets," "Environment," or "Project Variables." That is the app equivalent of keeping your house key in your pocket instead of taping it to the door.
For a deeper beginner-friendly walkthrough, .env Files Explained: Protect Your API Keys Today covers the basics well. What this article adds is the AI behavior layer: you must also stop your assistant from reintroducing the bad pattern every time it edits your app.
TL;DR: Add permanent rules to your AI tool, move keys into secret storage, and ban logging of secret values.
Here is the practical part. Do this today.
If you use Cursor, create a .cursorrules file in your project. If you do not know what that is, ask Cursor to create it for you.
Paste this:
Security rules for this project:
- Never hardcode API keys, passwords, tokens, or secrets in code.
- Never put secrets in example code, test code, or comments.
- Always use environment variables or the platform's built-in secrets manager.
- Never print secret values in logs, error messages, or debug output.
- If a secret is required, explain exactly where I should paste it in the platform settings, not in the code.
- When editing code, preserve secure secret handling patterns already in place.
- If you are unsure whether a value is sensitive, treat it as a secret.That is how Cursor rules prevent secrets from creeping back in. Is it perfect? No. Is it dramatically better than hoping? Yes.
Use this prompt before you generate anything:
Build this feature without hardcoding any secrets.
Use environment variables or the platform's secret settings only.
Do not print keys, tokens, passwords, or full request data in logs.
If a secret is needed, leave a clear placeholder name and tell me where to set it in plain English.
Assume I am a non-developer and explain each setup step.For environment variables in vibe coding, the exact buttons differ, but the pattern is the same:
OPENAI_API_KEYIf you are unsure where that setting lives, ask your tool:
Show me exactly where this platform stores secrets, using click-by-click instructions for a beginner. Do not tell me to paste the key into code.Tell the assistant:
Remove any logging that prints secret values, authorization headers, tokens, cookies, full request bodies, or private user data. Replace with safe logs that only say whether the value exists.Good log: API key present: yes
Bad log: Using API key: sk-12345...
If you are also using automation, keep an eye on build pipelines too. GitHub Actions Security After a Supply Chain Attack is about a different layer, but the lesson is the same: automation happily spreads mistakes at machine speed.
TL;DR: The easiest security win is giving your AI assistant one reusable prompt that blocks the most common secret mistakes.
Paste this into Cursor, Replit, Bolt, or whatever you use:
You are helping me build this app safely.
Rules you must follow:
1. Never hardcode secrets in source code, comments, tests, sample data, or config files that will be shared.
2. Always use the platform's secret storage or environment variables.
3. Never log secret values or full private payloads.
4. If existing code contains a hardcoded secret, stop and show me how to replace it safely.
5. Explain every setup step in plain English for a non-developer.
6. Before finishing, review your own code for hardcoded secrets, unsafe logs, and accidental leaks.
Return both the code and a short checklist of what I need to configure outside the code.That one prompt will not make the model wise. It will make it less reckless.
TL;DR: Check one project today for hardcoded secrets, logs, and history before it costs you money.
Before tomorrow's lesson, do one thing:
Open your most recent project and search for these words:
keytokensecretpasswordauthorizationconsole.logprint(If you find a real secret in code, do not just delete it. Rotate it. Replace it. Then make sure your AI tool knows not to do it again.
Because they learned from public examples where humans did that exact bad thing. The model is predicting common patterns, not making a moral judgment about security. If you do not give it explicit rules, it often chooses the shortcut that gets the app running fastest.
Not necessarily. The secret may still exist in version history, logs, backups, screenshots, or shared chat transcripts. The safe move is to rotate or revoke the key, then clean up every place it may have spread. Treat deletion as step one, not the finish line.
They are hidden settings your app can read without storing the secret in the code itself. Think of them like a locked drawer your app can open when it needs the key, instead of leaving the key out on the table.
They give Cursor permanent instructions for your project, so the assistant sees your security rules every time it writes or edits code. They are not perfect protection, but they reduce repeated unsafe suggestions and make the tool much easier to steer toward safe patterns.
Treat it as exposed immediately. Revoke or rotate the key in the provider's dashboard, remove it from code and logs, and review any usage or billing activity tied to that key. Do not wait to see whether someone abuses it — assume they will.
You do not need to become a security engineer overnight. You just need a few non-negotiable habits. Keep secrets out of code. Keep them out of logs. Make your AI assistant follow rules instead of vibes. That one change will save a lot of people a lot of pain.
Share this with someone who is building too fast and trusting autocomplete too much. Come back tomorrow for the next lesson.
You've got this. See you tomorrow.
Discover more content: