Your AI Assistant Just Committed a Secret. Here's Why You Can't Blame It.

A developer asks an AI assistant to wire up a payments integration. The assistant produces a clean little module with a Stripe key sitting right at the top, in plain text, exported for convenience. The developer commits it, the tests pass, and the key goes into git history where it will live forever, or at least until someone finds it.

I keep seeing this pattern, and I have stopped being surprised. What bothers me is how often the reaction is a shrug. It was just a test key. It was just a placeholder. The assistant wrote it, so surely it knows what it is doing.

It does not. It cannot. An AI coding assistant has no idea whether the string it just wrote is a real credential, a fake one from a tutorial, or the production key someone pasted into a Slack thread three months ago. It is completing a pattern. The pattern includes a variable named apiKey and a string that looks like a key, because that is what the training data looked like. Training data is full of bad habits, and this is one of the worst.

The convenience trap

Generated code is optimized to look finished. A hardcoded secret makes a snippet feel complete and runnable. The alternative, reading from an environment variable, looks fussier and requires the developer to do something after pasting. So the assistant takes the path of least resistance, and the developer, relieved to see working code, accepts it.

This is not a failure of AI. It is a failure of review that AI makes easier to skip. The same developer who would raise an eyebrow at a hardcoded password in a human-written pull request will wave through the same line when it arrives from an assistant, because the assistant feels like a second pair of eyes.

It is not. It is a very fast first pair of eyes with no memory of your environment.

What it looks like, and what it should look like

Here is the shape of the problem, sanitized:

# What the assistant often writes
import requests

API_KEY = "sk_live_EXAMPLE_NOT_A_REAL_KEY"

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

The fix is not exotic. Read the value at runtime, fail loudly if it is missing, and keep the secret out of the repository entirely:

# What the assistant should write, and what you should insist on
import os
import requests

def charge(amount):
    api_key = os.environ.get("PAYMENTS_API_KEY")
    if not api_key:
        raise RuntimeError("PAYMENTS_API_KEY is not set")
    return requests.post(
        "https://api.example.com/charges",
        headers={"Authorization": f"Bearer {api_key}"},
        json={"amount": amount},
    )

A prompt to the assistant, something like "read credentials from environment variables and never inline them," helps, but it is not a guarantee. Assistants drift, especially in long sessions, and a follow-up request can undo a rule set twenty messages earlier. Treat the prompt as a nudge, not a control.

The part that actually matters

Once a secret is in a commit, deleting the line does nothing. Git keeps it. Forks keep it. CI logs keep it. The only real fix is rotation, and rotation is annoying enough that teams procrastinate, which is exactly why the leak keeps costing money.

So the cheap, boring controls are the ones worth building:

• A pre-commit hook that scans the diff for key-shaped strings and blocks the commit.
• Secret scanning enabled on the repository, not just in the CI pipeline.
• A short review rule: any line containing a literal credential gets a comment, no exceptions, even in generated code.
• Environment files in .gitignore before the first commit, not after the first incident.

None of this is glamorous. That is the point. The assistant gave you a shortcut and the shortcut went through a minefield.

My take

I do not think AI assistants are making developers worse at security. I think they are removing the friction that used to force a decision. When you typed out a config file by hand, you had to think about where the key came from. When the assistant types it for you, the thinking happens somewhere else, or not at all.

Keep the assistant. Just stop treating its output as reviewed code. It has never seen your production environment, and it never will.

Seaworthy builds tooling for developer security teams, including secret detection that runs where your code already lives.