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.
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 —
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.
"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.
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:
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.
Roughly, this:
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.
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.
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.