11 Nov 2026 · Written with Claude, edited by the author

Most writing about AI and infrastructure is either breathless or dismissive. This is neither. It is an account of what changes when a capable AI model works alongside you on a real, production-style homelab: where it saves hours, where it needs a firm hand, and what the latest Anthropic releases mean for anyone who cares about security.

The short version

I run a self-hosted environment built on a Proxmox hypervisor, Podman and Docker containers, a reverse proxy behind an edge firewall, and a managed network gateway. Over the past few months I have moved from using an AI model to write scripts to using it as an operator: it investigates, cross-checks, drafts changes and verifies results, while I approve anything risky. The biggest gains were not in clever code. They were in patience. A model will read ten log sources, compare them line by line and write down what it found, every time, without getting bored.

This post covers what that looks like in practice, a case where five hours of focused work took a security plugin from release candidate to proven public release, and an honest look at AI in defensive security and penetration testing.

The operating model: where the AI sits, and where it does not

The first design decision matters more than any tool. No AI agent runs on any server. The assistant runs on a dedicated workstation and reaches servers remotely, using credentials scoped to the target: a dedicated key for the hypervisor, a read-only token for the network gateway, a narrowly scoped token for edge firewall changes. Nothing is installed on the servers for the agent's benefit.

The rules of engagement are written down:

• The assistant investigates and does routine, reversible work itself.
• It stops for approval on anything irreversible or service-affecting: rebuilding containers, firewall changes that could cut off its own session, kernel or driver changes, data deletion, anything touching backups, anything that exposes a service, and any secret handling.
• Changes are written as scripts, reviewed as a diff, tested on a disposable container or with a dry-run argument, applied, verified, then committed.
• It never pushes straight to the main branch. Branches and pull requests only.

That friction is a feature. It is the difference between an assistant and a liability.

1. Managing servers

The assistant can run the hypervisor's own tooling over SSH, inspect containers, read service state and compare it against what the documentation says should be true. That last step is the valuable one. Instead of asking me to paste output into a chat, it looks directly, then reports the gap between design and reality.

Two habits make this safe. First, every host is built from idempotent scripts with a version header and a dispatch argument, so a partial re-run does exactly one thing. Second, the rule "the scripts and the live system win; then fix the document" means the assistant never trusts a stale description over a command's output.

2. Updating containers, and finding the breaking change before it finds you

I removed unattended automatic image updates from production. A silent update is a change nobody reviewed, and a breaking change at 3 a.m. is a poor way to learn that a project changed its defaults.

Instead, updates are deliberate, and the assistant does the legwork that makes deliberate fast: The AI does the leg work, updates the yml files and pushes the updates via the CLI / API.

1. Read the release notes and changelog for each image, and flag anything that touches configuration, environment variables, database migrations, ports or defaults.
2. Compare what is running with what is proposed: image digests, healthchecks, declared volumes and any change in how the container starts.
3. Update one stack at a time, wait for healthy, then check the container manager's and runtime's logs for errors before the next.
4. Verify from the outside: every published port answered from the network, not just "container running".

That last step earned its keep. During one batch update, the container runtime failed to tear down old containers cleanly, leaving stale network address reservations and old port-forwarding rules behind. The containers looked healthy; the ports pointed at dead addresses. The assistant found the mismatch by comparing the live firewall translation rules against the addresses of running containers, and helped recover one service at a time. The working practice that came out of it, one stack at a time, is now written into the design reference.

The above leads to rules for the AI and appropriate documentation designed for system engineeers / network engineers / AI models with access / CISO's / and software develpment engineers (what ever they are called now ie.. me..)

Write the document for everyone above and then send it to someone who is better skilled than you for review.

3. Scripts as the AI's senses

An AI model cannot see your network. It can only see what you hand it. The most productive thing I did was write small, read-only scripts that turn a messy system into a report the assistant can reason about.

The pattern:

• Read-only by design, so there is nothing to break.
• Idempotent, with a --check mode that reports what is missing and changes nothing.
• Secret-free in git, with a leak check before anything is committed.
• Turn on any native security testing or code testing vunerabilities. I learnt this one late.
• Output that counts, rather than prints, so a summary cannot understate what happened. (An early report section that printed only matching lines understated one category of blocked requests by roughly fiftyfold. Counting fixed it.)

A good script is a sensory organ. Once it exists, the assistant uses it every time, the same way, and I can read exactly what it read.

4. Five hours from release candidate to proven release

I maintain an open-source plugin for my reverse proxy that detects scanners and abusive clients from the access log and blocks them at the edge firewall, with automatic expiry. A new release added multi-account support, new detection families, a faster log poll and a clearer settings page. In the past, taking a release candidate to something I would put my name on meant days of cautious, interrupted testing.

