Stop Hardcoding Secrets in Your AI-Generated Code!

I get it. AI coding assistants are fantastic. They write boilerplate, suggest fixes, and sometimes feel like magic. But there's a dangerous pattern I keep seeing in codebases that use these tools: secrets hardcoded directly in source files. API keys, database passwords, token strings. Right there in the code, often generated by the AI itself because you asked it to "connect to the database" or "call the OpenAI API."

And why not? It works. The code runs. The AI didn't warn you. You commit it to Git, push to GitHub, and move on. Except now your secrets are in version control history, visible to anyone with repo access, and possibly exposed in public if the repo is open source. That's not a minor slip. That's a security incident waiting to happen.

The AI doesn't know your security posture

When you prompt an AI assistant with something like "write a Python script to upload files to S3," it will often produce code with placeholder credentials or, worse, suggest you paste your actual keys into the script. The AI has no context about your threat model. It doesn't know that your repo might be public, that your laptop could be stolen, or that your CI logs are shared with contractors. It just wants the code to run.

I've seen this in production codebases more than once. A developer used an AI assistant to scaffold a quick integration, left the API key in a config.py file, and committed it. Six months later, that key was still active and being used by an attacker to rack up bills. Nobody noticed because the key was buried in a file everyone assumed was fine.

The fix is boring, and that's the point

The right pattern is environment variables. Secrets live outside the codebase, injected at runtime. Your source code references them by name, never by value. This is not new advice, but it's easy to skip when an AI hands you a working snippet.

Here's a typical bad pattern (the kind an AI might generate):

# bad: secret hardcoded in source
import requests

API_KEY = "sk_live_abc123def456ghi789"

def fetch_data():
    headers = {"Authorization": f"Bearer {API_KEY}"}
    return requests.get("https://api.example.com/data", headers=headers)

And here's the fixed version:

# good: secret loaded from environment
import os
import requests

API_KEY = os.environ["API_KEY"]

def fetch_data():
    headers = {"Authorization": f"Bearer {API_KEY}"}
    return requests.get("https://api.example.com/data", headers=headers)

Then you provide API_KEY via your shell, your .env file (which is gitignored), or your deployment platform's secret manager. The code is the same, but the secret never touches the repository.

Why developers skip this

I think there are two reasons. First, AI assistants make it too easy to copy-paste working code without thinking about the implications. The snippet runs, so you move on. Second, security basics feel like friction. Creating a .env file, adding it to .gitignore, configuring environment variables in staging and production, it's extra steps that don't make the feature work.

But here's the thing: the friction is the point. Security is not a feature you add later. It's a property of how you build. If your codebase has secrets in source, you don't have a secure system, no matter how many other controls you add.

What to do right now

If you're using AI assistants, add a rule to your workflow: never accept code that contains a literal secret. If the AI suggests one, replace it with an environment variable reference before you commit. Better yet, tell the AI in your prompt: "Use environment variables for all secrets." Most assistants will comply.

There's also a mental trap worth naming. When a secret is hardcoded, it feels local and small, like a note to yourself. In reality, the moment it enters a commit, it becomes a permanent record. Rotating a key is straightforward. Cleaning up every place that key was copied, cached, or scraped from a log is not. I've watched teams spend entire afternoons tracking down where a leaked token traveled. Prevention takes minutes. Recovery takes days.

Also, scan your existing repos. Tools like git-secrets or trufflehog can find committed secrets. If you find any, rotate them immediately. Deleting the file or rewriting history is not enough; once a secret is exposed, it's compromised.

A final note

I'm not against AI coding assistants. I use them. But they amplify your habits, good and bad. If you skip security basics, they'll help you skip them faster. If you build secure patterns into your workflow, they'll follow along.

For teams that want to catch these issues automatically, Seaworthy offers secret scanning as part of its code review tooling.