The starting point
After several months of growing this homelab — a 6-node k3s cluster on Raspberry Pi, a NAS acting as both media hub and backup target, a handful of sites behind a tunnel — one question kept nagging at me: what did I miss?
Not in the sense of “does it work” (monitoring answers that every day), but in the sense of “what could quietly cost me my data, expose my privacy, or fry some hardware”. Those are exactly the blind spots you stop seeing once you live inside your own infrastructure.
So I ran an experiment: give an AI agent — Claude Fable 5 — access to my three sources of truth (my notes, my Git repositories, and the live cluster) and ask it for a full security audit. This post covers the method, what such an audit actually finds, the moment the AI got it wrong, and why that moment is the most instructive one of all.
Deliberate note: I publish no exploitable detail about my infrastructure (addresses, hostnames, open ports, still-open holes). Publishing a map of your own gaps would be a vulnerability in itself. Everything below is presented as transferable lessons, not as a diagram of my network.
1. The method: three sources, parallel agents, and one golden rule
The first pleasant surprise was how the agent split up the work. Rather than reading everything sequentially, it launched several sub-agents in parallel, each on an independent domain:
- one on my notes (my documentation vault: infra reviews, runbooks, backup strategy);
- one on my Git repositories (cluster manifests, application code) — hunting for committed secrets, overly broad permissions, risky configurations;
- one on the applications themselves.
And above all, one rule that changes everything: verify before asserting. Wherever it could, the agent didn’t settle for reading a config — it tested the actual behaviour. Is a service really reachable? Does it really answer without authentication? Does the backup really exist? The gap between “the config file suggests X” and “I verified that X happens” is the whole difference between an audit that helps and an audit that falsely reassures.
2. What a homelab audit really finds
The most useful findings are not exotic CVEs. They are trust assumptions you made without ever testing them. Here are the categories that keep coming up — and that probably apply to most homelabs.
The firewall that filtered nothing
The most striking lesson: my firewall was giving me false confidence. I had clean rules and a short, reassuring list of allowed ports. Except that most of my services run in containers — and the container engine inserts its own network rules before those of the application-level firewall. Result: ports I believed were filtered were in fact reachable from the entire local network.
The rule to remember: on a Docker host, the real exposure surface is the list of published ports: — not the output of your firewall. Check it yourself by testing from another machine, not by reading your configuration.
The LAN is not a trust zone
A corollary of the previous point: several services answered with no authentication at all on the local network. You tell yourself “it’s the LAN, it’s my home”. But “my home” also includes a guest’s phone, a cheap connected device, or any compromised machine on the same network. A service handling personal data should never rely on the LAN as its security perimeter.
RAID is not a backup — and a backup you can erase isn’t really one
Two levels here. The first is classic: RAID protects against a disk failure, not against a deletion, ransomware, or human error. The second is subtler: my off-site backup did exist, but the account writing it could also delete it. A malicious process on the source machine could have destroyed the original and the copy at the same time.
The missing piece is immutability: an append-only target, or a token with no delete rights, so a copy survives even a compromise of the source. That’s the difference between a backup and wishful thinking.
Secrets live a long time in Git history
A timeless classic: a credential committed once, removed later, but still present in the history — and therefore in every clone, including the backup mirror. “I deleted it” isn’t enough; an exposed secret must be treated as compromised and rotated, not just wiped from the latest commit.
The keys that open everything, with no padlock
Finally, access keys stored without a passphrase on a machine whose disk encryption wasn’t confirmed. A well-built secrets manager for emergencies doesn’t replace everyday hygiene: the key you use every morning is often the most exposed link.
None of these findings is spectacular on its own. What matters is their accumulation — and that is precisely what a systematic, unflattering audit brings to light.
3. The most important moment: when the AI got it wrong
Here’s the section I most wanted to write, because it is the opposite of a sales pitch.
After the audit, we moved on to maintenance: checking which applications needed an update. The agent produced a neat table and rated as critical priority a security update for a storage component, citing a specific vulnerability and a specific fix version.
Except that the fix version did not exist.
When it came time to apply the patch, the first step was to verify that the new version was real. The official registry didn’t know it: the most recent version available was exactly the one I was already running. The project had in fact stopped its community releases — there simply was nothing newer to install. The agent had hallucinated a plausible but false version number and vulnerability.
The lesson isn’t “AI is unreliable”. The lesson is that the golden rule — verify before acting — isn’t a luxury, it’s the guardrail that turned a mistake into a non-event. Had the agent applied its own advice without verifying, it would have pinned a nonexistent image and broken the deployment. Because every target was checked before being touched, the error died at the control step, with no consequence.
An agent allowed to act on real infrastructure must be kept on a leash made of evidence, not of its own confidence. That’s true for an AI. It’s just as true for a tired human at 11 p.m.
4. From audit to action: a rolling k3s upgrade
An audit that leads nowhere isn’t worth much. So we moved on to something concrete, with the same principle throughout: one step, one verification, one possible way back.
The most interesting piece was the Kubernetes minor version upgrade across the 6 nodes, with no service interruption. A few decisions that aged well:
- Swap the binary, not the configuration. Rather than re-running the install script (which might have rewritten sensitive configuration files), we swapped only the binary — verified by its checksum — while keeping the old binary on each node. Rollback in seconds if a node refused to come back up.
- A snapshot before starting. A backup of the cluster state taken just beforehand, as an anchor to roll back to.
- One node at a time, with a gate between each. Control nodes first, then worker nodes, never two at once. And between each storage node, we waited for the distributed storage to rebuild its redundancy before touching the next one. That’s the only step where you can genuinely lose data by going too fast; so that’s where you have to be most patient.
A tasty detail: on the first upgraded node, a built-in network component started failing in a loop for two minutes. Panic? No — that was the expected behaviour of a window where nodes don’t all run the same version, and it resolved itself as soon as the second node was done. Having anticipated it in the plan made the difference between “incident” and “footnote”.
Result: all 6 nodes on the new version, zero data loss, zero visible outage, everything verified at the end (cluster health, storage, and each public service answering through the tunnel).
5. Working with an AI agent on real infrastructure
If I had to sum up what made this exercise safe rather than risky:
- A clear, partitioned scope. Independent domains, handled in parallel, each with a precise objective. “Audit everything” doesn’t work; “look for committed secrets in these repositories and give me file plus line, values masked” works.
- Demand evidence, not assertions. Every important conclusion must be backed by a reproducible test. “The config suggests” is not “I verified”.
- Gates between steps. In a risky operation, you don’t move on until the previous step is confirmed healthy. An explicit pass criterion before each node, each service.
- Always a way back. A snapshot, a copy of the old binary, a verified backup. You don’t start an irreversible action without a net.
- Keep the human on irreversible decisions. The agent proposes, executes what’s reversible, and stops at the choices that commit you — publishing, deleting, breaking. Final judgement stays at the keyboard.
- Never publish the map of your own gaps. Including in a blog post. Lessons are for sharing; the coordinates of your holes are not.
Takeaways
What struck me most wasn’t that the AI found things — a scanner finds things too. It was the combination: the ability to sweep three heterogeneous sources in parallel, to cross-reference my notes with the actual state of the cluster, to phrase findings as actionable lessons — and, when it was wrong, the fact that the discipline of verification caught it before any damage.
A capable AI agent doesn’t replace judgement. It amplifies a good method — and would amplify a bad one just as well. The value wasn’t in the tool alone, but in the frame we gave it: evidence, gates, rollback points, and a human keeping control of whatever can’t be undone.
The best security audit isn’t the one that reassures you. It’s the one that shows you, calmly and with evidence, what you had stopped seeing.