Hardcoded Secrets in the Age of AI Assistants

The quiet problem with AI-generated code

I have a confession. Last week I asked an AI assistant to write a quick script to pull data from an API. It gave me a tidy function, complete with a placeholder for the API key. I replaced the placeholder with the real key and ran it. Then I saved the file.

That file is now a liability. And I'm not alone. Developers using AI assistants are producing more code, faster. But speed often means skipping the boring parts. Like environment variables. Like secret managers. Like not committing credentials to Git.

This is not a new problem. Hardcoded secrets have been a known issue for decades. What is new is the volume. AI assistants lower the friction of writing code, but they do not lower the risk of embedding secrets in that code. In fact, they may increase it, because the assistant does not know your security policy. It only knows patterns.

Why we do it

I've heard every excuse. "It's just a prototype." "I'll fix it before the PR." "The repo is private." All of these are wrong, for different reasons.

Prototypes become production. The temporary key stays. Private repos get forked, shared, or accidentally made public. And once a secret is in Git history, it is there forever, unless you rewrite history and rotate the key.

AI assistants make this worse because they are trained on public code. That public code is full of hardcoded secrets. So the assistant learns that pattern. When you ask for a quick demo, it gives you a key in a string. It is not malicious. It is just mimicking what it has seen.

There is also a psychological angle. When code appears instantly, it feels less like something you wrote and more like something you received. That subtle shift in ownership makes it easier to treat the output as disposable. You skim it, run it, and move on. Reviewing for secrets feels like extra work on code you did not really author. But you did author it the moment you committed it. The assistant is not the one who will get paged at 3 a.m. when the key leaks.

The fix is not complicated

You do not need a security team to avoid this. You need a habit. Use environment variables or a secret manager. Never commit secrets. Add a .gitignore for .env files. Use a pre-commit hook to scan for secrets. Rotate any key that has ever been committed.

Here is the pattern I see most often, and the fix.

# Bad: hardcoded secret
import requests

API_KEY = "sk_live_abc123..."

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

# Good: read 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)

That is it. One line changes. The risk drops from "catastrophic" to "manageable." If the environment variable is missing, the code fails loudly. That is good. It forces you to configure the environment properly.

A secret manager adds another layer. Tools like AWS Secrets Manager, HashiCorp Vault, or Doppler let you fetch secrets at runtime instead of storing them on disk. Your code asks for the secret by name. The manager returns it only to authorized workloads. If the secret rotates, your code does not change. If someone steals the source, they get nothing useful. For small projects, a .env file that never leaves your machine is often enough. For anything touching production, a real manager is worth the setup cost.

What AI assistants should do (and what you should do)

I think AI assistants should be trained to refuse to generate hardcoded secrets. They should always suggest environment variables or a secret manager. Some already do. But you cannot rely on that. You are the developer. You are responsible.

When you use an AI assistant, treat its output like code from a junior developer. Review it. Look for secrets. If you see a string that looks like a key, token, or password, replace it. Then add a check to your workflow.

Tools like git-secrets, trufflehog, or gitleaks can scan your repo for secrets. Run them in CI. Run them locally. Make it a habit. If a secret slips through, rotate it immediately. Do not just delete the commit. The secret is already exposed.

It also helps to give the assistant better instructions. Instead of asking for a working script, ask for a script that reads configuration from the environment. Mention your secret management approach up front. A good assistant will follow that constraint. A bad one will still slip. Either way, your review is the final gate.

The cost of skipping this

I have seen a startup lose a week of work because a database password was in a public repo. I have seen a developer accidentally push an AWS key and wake up to a bill for thousands of dollars. These stories are common. They are also preventable.

The AI assistant will not save you from this. It might even make it more likely. So do the boring thing. Use environment variables. Use a secret manager. Scan your code. Rotate your keys. It takes minutes. It saves months.

Seaworthy offers a free tool to scan your code for hardcoded secrets and other security issues.