Hardcoded Secrets Are Still a Problem, and AI Assistants Make It Worse

I keep seeing the same mistake in code reviews: API keys, database passwords, and tokens pasted directly into source files. It is not a new problem, but it has a new accelerant. AI coding assistants, which many of us now use daily, are very good at generating plausible code quickly. They are also very good at generating hardcoded secrets because they learn from public code, and public code is full of them.

A recent scan of a friend's side project turned up three separate keys in a single file. One was for a payment processor. He had used an AI assistant to scaffold the checkout flow, and the assistant had helpfully inserted a placeholder that looked like a real key. My friend replaced the placeholder with his actual key and committed it. He did not think twice. The assistant had made the whole thing feel normal.

That is the trap. AI assistants lower the friction of writing code, including bad code. They do not know your security policies. They do not know that your repository is public. They do not know that a leaked key can cost you thousands of dollars in minutes. They just complete the pattern.

Here is what the pattern often looks like:

# Bad: secret is hardcoded
import requests

API_KEY = "sk_live_abc123def456ghi789"

def charge_customer(amount):
    return requests.post(
        "https://api.payments.example/charge",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"amount": amount},
    )

The fix is not complicated, but it requires a habit change. Move secrets out of source and into environment variables or a secrets manager. Then load them at runtime.

# Good: secret comes from the environment
import os
import requests

API_KEY = os.environ["PAYMENTS_API_KEY"]

def charge_customer(amount):
    return requests.post(
        "https://api.payments.example/charge",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"amount": amount},
    )

That change alone prevents the most common leak. But it is not enough. You also need to keep secrets out of version control. Add .env to .gitignore before you create the file. Use a pre-commit hook that scans for high-entropy strings. Rotate any key that ever touched a commit, even if you deleted it later. Git history remembers.

I have little patience for the excuse that this is too much work. Setting up a secrets manager takes an afternoon. Rotating a leaked production key takes a weekend of incident response, plus the cost of whatever the attacker did with it. The math is not close.

AI assistants can help here too, if you ask them to. Tell your assistant to use environment variables instead of literals. Add a system prompt or a project rule that forbids hardcoded credentials. Some assistants will follow that instruction. Some will not. You still have to review the output. The assistant is a tool, not a security reviewer.

The deeper issue is that many developers using AI assistants are skipping the basics. They are learning to code by prompting, and no one has told them that secrets do not belong in source. That is not their fault, but it becomes their problem the moment they deploy. A single leaked key can expose customer data, run up cloud bills, or let someone impersonate your service. I have seen all three happen.

There is also a cultural problem inside many teams. Senior engineers assume that everyone knows the rules. They do not write them down. They do not put them in the onboarding docs. They do not enforce them in CI. Then a junior developer joins, uses an AI assistant to ship a feature in a day, and the key ends up in the repository. The senior engineer is surprised. The junior developer is embarrassed. No one wins. The fix is to make the rule explicit and automatic: secrets never go in source, and the pipeline checks for them before merge. That way the standard is not a matter of tribal knowledge. It is a gate that everyone passes through.

Another angle is supply chain risk. If your repository is public, bots scan new commits within seconds. They look for patterns like sk_live_, AKIA, and long random strings. They do not need your permission. They do not need a vulnerability in your code. They just read the file. Once they have the key, they can use it from anywhere. You might not notice until the bill arrives or the data is gone. By then, rotation is not enough. You need to understand what the attacker did, which systems they touched, and whether any customer data left your control. That investigation can take days. The pre-commit hook that would have stopped it takes an hour to set up.

My reaction is not moral panic. It is frustration. The fix has been known for decades. Environment variables are not new. Secrets managers are not exotic. Yet every week brings another public repository with a live key in it. AI assistants make this worse because they generate code that looks finished. It compiles. It runs. It just happens to include a secret that will be scraped by bots within minutes of being pushed.

If you use an AI assistant, do one thing today. Search your codebase for strings that look like keys. Check your .gitignore. If you find a secret, rotate it. Then set up a pre-commit check. That is not a big ask. It is the minimum.

Seaworthy provides tools for finding and managing secrets in code, which can help teams catch these mistakes before they reach production.