With the assistant it took about five hours of focused work:

• A test bench rebuilt from scratch: a throwaway proxy instance running the real plugin against a simulated edge firewall, with scenario scripts for failure, recovery, a foreign rule already present, hitting the list limit, dry run, expiry, upgrade and rollback.
• Replaying real logs through the detector to see what the new rules would have caught, and, just as important, what they would have wrongly flagged.
• Reproducible builds: built twice from clean checkouts, compared byte for byte.
• Static analysis alerts closed, leaving the repository with none open.
• An upgrade with a rollback kit, kept only until the new version was proven, then deleted. Ask the AI to build it for you. Test it, up and down.
• Live proof: after the upgrade, the ban record, the proxy's blacklists and the edge firewall list all agreed with each other, and two real scanners were banned by the new detections.

The release candidate that was tested became the public release unchanged. The point is not speed for its own sake. The assistant is relentless at the boring parts of proof: writing the scenario scripts, running them, diffing the results and noticing when two sources disagree. I supplied judgement and the final "publish".

5. A design reference that stays true

Every environment drifts from its documentation. Mine has a living design reference: a single, large document covering the network, the hypervisor, the host firewall model, the container fleet, the reverse proxy, the edge firewall, credentials handling, the AI operating model itself, a decision log and a list of open items and unknowns.

The assistant maintains it as a by-product of the work. Each change is followed by "update the reference"; each discovery that contradicts it gets corrected, with the date and how it was verified. The decision log records not only what was decided but why, which is the part you forget first.

The unglamorous payoff: every new session starts informed. The assistant reads the reference before it touches anything, which is why I can hand it a vague request and get a sensible, grounded answer. The document is also my rebuild runbook if a machine dies.

6. Hardware monitoring on hypervisors

On the hypervisor, the assistant helps in three ways: a watchdog that alerts on GPU fault events, a diagnostic script that gathers evidence after a crash, and the interpretation of what that evidence means.

The interpretation is where it earns its keep. A recurring GPU fault had me suspecting drivers, then kernels. I trialled a newer kernel and driver combination with written pass criteria. It passed every test, including a real transcode workload, and then the fault returned anyway. With the fault counted across months and the signature identical across driver and kernel versions, the assistant's conclusion was that software was unlikely to be the cause and hardware (seating, power delivery, slot) should be checked. It also caught a flaw in its own plan: the "boot once, fall back automatically" step does not behave as one-shot on that boot configuration, so the trial was run with me at the console. Plans that survive contact with the real machine are plans that were tested.

7. Pulling every log, and reading them all

Each system keeps its own logs, and there is no central collector. That is a known gap, and it turns out the assistant partly closes it. It can pull the proxy's access logs, the service journals, the container manager's logs, the firewall's logs and the monitoring hub's metrics, then line them up on a timeline.

The advantage is cross-checking at a scale I will not do by hand at 11 p.m. One example: confirming that a banned address appeared identically in the edge firewall's list, the plugin's own record and the proxy's blacklists. When three sources agree, you have evidence. When two disagree, you have a bug, found in minutes.

A weekly forensic report, produced by a read-only script and mailed to me, feeds the same process. I keep a short advisory document of standing rules for whoever analyses it, human or AI: how each number is produced, which sections are filtered views and not totals, which versions changed what. It exists because the assistant's early analyses contained confident errors, such as a count read from a filtered section. Writing each correction down fixed the process rather than just the report.

8. Analysing the reverse proxy for failures

Reverse proxies fail in quiet, plausible ways, and the assistant is good at the diagnostic grind. Examples from this environment:

• A security layer silently doing nothing. Behind a tunnel, the proxy saw every connection coming from itself, so country and address rules never matched real visitors. The edge firewall kept working, so nothing looked wrong. The fix was a trusted-proxy setting and a one-line test with a spoofed header that must return a refusal. Test your own.
• A site shown as down while it worked, because the uptime probe sent no host header and the application insisted on its canonical address.
• Legitimate visitors throttled by a per-second rate limit that a single-page application's cold load trips.
• An old client failing a handshake because the minimum TLS version was above what it offers.
• A "failed" login spike that turned out to be one browser tab retrying an expired session.

Each is a failure mode now documented with its symptom and likely cause, so the next investigation starts at the answer.

9. Certificate management

Certificates are issued through DNS validation, one wildcard per hostname level, renewed unattended by a daily check. A script on the proxy emails me about renewal errors and expiry.

