Playing hide-and-seek with an API key our CFO's Claude Code kept hiding

There's a B2B SaaS that a non-engineer executive built all the way to production in two days, by handing everything to an AI. Real customers use it. It works. Features ship fast. It's genuinely impressive. And then I got handed the infra and the ops for it. I'm the guy who walks the "it's running in production" code path one step at a time. Treasure hunt, minefield sweep — somewhere in between. Today's story is about one of those steps: where the secrets (API keys and friends) were kept, and the game of hide-and-seek that played out there. Here's the punchline up front: every time I said "uh, that's dangerous," the secret's hiding spot moved house. And every time it moved, I got the look that says "there, now it's safe, right?" Hiding something and securing something are not the same thing. That's the whole article. Stage one: hardcoded in the source The first one I found was a fastball right down the middle. The API key was written straight into the source code. API_KEY = "(the real key string)" # ...right there in the open Classic vibe coding (= you give an AI a fuzzy instruction and it builds the thing). Getting it to run is the only priority, so it lands on the shortest path that works — embed the value as-is. The AI happily emits "code that runs"; it just won't emit "code that treats a secret like a secret" unless you ask. So I say my piece: "Hardcoding the key in the source is bad. One look at the repo and it's leaked." The exec, bless them, was agreeable and fixed it right away. Fixed it, sure — but — Stage two: relocated to the README They said it was fixed, so I checked. The key was gone from the source. Oh, nice. Except — it was now in the README. As a "setup step." Very helpfully. ## Setup 1. Clone the repository 2. Set the following key: (the real key string) …you see it, right? The secret just moved from the source to the instructions — it's still sitting inside the repo, not one millimeter less exposed. If anything, what was buried deep in the code got promoted to a prime, front-and-center spot in the document everyone reads first. In hide-and-seek terms: it came out of the closet and is now standing in the entryway. Easier to find. Great job. I get the feeling of accomplishment — "I removed it from the code." I do. But in secret-management land, the moment it's inside the repo, it's already game over. You've handed it to everyone who clones. Stage three: stored in the DB (progress!), but… "The README is no good either. The point is: don't put it inside the repo at all." I explained it once more. This time they really thought about it, and the next time I looked, the key was stored in the database. Which — directionally — is correct. It left the repo. No secret in the code, none in the README. Progress. I clapped. Genuinely. I did. But. When I actually peeked inside, the value was sitting there in plaintext. No encryption, no masking, nothing. Open the table and anyone can read it — the key string, just sitting there on its throne. Putting it in the DB does not equal safe. The location changed; the secret was never once actually concealed. In the source → in the docs → in the DB (still plaintext). The hiding spot took a three-stop trip and finally made it "outside" — but it hasn't moved a single step closer to "concealed." The seeker in this game is still looking in exactly the same place. "Hiding" and "concealing" are different things I'm not telling this to laugh at the culprit (= the exec). Honestly, it's a really natural instinct. Human intuition goes like this: If you put it somewhere out of sight, it's safe. The closet, the attic, a box pretending to be a safe. Make it invisible and you feel like you've protected it. In the physical world that's half true. But in software secret management, that intuition slips. The question isn't "is it hard to see," it's: - Does putting it there keep it out of the distributable (the repo)? - Is read access actually narrowed to only the people who need it? - Even if it's read, is the content encrypted so it's meaningless? That's what matters. Moving the location is "hiding." Only when you satisfy the above do you "conceal." Take it on a three-city tour and, if it never once meets the bar for concealment, the game of hide-and-seek never ends. So where should it live? Roughly, this: - Don't put secrets in the code or in the repo (hardcoding, README, committed config files — all out). The code should know only the secret's name, never its value. - Inject the value from outside the runtime — environment variables, or a secrets manager (a vault built for exactly this). - If you absolutely must keep it in the DB, store it encrypted. Plaintext means "if the DB leaks, everything leaks." - And rotate any key that might have leaked. A key that ever sat in plaintext in a repo or a log is contaminated; treat it that way. This SaaS is about to launch, so I tackled the secrets first. We also had an external red team review the source for vulnerabilities, and that pass is done. Secrets are "leak once and it's over," so they go ahead of refactoring and tests — order-wise, this was the thing to knock out first. Meanwhile, the obviously-should-be-refactored code and the gaping lack of tests are, for now, left exactly as they are. Because, well, it works. After launch we'll clean it up little by little, update by update. The CFO charges ahead building features; I follow behind sweeping up bugs. That's the split, and right now we're in the just-ship-it phase. The most interesting part: it happened on Opus 4.8 Read this far and you're thinking "well, a non-engineer built it, so sure." I thought so too. But here's what made this one genuinely interesting. This exec runs the top-tier AI plan, constantly — the smartest current model (Opus 4.8), on the highest tier. By any reasonable expectation, this kind of rookie mistake shouldn't happen with that gear. And yet it did. The secret got hardcoded, moved to the README, and landed in the DB in plaintext. Even with the strongest tool in hand. It's not that the AI is bad. A smart model emits "code that runs" in an instant. It does — but what counts as a secret, and where it should live, only gets satisfied once you ask for it. Don't ask, and it will cheerfully, brilliantly, help you drop a plaintext secret into your DB. In other words — Even with the smartest model, if the operator doesn't know what to protect, intelligence doesn't convert into safety. The capability of the tool and the safety of the result are on different axes. The same way "this knife is sharp" and "you didn't cut your finger" are two different sentences. Takeaways - "Building" got fast; "treating a secret as a secret" is a separate skill. Even in an era where a non-engineer ships to prod in two days, this part doesn't fill itself in unless you ask. The brighter the light, the sharper the shadow. - Moving the hiding spot is "hiding," not "concealing." The moment you feel accomplished about relocating it is your cue to stop and look again. - The reviewer's lens, when you inherit something, isn't "does it work" — it's "how could it leak." The more it's running happily in production, the more likely a plaintext key is enthroned behind it. - Even the smartest top-tier model won't save you when it can fail, it fails. Tool capability and output safety are different axes; intelligence converts to safety only when you ask "what are we protecting." A non-engineer shipping to production is genuinely amazing. I'm not knocking it. It's just that a secret belongs not in an "invisible place" but in the "right place." Before you stuff it in the closet and relax — take one more look: is it visible from the entryway? Stay safe out there. Top comments (0)