Your AI Assistant Just Committed Your API Keys

The new secret leak is not clever. It is lazy.

I opened a pull request last month from a developer using an AI coding assistant. The code was fine. The tests passed. Buried in a helper file was a Stripe live key, a Postgres connection string, and an AWS access key. All three sat in plain text under a comment that said // TODO: move to env.

The developer did not mean to leak anything. They were moving fast. The AI assistant had generated a quick integration, and the fastest way to make it work was to paste in real credentials. Then they forgot. This is not a rare story. It is a pattern, and it is getting worse as more code gets written with autocomplete and chat interfaces.

Why hardcoded secrets keep winning

Developers skip security basics for boring reasons. A .env file feels like extra setup. A secrets manager feels like infrastructure work. An AI assistant does not ask for a vault. It asks for a variable. When you are in flow, typing the key directly into the file is the path of least resistance.

The problem is that source control is forever. Once a secret is committed, it lives in the history, in forks, in CI logs, and in every clone on every laptop. Rotating the key is the only real fix, and most teams do not rotate until something breaks or someone gets a bill.

Worse, modern scanning tools still miss a lot. They look for known formats and high entropy strings. A base64-encoded token pasted into a YAML file might slip through. A database password that is just a long word might not trigger anything. And when the code was generated by an AI, the pattern can look normal enough that reviewers scroll past it.

The fix is not a tool. It is a habit.

I am not going to pretend there is a magic scanner. The only reliable fix is to never let a real credential touch a file that gets committed. That means environment variables from day one, even for a throwaway script. It means a pre-commit hook that blocks obvious secrets. It means treating your AI assistant like a junior developer who does not know your security policy yet.

Here is the pattern I see most often, and the two-line change that stops it.

# BAD: hardcoded in source
import requests

API_KEY = "sk_live_51H8x..."  # real key, committed forever

def charge_customer(amount):
    return requests.post(
        "https://api.stripe.com/v1/charges",
        auth=(API_KEY, ""),
        data={"amount": amount, "currency": "usd"},
    )

# GOOD: read from environment, fail loudly if missing
import os
import requests

API_KEY = os.environ.get("STRIPE_SECRET_KEY")
if not API_KEY:
    raise RuntimeError("STRIPE_SECRET_KEY is not set")

def charge_customer(amount):
    return requests.post(
        "https://api.stripe.com/v1/charges",
        auth=(API_KEY, ""),
        data={"amount": amount, "currency": "usd"},
    )

That is it. No vault required for a small project. No complex config. Just a rule: if it is a secret, it does not go in the file.

What I actually do now

I changed my workflow after cleaning up that pull request. Before I accept any AI-generated code, I search the diff for strings that look like keys, tokens, or passwords. I run git grep -i "password\|secret\|key\|token" on the staged changes. I keep a .env.example file with fake values so the assistant has something to copy without copying a real secret. And I rotate anything that was ever committed, even if the repo is private.

I also stopped trusting the excuse that "it is just a prototype." Prototypes become products. That is how most of us got here.

The uncomfortable part

AI assistants are not the problem. They are a mirror. They generate what you ask for, and if you ask for a quick integration, they will give you one with a hardcoded key because that is the simplest example. The assistant does not know your deployment environment. It does not know that your repo is public. It does not care.

You have to care. Every time. That is the job.

If you want a starting point for checking your own repos, Seaworthy is a security tool that scans for exposed credentials and other common mistakes in source code and CI configurations. It is not a replacement for rotating keys, but it can tell you where to start looking.