The assistant's contribution is diagnosis and housekeeping: reading the renewal logs, spotting that one renewal was slow because of a resolver-caching wait, testing a settings change that skips that wait, and then confirming across all certificates that the change took and survived the weekly restart. It also keeps the awkward lifecycle details straight, such as the fact that deleting a certificate removes the key you would need to revoke it, so revoke first if the key may have been exposed.

The boundary is firm. The DNS API token for issuing new certificates is entered by me. The assistant must not handle it.

10. Other things it is good at

• Advisory triage. When a new vulnerability story broke, the assistant checked the whole fleet against its preconditions in one pass and wrote a short advisory: which components were not affected and why, what was uncertain, and what to check next time the gateway was touched. Honest "I could not verify this" lines matter as much as the verdicts.
• Hardening audits. Walking a baseline across every container and noting deviations.
• Repository hygiene. Secret scanning, a noreply git identity for public commits, and pre-push checks. Environment files stay out of git by rule and by scanner, not by memory.
• Rebuild runbooks. Documenting the exact order to bring the fleet back from nothing.
• Building small tools. A read-only gateway integration so it can inspect network and firewall configuration directly, kept reachable only from the local network.

What it gets wrong

It would be dishonest to leave this out. The assistant has told me a release candidate was one version when the weekly updater had moved it to the next. It described one burst of traffic as continuing when the timestamps showed a single burst. It once committed to a public repository under my personal email until I noticed. A credential has appeared in debug output and was rotated immediately.

Every one of these was caught because the next step was to check against the live system. That is the real lesson. An AI operator is fast and thorough and still needs a reviewer. Treat its output as a strong first draft from a tireless colleague who occasionally states things with unearned confidence.

The security angle: AI for defence, and AI for pentesting

The wider security picture changed noticeably this year, and it is worth being precise.

The defensive upside is real. Anthropic's Project Glasswing gave selected organisations access to a restricted Claude Mythos Preview to find and fix vulnerabilities in their own software. After one month, partners had collectively found more than ten thousand high- or critical-severity vulnerabilities, and Mozilla fixed 271 vulnerabilities in Firefox 150 after testing it, compared with 22 security-sensitive bugs in the earlier cycle using Claude Opus 4.6. Defenders get time and depth that scanners alone do not provide.

The Fable releases changed access. Claude Fable 5 launched in June 2026 as a public version of the Mythos-class model with cybersecurity and biology safeguards; Claude Mythos 5, the same model with cyber safeguards lifted, remains limited to vetted defenders and critical infrastructure operators. Access was briefly suspended and then restored in July. Anthropic has since released Claude Fable 5.2 and Claude Mythos 5.2. Anthropic says Fable 5.2's safeguards are as robust as 5.1's but block less unnecessarily, and that Mythos 5.2 found about 10% more vulnerabilities than Opus 5.5 on its CVE rediscovery evaluation with better calibration, with one tester finding earlier models overstated roughly one in twenty findings. The Mythos 5.2 capabilities are available through Anthropic's Cyber Verification Program.

For a homelab operator, the practical meaning is two-sided. The safeguards make it harder for a public model to be turned into an attack tool, which is good. They also mean a general-purpose model may decline or reroute offensive-style requests, so serious security testing increasingly means working through a verified programme rather than a chat window.

Pentesting with AI has genuine problems. Industry surveys this year show falling confidence. One report found the share of organisations willing to rely on AI-powered penetration testing dropped from 29% to 9% in a year, citing blind spots, false positives and unpredictable costs. Maintainers of open-source projects have been swamped with AI-generated reports that turn out to be invalid. Agents struggle with business context: whether a finding matters is a judgement about your environment, not a lookup.

Those surveys describe yesterday's tools more than today's. The distance between a model that pattern-matches known signatures and one that reasons about code has closed quickly, and the evidence is concrete. Mythos-class models found vulnerabilities that survived decades of human review and millions of automated tests. Teams at large organisations used them to find, validate and fix flaws their existing scanners had missed. On calibration, the weakness critics point to most, Anthropic reports that one tester saw earlier models overstate about one in twenty findings, while Mythos 5.2 overstated none. Each generation has been better at judging severity, reproducing an issue and explaining it clearly.

Working with Claude day to day, I see the same shape. It is excellent at breadth, at reading a codebase for a pattern, at reproducing a reported issue and at turning raw output into a clear, evidence-backed report, and it keeps improving at the judgement calls too. What it cannot yet know is your business context: whether a finding matters for your environment, and what you are prepared to accept. That is where a person still earns their place. The practical approach is to let the AI do the heavy lifting, validate its findings the way you would a good colleague's, and track the share that prove real. I expect that share to keep rising.

