Thoughts
The wrong answer I gave about AI coding security
I was cleaning out a dryer vent last week when the conversation turned to AI.
The customer works in tech. His company is adopting AI into their workflows and he’s been thinking about it seriously. We started comparing notes, and then he asked me something I fumbled:
When you use AI to write code or manage your servers, how do you know it’s actually secure?
My first answer was the defensive one. AI coding has a bad reputation in self-hosting and developer circles right now. Rushed, untested, and there have been real incidents where credential leaks in AI-written software hit actual users. I basically said it’s an inherent problem because the barrier to entry is so low, and I contain the risk by keeping things on Tailscale, limiting outside exposure unless I really need it.
That’s a real answer. It’s not the whole answer. I’ve been thinking about it since.
The technicians who refused to learn circuit boards
In the early 2000s, appliances started getting modern circuit boards and electronic controls. The shift away from mechanical and analog systems was fast. Old-school technicians who’d spent decades diagnosing by hand and ear were not happy about it. Some refused to learn the new machines. Some refused to work on them at all. The argument was that the new stuff was unreliable, hard to diagnose, and couldn’t be trusted the way a mechanical component could.
The technicians who adapted went on to work on the machines that were actually being sold. The ones who didn’t got left behind.
I’m not a CS person. I came up through networking and service business operations. And I think people with a traditional CS background sometimes respond to AI coding the way those technicians responded to circuit boards. The instinct is to protect the craft from something that feels like it’s cheapening it. Fighting it doesn’t slow it down.
AI coding is here. The question is whether you shape how you use it or let it use you carelessly.
What I should have said
Coding with AI works like everything else with AI. Vague instructions, no constraints, no security knowledge in the prompt, and you get something that demos fine and breaks somewhere inconvenient later. Clear context, specific requirements, patterns you’ve already validated, and the output looks a lot more like the standards you set.
That did not arrive free. Early on, testing prompts and workflows with AI, I locked myself out of servers more than once. Firewall too early. SSH tightened before I had a way back in. It took a lot of trial and effort before the models were tuned to this kind of work, and before my instructions stopped assuming I would catch the dumb step by hand.
Over the years I built up how I want specific things secured: authentication flows, API access, how tokens get scoped, rate limiting. I used to write that by hand every time, then kept scripts, then a folder of scripts and notes I’d copy from. Now that knowledge lives in prompts and instructions I’ve tested and trust. When I need an auth piece built, the AI is working from patterns I’ve already validated, not inventing the whole thing from vibes.
Same story on infrastructure. I used to harden a new Linux box by hand off a mental checklist that grew over years of setting machines up. Now I send an agent in over SSH with a documented runbook. Two phases on purpose, because I learned the hard way what happens if you lock the door while you’re still getting in. The agent doesn’t skip fail2ban. It doesn’t leave password auth on because it’s midnight and I’m tired. More on that in how I provision and harden a Debian 12 server. Credentials for those agents don’t sit in the prompt either. That side is Infisical and Agent Vault.
That is not less secure than hand-coding every time. In some ways it is more consistent, because the process does not depend on whether I remembered the checklist.
Where it ended up
The evolution of this is documentation the AI can actually retrieve and apply. Hardening a new VM. Auth in a Next.js app. Scoping database credentials the way I want them scoped. Institutional knowledge that shows up every time, instead of knowledge I have to remember to paste in.
The writeups in self-hosting communities about AI-coded disasters usually involve someone vibing an app without bringing real security knowledge into the prompts. The door to building software is wider than it used to be, and not everyone walking through it knows what they’re doing. That part of the criticism is fair. Closing the door isn’t the move. Being the person who brought something through it is.
The Tailscale point I made in the laundry room is still valid. Defense in depth matters. Network containment is a real fallback when something gets past the process. But that is not the answer to “how do I know it’s secure.” The answer is: I defined what secure looks like for my stack, burned myself learning where the prompts fail, and the AI follows that definition.
I should have said that the first time.
I wrote more about keeping credentials out of AI agent context windows in secrets, keys, and why AI agents make this harder to ignore.