Naming Two Secrets Differently So an Agent Can't Confuse Them

# Naming Two Secrets Differently So an Agent Can't Confuse Them Setting up the first automated test suite for a codebase that also runs a production data-migration pipeline, the two systems needed database credentials that were similar in every way that mattered functionally and different in exactly one way that mattered for safety: their names. ## The failure mode this prevents A test-database credential and a production-migration credential can look, structurally, identical — both are a connection string, both grant real write access to a real database, both get read from environment configuration by code that doesn't inherently know or care which one it's holding. The dangerous version of this setup is when both are plausible-looking environment variable names that an engineer, or an agent constructing a command, could type from memory and get subtly wrong under time pressure — running a test suite's teardown logic against what turns out to be the production migration target. ## Why documentation alone doesn't fix it You can write "never confuse these two" in a runbook, and it will hold right up until someone is moving fast, mid-incident, working from muscle memory instead of the doc. A comment doesn't stop a wrong keystroke. What stops it is making the wrong keystroke produce an immediate, loud failure instead of a quiet, catastrophic success — which means the two variable names can't merely be different, they have to be different in a way that's impossible to type one when you meant the other by simple habit. ## Why this generalizes past secrets This is a narrow instance of a broader pattern worth having as a default: when two things are functionally similar but must never be substituted for each other, don't rely on the operator — human or automated — to remember which is which under pressure. Make the two things structurally, nameably different, so a mix-up fails fast and loud at the point of use instead of succeeding quietly and failing much later, somewhere much more expensive to trace back.