Your AI Assistant Just Committed a Secret: The Hardcoded Credential Problem

I keep seeing the same mistake in code reviews: API keys, database passwords, and tokens sitting in plain text inside source files. And lately, I see it more often in code generated by AI assistants. These tools are helpful, but they do not think about secret management. They think about making the code run. If a function needs an API key, the assistant will happily write const API_KEY = 'sk_live_abc123' and move on.

That is a problem. Hardcoded secrets in your repository are a gift to anyone who gets read access, whether that is a contractor, a compromised laptop, or a public GitHub mirror. Even private repos are not safe. Secrets get copied into logs, screenshots, and CI output. They end up in Docker layers. They persist in git history long after you delete the line.

The worst part is that this is an old problem. We have known how to avoid it for over a decade. Environment variables, secret managers, and configuration files outside version control are standard practice. Yet AI assistants keep suggesting inline secrets because they optimize for a single-file example that works. They do not know that your repo will be cloned by a hundred people or that a bot will scrape it minutes after you push.

Here is what the bad pattern looks like in a typical AI-generated script:

# bad: secret hardcoded in source
import requests

API_KEY = "sk_live_51H8x..."

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

This runs. It also means that key is now in your editor, your git history, your build artifacts, and any backup. If you rotate the key, you must edit the code. If someone forks the repo, they get your key. If you accidentally make the repo public for five minutes, the key is compromised.

The fix is not complicated. Move the secret out of the code and inject it at runtime. Use environment variables for local development and a secret manager for production. Here is the same function with that change:

# good: secret comes from environment
import os
import requests

API_KEY = os.environ["API_KEY"]

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

Then add .env to your .gitignore and provide a .env.example with placeholder values. In production, your platform (Kubernetes secrets, AWS Secrets Manager, HashiCorp Vault, or similar) injects the real value. The code never contains the secret.

The practical difficulty is not knowing the right pattern. It is building a habit that survives deadlines. When you are under pressure to ship a feature, the quickest path is to paste the key and keep moving. That is exactly when a hardcoded secret slips through. A short checklist helps: before every commit, scan the diff for anything that looks like a credential. If you see a long random string, a token prefix like sk_ or ghp_, or a password assignment, stop and refactor. This takes less time than writing the commit message.

Another angle is training your team to treat generated code differently. Assistant output should go through the same review as any external contribution. Some teams even label AI-generated blocks in pull requests so reviewers pay closer attention. That is not about distrust. It is about acknowledging that the tool does not share your context about deployment environments, access policies, or compliance requirements.

I think the AI assistant vendors should do better here. They could scan generated code for secret-like patterns and warn the user. Some already do, but it is inconsistent. More importantly, developers need to stop accepting the first suggestion. If an assistant gives you a hardcoded key, treat it like a bug. Ask for the environment variable version. It takes ten seconds and saves you a breach report.

You can also automate detection. Pre-commit hooks like detect-secrets or gitleaks will block a commit that contains a secret. That is a cheap safety net. It will not catch everything, but it catches the obvious mistakes. And if you do accidentally commit a secret, rotate it immediately. Do not just delete the line and force-push. Assume the secret is compromised the moment it touches a remote.

One more thing: AI assistants sometimes generate secrets as placeholders that look real. For example, password = "admin123" or token = "ghp_abc...". Those still count. They get copied into configs and then replaced with real values later, but the pattern remains in history. Treat every hardcoded credential as a problem, even if it is fake. The habit is what matters.

I am not saying AI coding tools are bad. They are useful. But they are not security tools. They will not remind you to use a secret manager. They will not rotate keys. They will not audit your git history. That is your job. So when your assistant hands you a line of code with a secret in it, do not paste it into your repo. Fix it first. Your future self will thank you.

For teams that want a quick way to check for exposed secrets across repositories, Seaworthy offers a free scan that looks for credentials in source code and history.