When I decided to put an AI engineer in my homelab cluster, the first real question was not "can it do the work." It was "how much do I trust it, and what catches it when I am wrong about that."
That is a governance question, not a coding one. And governance is squarely in the integrator's lane. My job here was not to invent a smarter model. It was to take a capable adopted agent and wire it into the cluster in a way that is accountable and recoverable. So this post is about the boundary I drew, why it fit my situation, and the honest limits of it.
I will say up front: this is the line that worked for a trusted homelab operator with a recoverable cluster. Someone running production for paying customers will draw it tighter, and someone messing about on a throwaway VM might draw it looser. All of those are reasonable. This is just mine.
The decision: full cluster-admin, on purpose
Long John, my AI engineer (the persona-and-platform setup from earlier parts), runs with full cluster-admin. Superadmin. No read-only training wheels.
That sounds reckless until you compare it to how I already work with people. When a competent human engineer joins an on-call rotation, I do not hand them a read-only kubeconfig and tell them to file a ticket every time something breaks at 3am. That would make them useless for the exact moment they are there for. I give them access, and I pair it with judgment, a notify-first habit, and a way to undo mistakes.
I decided the AI gets the same deal. The value I actually need covered is the on-call seat, a thinking engineer who can look and then act. A read-only account does not cover that seat. It just creates a bottleneck with extra steps.
The soft boundaries
The day-to-day guardrail is behavioural, not a rule engine. Three habits, baked into the persona and protocols in memory:
Notify-first. Read-only investigation is free. Long John can poke at logs, describe pods, check node state, query Prometheus, all day without asking. But before any change to the cluster, it pings me on Telegram with what it found and what it wants to do, and waits for a go.
SOP baseline. Standard DevOps practice is the default. Not a bespoke playbook for every scenario, just the same sensible defaults I would expect from any engineer: check before you change, smallest safe action first, do not stack risky moves.
Escalate the sensitive stuff. Anything touching secrets or credentials goes to a human, full stop. That is not negotiable behaviour, it is a hard escalation rule.
I want to be honest about what these are. They are behavioural guardrails. A determined or malfunctioning agent could in principle step over them, because they live in instructions and persona, not in an interlock that physically refuses the action. I am not pretending notify-first is a permission boundary. It is a discipline, the same way "always announce before you reboot the etcd node" is a discipline for a human.
The hard backstops
Because the soft boundaries can be crossed, I do not rely on them alone. Two things are not behavioural, they are mechanical.
An append-only audit hash-chain. Every action Long John takes is logged into a chain where each entry hashes the previous one. If anything is altered or deleted after the fact, the chain breaks and I can see it. This is the flight recorder. It does not stop a bad action, but it guarantees I can reconstruct exactly what happened and prove the record is intact. For me that is the difference between trusting an agent and merely hoping.
A kill-switch. One control that stops the agent cold. When in doubt, pull it, and nothing further happens until I look. It is the big red button next to the rack, and the whole point is that it does not depend on the agent cooperating.
So the model is: judgment and habits for the normal path, mechanical truth and a hard stop for the bad path. Soft where soft is enough, hard where it has to be hard.
Why this lets me sleep
The thing that actually settles my nerves is not the access level, it is the recoverable path. Cluster-admin with a verifiable record and a kill-switch is, for my homelab, less scary than a locked-down agent that quietly does nothing useful and lets a real problem rot until morning.
I treat the AI the way I would treat a trusted human engineer. Access, plus judgment, plus a way back. Not a cage, but not a blind leap either.
In Part 4 I will get into where that judgment actually shows up: the alert loop, and the time Long John caught a "disk 82% full" page that turned out to be synthetic test data. The boundary is the foundation. Next is what it does inside it.