Your AI Assistant Just Committed a Secret. Here's Why You Should Panic (a Little).

I've watched three separate teams this month discover live AWS keys in their repositories. Not in old, forgotten branches. In commits from last week, typed by developers who were "moving fast" with an AI assistant finishing their lines. This is not a hypothetical risk anymore. It's a pattern, and it's getting worse.

Here's what happens in practice. You start typing a config block. Your assistant, trained on millions of public repos, suggests a plausible-looking key. You hit Tab. The key is fake, sure, but the shape is right, and the next time you replace it with a real one, it stays in the file. Or worse, the assistant suggests a pattern that mirrors how secrets often appear in examples, and you paste a real token into that slot without thinking. The model doesn't know it's a secret. It just knows it completes the syntax.

The autocomplete trap

AI assistants are very good at matching the statistical shape of code. That's also their weakness. A line like API_KEY = "sk-live-..." is extremely predictable, so the model will happily fill it in. It has no concept of sensitivity. It has no concept of a production credential. It sees a string assignment and gives you a string.

Developers who lean on assistants often skip the boring parts: environment variables, secret managers, .gitignore hygiene. The assistant never reminds you. It just keeps producing code that looks done.

# Bad: secret lives in source, autocompleted or pasted
STRIPE_KEY = "sk_live_51H..."

# Better: secret comes from the environment, fails loudly if missing
import os
STRIPE_KEY = os.environ["STRIPE_KEY"]

The second version is not clever. It's not impressive. It is, however, the difference between a leak and a non-event. The assistant will still try to autocomplete the first one. You have to choose the second.

Why this keeps happening

I don't think this is a tooling problem, exactly. It's a habit problem. AI assistants make writing code feel frictionless, and friction is where security lives. Setting up a secret manager is friction. Adding a pre-commit hook is friction. Reading a diff before committing is friction. When the assistant removes the friction from writing, it also removes the moment where you would have paused and thought, "should this string be here?"

Teams also over-trust the assistant's output. If the model produced it, it must be reasonable, right? No. The model produced it because it's likely, not because it's safe. Likelihood and safety are different axes, and the assistant only optimizes one of them.

There's a social dimension here too. When a senior engineer writes config by hand, a junior reviewer feels fine pushing back. When the code arrives from an assistant, it carries a quiet authority that nobody assigned it. Reviewers skim instead of question. The suggestion came from a system trained on more code than any human has read, so surely it knows what it's doing. It doesn't. It knows what strings tend to follow other strings, and that is all. Once a team internalizes that, the review culture starts to shift back toward healthy skepticism.

What actually helps

Stop treating secret scanning as a nice-to-have. Put a scanner in your pre-commit hooks and your CI. It will catch the obvious patterns, and the obvious patterns are most of what leaks. Yes, it will occasionally flag a test fixture. Deal with it.

# .pre-commit-config.yaml (excerpt)
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

Second, change your default. When you ask an assistant to write config code, tell it to read from environment variables. Some assistants will follow that instruction for the rest of the session. That's a cheap win.

Third, review diffs with secrets in mind. Not every diff. Just the ones that touch config, deployment, or anything with the word client in the filename. You're looking for long random strings. It takes ten seconds.

Fourth, make the safe path the easy path. Keep a small snippet file in every repo with the environment-variable pattern already written out, so nobody has to think about it under deadline pressure. Pair that with a rotation runbook that names who to call when a key does slip out. Detection without a response plan just converts a leak into a scramble. The teams that handle this well treat a found secret as routine maintenance rather than a scandal, because the absence of blame is what keeps people reporting them early.

My actual opinion

The convenience of AI autocomplete is real, and I'm not going to pretend otherwise. But we've quietly traded a safety habit for speed, and most teams haven't noticed the trade. A hardcoded secret is one of the few mistakes that can go from "typo" to "incident" in a single push. The assistant won't warn you. The scanner might. Your reviewer might. But the model, the one writing half your code, will not.

Treat every autocompleted credential-shaped string as suspect until proven otherwise. That's the habit worth keeping.

If you want a starting point for catching these before they hit a remote, Seaworthy runs secret detection as part of its code scanning workflow.