Your AI Assistant Just Committed Your API Key

I keep seeing the same mistake in code review, and it is getting worse. A developer asks an AI assistant to wire up a quick integration. The assistant writes a clean little function, drops in a literal API key, and moves on. The code runs. The tests pass. Then it goes into git.

This is not a subtle bug. It is a configuration problem that turns into a security incident. Secrets belong in environment variables or a secret manager, not in source. The fact that AI assistants make it effortless to paste a key directly into a file does not make it safe.

Why this keeps happening

AI coding assistants are trained on a huge amount of example code. A lot of that code includes placeholder keys, demo tokens, and sample credentials embedded directly in the file. When you ask for a working example, the model often gives you what looks like a finished product: a function with a real-looking string where a key should go. It feels faster. It is also a trap.

The pattern usually looks like this:

import requests

API_KEY = "sk_live_abc123def456ghi789"

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

That code works. It also hands your production key to anyone who can read the repository. If the repo is public, that is everyone. If it is private, it is everyone who ever clones it, forks it, or copies it into a support ticket. Rotating the key after the fact does not undo the exposure. The old key sat in plain text for however long it took you to notice.

The fix is not exotic. Read the secret from the 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 set the value outside the codebase. For local work, a .env file that is listed in .gitignore is fine. For deployment, your platform's environment configuration or a dedicated secret manager handles it. The point is that the secret never enters version control.

Why developers skip this

Environment variables feel like ops work. They require a step outside the editor. They break the satisfying loop of write, run, see result. When an AI assistant offers a one-file solution, that loop stays tight. Adding environment configuration feels like friction you did not ask for.

There is also a dangerous assumption that private repositories are safe. They are not. Repository access is broader than most teams think. Contractors, former employees, CI systems, and third-party integrations can all read them. A secret in a private repo is a secret with a large audience and no expiration date.

A few habits that actually help

First, ask your AI assistant for the environment-based version from the start. Many tools will generate a .env.example file and an os.environ lookup if you include that requirement in your prompt. Be specific. Say "read the key from an environment variable, do not hardcode it."

Second, add a pre-commit check. Tools like gitleaks or detect-secrets scan staged changes for patterns that look like credentials. They are not perfect, but they catch the obvious cases before they reach the remote.

Third, treat every hardcoded secret as already leaked. If you find one, rotate it. Do not just delete the line and commit. The value existed in the history, and history is easy to retrieve.

Fourth, make the safe path the easy path. Put a .env.example in the repo with placeholder names and no values. Document the one command or one dashboard step needed to set real values. When the secure option takes ten seconds, people use it.

The part that bothers me

The part that bothers me is how often this is framed as a beginner mistake. It is not. Experienced developers do it too, usually under deadline pressure, usually because an AI assistant produced something that looked complete. The assistant is not the problem. The lack of a guardrail is.

Configuration is not glamorous work. Nobody gets excited about environment variable loading. But a leaked key can cost real money, real data, and real trust. The cost of moving a string out of a file and into the environment is close to zero. The cost of leaving it in is not.

If you use AI coding assistants, add one line to your review checklist: no secrets in source. Then add one automated check to enforce it. Your future self will thank you.

For teams that want a second set of eyes on configuration and secret handling in their repositories, Seaworthy provides automated checks that flag hardcoded credentials before they ship.