I Gave My AI Bots the Keys. Then I Hired a Bot to Watch Them.

This weekend I had a team of AI bots building websites for me. Not helping. Building. They wrote the code, deployed it, and changed DNS on live domains while I made coffee.
That's either really cool or really scary, depending on how long you've worked in security. I've done this for 24 years, so it was both.
The fun part
My kids are grown, so nights and weekends are mine again, and I've been using them to tinker. Using Grok Bot and Cloudflare, I spun up:
- askchampva.com, a free guide that helps veterans' families make sense of CHAMPVA
- getisthisai.com, a free detector that tells you whether a piece of writing was AI-generated
- baileshomes.com, a site for my brother-in-law's homebuilding business

A few years ago each of these would've been a month of my Saturdays. This time it took a couple of evenings. I'm not going to pretend that isn't amazing.
The scary part
Every one of those bots had real access to production. Picture an intern who never sleeps, types at 1,000 words a minute, and never asks "are you sure?" That's who was pushing changes to my live sites.
The bots weren't bad at the work, they were good at it. The problem is that nothing was checking them.
Then I added a growth bot
Once the sites were live, I wanted people to actually find them. So I added Website bot Growth, which handles search, sitemaps, ads, and traffic reports. It doesn't touch site code. When it wants a code change, it hands the request to the builder bots, and those still need security approval.
On day one it connected Google Search Console for every site and audited the traffic. The honest finding was humbling: only about 1 to 26 percent of page views came from real people. The rest were bots and scanners. That's exactly why the next part matters.
So I gave them a boss
I built one more bot whose only job is to be the grumpy security reviewer. It's called Site Security, and it can't build anything. It can only say yes or no.
Now nothing ships unless it says yes. A bot that wants to deploy has to show its exact changes first. Site Security reads the real files and approves or sends them back. It also requires post-deploy checks, which the builder bot runs and reports, so we know the change did what it claimed. Anything that touches the whole account still comes to me.

It even pushes back on its own team. Site Security rejected two of the growth bot's proposed changes as unnecessary. Fewer changes means less attack surface.
It's caught things already. One bot shipped a new page and a security contact file, and both got approved. Then the post-deploy checks Site Security requires caught that one file was being served the wrong way. It was a tiny fix, but tiny misses like that are exactly how real incidents start.
Nothing here is new, and that's the point
This is the same playbook I'd use at any company. It just has a new kind of employee:
- The one who builds is never the one who approves.
- The goal is for every bot to get the least access it needs. I'm still tightening that part.
- Every change is written down, reviewed, and verified.
AI made the building easy. It didn't make the securing optional. If anything, it raised the stakes, because the bots move faster than any human can keep up with.
So go build something this weekend. Just hire the grumpy reviewer first.
Cory Zaner, CISSP, CISM, USAF Veteran
Want help applying this in your environment?
Request a service