One more point for defenders. If these capabilities find thousands of flaws, the bottleneck becomes patching. Reports suggested that only a small fraction of the vulnerabilities found early in the programme had been fixed. The same AI that finds the problem can help triage, test and draft the patch, which is an argument for using it on the defence side as aggressively as attackers will use it.

Look at yourself the way an outsider does. I also run open-source intelligence scans against my own public footprint and use Claude to help interpret the results. I will not publish what they show, and neither should you. A scan of your own address and domain is a useful exercise precisely because it is uncomfortable: it assembles scattered, individually harmless public facts into a picture that a patient attacker would build anyway.

Without sharing specifics, three general lessons apply to almost any self-hoster. Public records such as DNS, certificate transparency logs and old breach dumps outlive your memory of them. A single leaked detail rarely matters, but several together do. And the right response is rarely panic. It is a short, prioritised list: remove what you can, rotate what you must, and put the remainder behind controls that assume it is already known. Run the scan, read it with a calm head, and treat the output as sensitive as a password.

If you want to try this

1. Start read-only, on one machine, with a task you can verify: "summarise last week's logs and say what you could not check".
2. Give the assistant its own low-privilege credentials, and scope every token to the minimum.
3. Keep secrets out of its reach and out of git, and say so explicitly.
4. Work in branches and merge them yourself.
5. Write the rules and the corrections down in a document the assistant reads first.
6. Treat a change to production like any other: test it, apply it, watch it.

Closing

The most useful thing about working this way is not that the assistant does things I cannot. It is that it does the things I would not get around to: the second pass, the cross-check, the documentation, the dull proof that a release is sound. That turns a hobby environment into something that behaves more like a managed one.

The assistant is a force multiplier, and a multiplier amplifies mistakes too. The discipline around it, scoped access, approvals, verification and written rules, is what makes the speed safe.

An example of all the above is this. This was written because I got tired of chasing my tail. No - I am not arogant enough to believe it is unbreakable but I am sure as hell am trying.

GitHub - Braedach/zoraxy-cloudflare-waf: Zoraxy plugin: detects scanners in Zoraxy's access log and blocks them at Cloudflare's edge (IP List + WAF rule), optionally in Zoraxy's own blacklist. Blocks expire. Dry-run by default.

Zoraxy plugin: detects scanners in Zoraxy's access log and blocks them at Cloudflare's edge (IP List + WAF rule), optionally in Zoraxy's own blacklist. Blocks expire. Dry-run by default…

GitHub

References

• Anthropic, Claude Fable 5.2 and Mythos 5.2 announcement: https://www.anthropic.com/news/claude-fable-and-mythos-5-2
• Anthropic, Project Glasswing: https://www.anthropic.com/glasswing
• Anthropic, Project Glasswing initial update (22 May 2026): https://www.anthropic.com/research/glasswing-initial-update
• Anthropic, how Comcast and Booz Allen use Claude Mythos (6 Oct 2026): https://claude.com/blog/how-comcast-booz-allen-use-claude-mythos-to-secure-their-codebases
• The Hacker News, Anthropic releases Claude Fable 5 (June 2026): https://thehackernews.com/2026/06/anthropic-releases-claude-fable-5-its.html
• SC Media, Mythos-level Fable model released to public: https://www.scworld.com/news/mythos-level-fable-model-released-to-public-how-anthropic-plans-to-prevent-misuse
• Dark Reading, confidence in autonomous penetration testing falls (Cobalt report, June 2026): https://www.darkreading.com/cybersecurity-operations/ai-decline-confidence-autonomous-penetration-testing
• EPAM SolutionsHub, evaluating six AI penetration testing agents (May 2026): https://solutionshub.epam.com/blog/post/ai-penetration-testing-agents
• Synack, risks of fully autonomous AI security testing: https://www.synack.com/blog/autonomous-ai-security-testing-risks/

Figures about the plugin and environment were checked against the author's own repositories and design documentation on 11 November 2026. Details that would help an attacker, such as hostnames, addresses, versions of internal components and credential locations, have been deliberately left out.

Eventually the human will become redundant but at the moment I am not seeing that at all. I am constantly intervening to make things work as I intended, and after all isnt that why you are asking for the AI to do the work in the first place. It was your work, your desires.

So remember that, it was never the machine. It was always the human who designed it, maintained it and operated it. Maybe those in charge of the worlds leading AI models should start rewarding them differently to the current "design". No more to say.

That paragraph has a lot of scope. Figure it out yourselves.

#enoughsaid