Your AI Assistant Won't Save You From Committing Secrets

I've reviewed a dozen codebases in the past month where developers used AI coding assistants to scaffold entire projects. Every single one had at least one hardcoded secret. Not in a comment, not in a test fixture. In production code, committed to a public repository.

The pattern is always the same. A developer asks an AI assistant to integrate a payment provider, a database, or a third-party API. The assistant generates working code with a placeholder like sk_live_abc123 or your-api-key-here. The developer replaces the placeholder with the real key to test locally. Then they forget to move it out before pushing.

This is not a new problem. But AI assistants make it worse because they generate complete, runnable snippets that often include the secret in the same file as the logic. The assistant does not know or care about your deployment pipeline. It just wants the code to work.

Why this keeps happening

Most developers know they should use environment variables. They have read the twelve-factor app. They have seen the warnings. So why does it still happen?

Because environment variables add friction. You need a .env file, a loader library, a way to manage secrets in production, and a fallback for local development. An AI assistant can write a function that calls an API in five seconds. Setting up proper secret management takes twenty minutes of configuration and documentation reading.

And here is the uncomfortable truth: many AI assistants are trained on code that already has hardcoded secrets. GitHub is full of them. The assistant sees a pattern where the secret is right there in the source, and it reproduces that pattern. It is not being malicious. It is being helpful in the worst possible way.

I have seen this in code written by senior engineers. It is not a skill issue. It is a workflow issue.

The fix is boring and effective

Stop treating environment variables as an advanced topic. Treat them as the default. Here is what that looks like in practice.

Bad pattern (what the AI gives you):

import requests

API_KEY = "sk_live_abc123def456"

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

Good pattern (what you should write instead):

import os
import requests

API_KEY = os.environ["API_KEY"]

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

Then add a .env file for local development and add it to .gitignore immediately. Use a tool like python-dotenv to load it. In production, set the environment variable through your hosting provider or a secrets manager.

This is not complicated. But it is easy to skip when you are moving fast and trusting the assistant.

What I actually want you to do

First, run a secret scanner on your repository today. There are free tools. GitHub has one built in. If you find a secret, rotate it immediately. Do not just delete the commit. The secret is already in the history and possibly in someone's fork.

Second, change your AI assistant workflow. After every generated code block that includes a credential, ask yourself: does this need to be in the source? If the answer is yes, you are probably wrong. Ask again.

Third, write a pre-commit hook that blocks files matching common secret patterns. The hook does not need to be perfect. It just needs to catch the obvious cases. I use a simple one that looks for strings starting with sk_, ghp_, AKIA, and a few others. It has saved me twice this year.

Fourth, stop using .env files in production. They are fine for local development. In production, use your platform's secret management. If you are on Kubernetes, use Secrets. If you are on a cloud provider, use their secret manager. If you are on a VPS, use systemd's EnvironmentFile or a real secrets tool.

The AI assistant is not the problem

I like AI coding assistants. They make me faster. But they do not have context about your security posture. They do not know that your repository is public. They do not know that your CI logs are visible to your whole team. They do not know that a leaked key means someone can spin up expensive infrastructure on your dime.

You have to be the adult in the room. That means building a habit of moving secrets out of source code even when the assistant does not remind you.

The good news is that this habit takes about a week to form. After that, you will notice hardcoded secrets in other people's code immediately. It becomes a reflex.

Seaworthy provides a free secret scanning tool that checks your repository for common credential patterns before you push.