When Your AI Agent Has Write Access to Production

There's a book that's been circulating in developer circles called Buy Back Your Time by Dan Martell. The premise is simple: burnout isn't about working too hard — it's about spending your hours on tasks that don't deserve them. The Dreams of Code creator invokes it early in his latest video, and I'll be honest, I'm not usually moved by productivity-book energy. But the way he applies it here — not to his schedule, but to his CI/CD pipeline — caught my attention for a different reason entirely.

He built two AI agents that live on physical mini PCs on his home network, wake up when a build fails in GitHub Actions, autonomously diagnose and fix the problem, then open a pull request for human review. He reports — by his own account, unverified — that the machines have each generated "tens of PRs." His framing is productivity. My framing is: there's a lot of interesting security architecture in here, some of it deliberate, some of it instructive by contrast.

Let me explain why this setup is more carefully constructed than most home automation projects I see, and where the residual risk still lives.

The actual problem being solved

His video editor, Kiru, is built in Rust and targets Windows, Mac, and Linux simultaneously — each platform using different video pipeline libraries under the hood. He develops on a Mac, which means Linux and Windows breakages only surface when CI catches them. Fixing those breakages requires a context switch to a different physical machine to reproduce the error, which he describes as "a low-value task" that "happens quite often." The fix is usually not complicated. Verification is binary: the build either passes or it doesn't.

That combination — frequent, low-complexity, easily verifiable — is genuinely the right profile for automation. Not every task is. The structure that makes AI agents reliable is the same structure that makes them safe to run autonomously: constrained scope, clear success criteria, human review at the end. He has all three.

Three ways off-the-shelf agents failed him

His first instinct was to route everything through an existing coding harness — something like Claude Code — and just have it handle the whole job. Three problems killed that plan, and they're worth naming because they show up every time someone tries to run an interactive AI tool in headless mode.

Permissions prompts. Tools designed for human use ask before executing commands. That's the right behavior for interactive sessions. In headless mode, it either blocks indefinitely or requires the --dangerously-skip-permissions flag, which is exactly as alarming as it sounds. He didn't want to use it. Good instinct.

Too much LLM surface area. He was asking the agent to clone the repo, check out the commit, diagnose the failure, write the fix, verify it, and open the PR — all in one LLM-driven flow. The non-determinism compounds across each step. One bad inference early in the chain cascades.

No observability. When your agent does something unexpected in headless mode and you have no logs of what it was thinking, you're debugging a black box.

His solution was a hybrid: use deterministic code for everything that doesn't require judgment — cloning, checkout, fetching failure details from GitHub — and only invoke the LLM for the part that actually needs it: understanding what's broken and writing a fix. This is the pattern that separates working agent systems from demos. The LLM handles ambiguity; code handles everything else.

This is where I put on my security correspondent hat

Let me describe this system plainly: two physical machines on a home network have autonomous write access to a real GitHub repository, use a dedicated GitHub account with an access token, receive instructions from an external CI/CD service, and run LLM inference through a proxy. That's a meaningful attack surface. Here's what he did about it.

Dedicated GitHub account with scoped credentials. The agents don't use his personal GitHub account. They have their own, with a token stored in Doppler (a secrets manager), not hard-coded or stored in plaintext on the machines. This matters because if one of those machines is ever compromised, the blast radius is limited to the agent account's permissions — not his entire GitHub identity.

VLAN isolation. The agent nodes sit on their own virtual LAN, separated from the rest of his home network. Standard practice for any machine running automation, but regularly skipped by home lab builders who don't think the threat model applies to them. It does.

Tailscale for the network layer. Rather than punching a hole in his firewall or exposing the machines to the public internet, he used a zero-config private network built on WireGuard. GitHub Actions communicates with the nodes through this encrypted mesh; nothing is listening on a public port. The nodes are unreachable to anyone not on his tailnet.

Now, a note on one specific product he mentions: he describes a feature called "Tailscale Aperture" as an LLM proxy that lives on the tailnet, logs all agent prompts and responses, and lets him centrally manage API keys so the agents never hold them directly. This is genuinely elegant security design — if an agent node is compromised, there's no API key to steal, and there's a full audit log of everything the agent said and did. However, I cannot independently verify that "Aperture" is a publicly released Tailscale product at time of publication. It may be a beta feature, a recently announced capability, or something introduced after my knowledge cutoff. Treat that specific product name as unverified until Tailscale's documentation confirms it. The principle — proxy your LLM calls through a controlled gateway that holds the keys — is sound regardless of which tool implements it.

What's the failure mode? The honest answer is: the human-review step is doing a lot of load-bearing work here. The agents open pull requests; they don't merge them. That gate is what keeps an LLM hallucination from becoming a production incident. If someone building a similar system removes that gate — or sets it up and then rubber-stamps every PR — the architecture degrades fast. The security properties here depend on the human staying in the loop, which is a social control, not a technical one.

What this looks like if you're not writing Rust compilers

Most of my readers aren't building cross-platform video editors in Rust. So let me translate the principle, because I think it's genuinely portable.

The pattern is: find a task that's repetitive, low-complexity, and has a binary success condition. Build the deterministic scaffolding yourself — the API calls, the environment setup, the verification step. Drop an LLM into only the part that requires inference. Route credentials through a proxy that holds the keys. Keep a human in the review loop. Isolate the machine running the agent from the rest of your network.

That's it. You could implement a version of this for automated dependency updates, for flagging failing tests with suggested fixes, for monitoring a data pipeline and drafting incident reports. The Rust crate he used — called Cersei, which he says in the video is a reference to A Song of Ice and Fire, though that's his own attribution and I can't independently confirm the naming — is one implementation. There are others. The developer automation space is producing new tooling fast enough that the specific library matters less than the architecture.

The lawn mower comparison he opens with is actually more precise than he lets on. He didn't build the Navimow — he bought one, pointed it at his lawn, and let it run within a bounded area. His AI agents work the same way: bounded scope, defined environment, human decides the edges. That's not a coincidence. It's the only configuration where delegating to a machine actually works without creating new problems.

Most people who get this wrong skip the boundaries. They hand an agent the keys to everything and then wonder why it does something unexpected. The correct move is to hand it keys to almost nothing, and then watch what it does with them.

---

Rachel "Rach" Kovacs is Buzzrag's cybersecurity and privacy correspondent.