Your API Keys Are in the Code: A Founder's Guide to Secrets Management
There is a specific moment when many founders first hear the phrase "secrets management." A developer, an investor's technical advisor, or a security reviewer looks at the app an AI assistant helped build and asks one question: why are the API keys hardcoded in the code? The app works. Customers may already be using it. And sitting in plain text, somewhere in the source files, are the credentials that unlock the payment processor, the email service, the database, and the AI model the whole product runs on.
This is one of the most common findings in AI-generated codebases, and one of the most fixable. The guide below explains why it happens, what the actual exposure is, and what the fix looks like in two steps: environment variables first, then a secret manager when the business grows into one. None of it requires a computer science degree. It mostly requires knowing the problem exists.
Why AI Assistants Paste Credentials Straight Into Source Files
An AI coding assistant is built to produce code that runs. When you paste an API key into the chat and ask for a working integration, the shortest path to “it runs” is to write that key directly into the source file as a quoted string. The demo works on the first try, which feels like quality. The assistant has done exactly what was asked.
The tool is also imitating its training material. Public tutorials and code samples often show a placeholder key inline because that keeps the example short. The assistant reproduces the pattern with your real key in place of the placeholder. It has no concept of which strings are sensitive and which are not, unless the prompt or the tool’s guardrails force the distinction. Some newer tools do warn about this. Many sessions still end with credentials in the files.
Two details make this worse than it first sounds. If the key lands in frontend code, the part that runs in the visitor’s browser, then anyone who opens the page source can read it. And if the project uses git, which nearly every AI coding tool sets up by default, every key ever committed stays in the repository’s history. Deleting the line in today’s version does not remove it from last month’s commit.
How Attackers Find Exposed Keys, and How Fast It Happens
Exposed keys are not found by a person reading your code. They are found by automated scanners that watch public code repositories around the clock, matching the recognizable formats that cloud and API providers use for their keys. Security researchers who publish deliberately planted test credentials have repeatedly observed them being used within minutes of exposure. Not hours. Minutes.
What happens next depends on what the key unlocks. A cloud infrastructure key often gets used to spin up servers for crypto mining, which shows up as a bill. A key for an AI model provider gets drained by someone else’s traffic, billed to your account. An email service key can be used to send spam under your domain, which damages deliverability long after the key is revoked. A database credential is the serious case: that can be customer data leaving the building.
A private repository narrows the exposure but does not close it. Keys in private repos still leak through a contractor’s laptop, a CI log, a repository that gets made public later, or an account with a reused password. The honest framing is risk reduction: every place a credential lives in plain text is a place it can leak from, and source code is the leakiest place of all because code gets copied, shared, and backed up constantly.
The Fix, Step One: Environment Variables
The standard first fix is moving every credential out of the code and into environment variables. The concept is simpler than the name. An environment variable is a named value that the operating system hands to a program when it starts. The code says “use the value named STRIPE_KEY.” The actual key lives outside the code, in the environment where the app runs.
In practice that means two homes for your secrets. On a developer’s machine, they typically live in a file called .env that sits next to the project but is listed in .gitignore, the file that tells git what never to commit. In production, they live in the hosting platform’s dashboard: every mainstream host (Vercel, Netlify, Render, AWS, and the rest) has a settings screen for exactly this. The code is identical in both places. Only the environment differs.
This step matters beyond the immediate fix. Once secrets live outside the repository, the code can be shared, reviewed, or handed to a new developer without handing over the keys. An AI assistant can read the codebase without reading the credentials. And the repository history problem stops growing, though any key already committed should be treated as exposed and replaced, not just relocated.
For a solo founder with one app and a couple of services, this step alone covers most of the ground. The limitations show up later: a .env file is still plain text on someone’s laptop, and anyone with access to the server can read the variables. Those limits are what the second step addresses.
The Fix, Step Two: Secret Managers, and When They Earn Their Cost
A secret manager is a dedicated, encrypted store for credentials with access control and an audit log. The major cloud platforms each offer one (AWS Secrets Manager, Google Secret Manager, Azure Key Vault), and standalone services like Doppler and 1Password fill the same role for teams that are not tied to one cloud. The app fetches its secrets from the manager at startup instead of reading them from a local file.
What you gain over environment variables is control and visibility. You can grant a contractor access to exactly one key and revoke it the day the contract ends. You can see which person or system read which secret and when. You can update a key in one place and have every environment pick it up, instead of chasing copies across laptops and dashboards. Several managers can also rotate certain credentials automatically.
Secrets management for startups is mostly a question of timing, and the honest answer is that day one rarely requires a manager. The cost is less about the subscription fee, which is modest, and more about setup time and a new piece of infrastructure to understand. The signals that it has earned that cost are concrete: more than one or two people touching the code, a contractor or agency in the picture, customer data behind any of the keys, or a compliance requirement that asks who can access what. Any one of those usually justifies the move. Until then, disciplined environment variables are a defensible place to be.
Rotation: What to Rotate, How Often, and Who Owns It
Rotation means replacing a credential with a new one and retiring the old one. It is the habit that limits how long any leak stays useful. A key that rotates quarterly is a smaller prize than a key issued three years ago that still works.
The immediate cases are the clear ones. Any key that was ever committed to a repository gets rotated now, because the history still holds it. Any key a departing employee or contractor could have seen gets rotated when they leave. Any key involved in a suspected incident gets rotated the same day. For everything else, a periodic schedule is the goal; quarterly is a common starting point, and providers’ own recommendations vary by service.
The part most small companies miss is ownership. Rotation only happens if a named person owns it, with a recurring calendar entry and a short written inventory of every credential: what it unlocks, where it lives, and when it last changed. That inventory tends to surface its own findings. In our reviews, the key that nobody can rotate without fear of breaking production comes up regularly, and that fear is itself a sign the credential is wired in somewhere it should not be.
None of this requires new tools to start. It requires the list, the owner, and the calendar entry.
If you are not sure what is sitting in your repository right now, that uncertainty is normal and worth resolving while it is still cheap. A security review finds exposed credentials before someone else does, including the ones buried in commit history that the current code no longer shows. It is the first thing we check, and the fix usually takes a matter of days.