You pasted a chunk of code into a chatbot to ask why it kept crashing, and it fixed the bug. Later that night you remembered that the code had a long string of letters and numbers near the top, the one your payment tool told you to "keep private," and now you cannot stop thinking about it. Did you just leak something? Does it matter? And if it does, what are you supposed to do about it without breaking the app that finally works?
This is one of the most common quiet worries for people who build with AI, and it is fixable. Most of the time the fix is a calm, ten-minute routine, not an emergency. Let's define exactly what a secret is, look at how it ends up somewhere it shouldn't, and walk through how to rotate a key without taking your app down.
What a secret actually is
A secret is any string that grants access or proves identity to a service your app talks to. If someone else has it, they can act as you: send emails from your account, charge cards through your payment processor, read your database, or run up a bill on your AI provider.
Here are the usual kinds, in plain terms:
- API keys. A long code that lets your app use another company's service (email sending, maps, an AI model, image hosting). It is basically a password for a robot.
- Tokens. Short-lived or long-lived access passes, often used for logins and "connect my account" buttons. Access tokens, refresh tokens, and session tokens all count.
- Passwords. Yours, your database's, your admin account's. Any of them.
- Database connection strings. A single line that bundles the database address, username, and password together. It looks technical, but it is a master key to your data.
- Private keys and certificates. The half of a key pair you are supposed to guard, plus things like signing keys and webhook signing secrets.
- The contents of your
.envfile. This is the file where many tools store all of the above in one place. It is the jackpot.
If you're still learning the vocabulary here, the security terms glossary and the glossary define these words without assuming you already know them.
In Plain English: a secret vs ordinary code
Most of your code is not secret. The logic that decides what happens when a user clicks a button, the layout of a page, the shape of your database tables, none of that grants access to anything. You could show it to a stranger and lose nothing.
A secret is different because it is not instructions, it is a credential. Think of it like this: your code is the recipe, and anyone can read the recipe. The secret is the key to the restaurant's back door. Sharing the recipe is fine. Sharing the key is not. The tricky part is that AI tools often place the key right in the middle of the recipe, so both get copied together when you paste.
What never to paste into a chatbot
When you ask an AI chatbot for help, you are sending whatever you paste to a company's servers. Even with good privacy settings, the safe habit is simple: never paste live credentials into a prompt.
Concretely, keep these out of any chatbot, screenshot, public repo, or support ticket:
- API keys and access tokens
- Passwords of any kind
- Database connection strings
- The full contents of a
.envfile - Private keys, signing secrets, and certificate files
- Webhook signing secrets
If you need help with code that contains one of these, replace the value with a placeholder before you paste. Swap the real key for the word YOUR_KEY_HERE (or xxxxx). The chatbot can still help you with the surrounding code, because the logic is what it needs to see, not the credential itself.
How secrets end up hardcoded or pasted
You did not do anything unusual. Secrets leak through a handful of ordinary paths, and AI-assisted building quietly encourages a few of them.
AI tools often hardcode keys to make things "just work." When you ask an assistant to connect your app to a service, the fastest way to get a working demo is to drop the key straight into the code. It runs, you move on, and the key is now sitting in a file. "Hardcoded" simply means the secret is typed directly into your code instead of being stored somewhere separate and pulled in at runtime.
Copy-paste debugging spreads them. You paste the failing file into a chatbot. That file had the key in it. Now the key exists in your chat history too.
Screenshots catch them. A screenshot of your editor or your terminal can include a key in a config file, a browser tab, or a log line you didn't notice.
Public repositories publish them. If you push your project to a public place and the .env file (or a hardcoded key) goes with it, it is now readable by anyone, and automated scanners find these fast.
None of these mean you were careless. They mean secrets are slippery, which is exactly why the rest of this article is about noticing and rotating rather than blaming.
This is one item in a longer list; the other security mistakes AI leaves behind covers the neighbors of this one.
How to tell if a key has been exposed
You cannot always know for certain that a key was seen by the wrong person. What you can do is check the places where exposure happens and look for signs of misuse. Detection first, panic never.
Ask these questions:
- Is the key hardcoded in a file? Search your project for the service's name or the word "key." If a real value shows up in the code instead of being pulled from an environment variable, treat it as exposed.
- Is it in a public repository? If your project is public anywhere, assume anything committed to it has been read.
- Did it go into a chatbot, an email, a ticket, or a screenshot? If yes, treat it as exposed. It is cheaper to rotate than to wonder.
- Are there signs of misuse? Check your provider's dashboard for usage you don't recognize: charges, API calls, emails sent, or logins from unfamiliar places. Many providers show recent activity and let you set up billing alerts.
A quick note on honesty with yourself: rotating a key stops future use of the old one, but it does not undo anything that already happened while the key was live. If you see unfamiliar charges or activity, that is a separate cleanup, and for payment or login systems it is a "get help" moment, not a "read one more article" moment.
For a broader sweep of your whole app, work through the full security self-audit or the Security Self-Audit checklist.
How to rotate a key safely without downtime
"Rotating" a key means replacing an old secret with a new one and turning off the old one. Done in the right order, your app never goes down. Done in the wrong order (revoke first, panic later), it does.
The safe sequence is: create, update, verify, then revoke.
- Create a new key. In the service's dashboard, generate a fresh key or token. Most services let you have more than one active at a time, which is what makes zero-downtime rotation possible. Do not delete the old one yet.
- Update your config. Put the new key where the secret is supposed to live (see the next section) and stop using the old one in your code. If your app needs to restart or redeploy to pick up the change, do that now.
- Verify the app works on the new key. Test the feature that uses this service. Send the test email, run the test charge in test mode, load the page that calls the API. Confirm it works with the new key before you touch the old one.
- Revoke the old key. Only after the app is confirmed working, disable or delete the old key in the dashboard. This is what actually closes the door on whoever might have seen it.
Because the new key is live and verified before the old one is switched off, there is no gap where your app has no working key.
Two guardrails:
- Never "fix" a key error by disabling the feature or turning off authentication. If an error tempts you to remove a login step or comment out a security check to make it go away, stop. That trades a small problem for a much bigger one.
- Provider-specific steps vary and change often. The buttons, menu names, and exact flow differ by service, so follow that provider's official documentation for the current steps rather than any UI walkthrough from memory. Treat rotation instructions as documentation-sourced only.
When to hire a professional
Rotate ordinary keys yourself. But if the leaked secret touches payments or authentication, that is the threshold to bring in help. A leaked Stripe key, a database connection string, a login/session signing secret, or anything that can move money or unlock user accounts crosses into hire-a-pro territory, and getting expert review before and after rotation is worth it. There, the risk is not just downtime, it is other people's money and personal data.
If payments are your worry specifically, add Stripe payments without leaking keys walks through doing it cleanly, and it is the right companion when a payment key is involved. Anything in this zone is a good candidate for expert review.
This is educational, not legal advice. If a leak involves customer payment details or personal data, verify your obligations with a qualified professional for your situation.
Where secrets should live instead
The point of rotation is a fresh key. The point of storing it correctly is that you rarely have to rotate again. Secrets belong outside your code, in a place designed to hold them.
Environment variables. Instead of typing the key into your code, your code reads it from the environment at runtime. The value lives in a .env file locally (which you keep out of any public repository) or in your hosting platform's settings. Your code just references a name like STRIPE_SECRET_KEY, never the value itself.
Platform secret managers and vaults. Most hosting platforms have a dedicated place to store secrets: an "Environment Variables" or "Secrets" section in the dashboard. You paste the value in once, and the platform injects it securely when your app runs. This keeps the secret off your laptop and out of your code entirely.
The habit that keeps you out of trouble:
- Keep every secret in environment variables or your platform's vault.
- Keep your
.envfile out of any repository you push. - Reference secrets by name in code, never by value.
- When in doubt about whether something leaked, rotate it. It is cheap.
Some tool links in our articles may be affiliate links, disclosed on our disclosure page. We do not call any secrets manager "best" without stated criteria.
FAQ
I pasted a key into a chatbot. Do I have to rotate it? The safe answer is yes. It is faster to rotate the key than to be sure it was never seen or stored, and rotation is a routine, not a crisis.
Does rotating a key mean I'm safe now? Rotating stops the old key from working going forward. It does not undo anything done while the key was still live, so also check the provider's dashboard for activity you don't recognize.
Is it okay to keep two keys active during rotation? Yes, briefly. Having the new key live while you verify the app is exactly what prevents downtime. Just revoke the old one as soon as the app is confirmed working on the new one.
What if the leaked key was for payments or logins? Treat that as a get-help situation. Rotate it, then get expert review, because the stakes involve money and user accounts rather than just app uptime.
In Plain English
What this means: a secret is a credential that grants access, separate from your ordinary code, and it should never end up in a chatbot, a screenshot, or a public file.
Who it helps: solo builders and non-technical founders who have pasted code and config into an AI tool and now aren't sure whether they exposed a key.
When to use it: any time you paste code somewhere, ship a project public, or get a nagging feeling that a key went where it shouldn't.
What to do next: replace exposed keys using the create-update-verify-revoke order, move every secret into environment variables or your platform's vault, and get expert help for anything touching payments or logins.
Your next step
Don't leave this as a one-time scare. Add a quick secrets check to your regular routine so exposed keys get caught early instead of after a surprise bill. Fold it into your monthly maintenance checklist with the Security Self-Audit, and you turn "did I leak something?" from a recurring worry into a two-minute habit.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.