← Contain it, don't review it

Rules for running
coding agents.

Sixteen rules for getting the speed of agentic coding without becoming a full-time reviewer. Short enough to paste into a repo.

A coding agent rolls dice on every action. Run enough actions and the bad roll arrives. Every rule below assumes that and bounds it, because the governing principle is simple: a rule the agent can decline is not a rule.

Contain

  1. Give the agent a container, never your machine.

    WhyYour machine holds everything you have ever logged into. A container holds exactly what you put in it, so the worst case is a list you wrote yourself.

  2. Deny network egress by default. Allowlist only what the work needs.

    WhyInjection arrives and stolen data leaves through the same pipe, and an allowlist is the only list you can finish writing.

  3. Give the agent an identity, never a stored key. Use OIDC federation so credentials are minted for the task and expire in minutes.

    WhyAnything sitting in the environment can be read by everything running in it. Federation leaves no stored secret to find, and what it mints expires before it is worth stealing.

  4. Never let one session hold all three: secrets worth stealing, untrusted text to read, and a channel to send data out.

    WhyUntrusted text lets an attacker instruct the model, secrets give it something worth taking, and a channel out lets it deliver. Remove any one and the theft cannot complete.

  5. Let it reach the world only through something reviewable. A branch, a diff, a pull request.

    WhyA diff can be checked and reverted before it costs anything. A live action cannot be un-taken.

Verify

  1. Write the specification yourself.

    WhyThe agent can generate everything except the intent. If it writes the spec too, nobody has decided what correct means.

  2. Turn the type system up to its strictest setting.

    WhyThe compiler checks every line of every change with the same attention, for free. An escape hatch switches it off exactly where the agent was likeliest to be wrong.

  3. Derive tests from the specification, never from the code the agent just wrote.

    WhyAn agent testing its own code marks its own homework. A misread requirement produces passing tests for the wrong behaviour.

  4. Work in small, reversible steps.

    WhyA small change fails safely, reverts cleanly, and is the only kind a human can honestly check.

  5. Automate every check you would otherwise do by eye, and make it fail the build.

    WhyYour attention runs out and automation does not. A check that blocks the merge gets fixed. A finding in a report gets ignored.

  6. Pin and verify every dependency the agent adds.

    WhyModels invent package names, the invented names repeat, and attackers register them.

Restrain

  1. Prefer the boring dependency.

    WhyThe cheapest code to review, secure and maintain is the code you did not write.

  2. Ask whether the thing needs to exist before asking an agent to build it.

    WhyCheap generation makes it easy to own code you would never have chosen to own.

  3. Write the decisions down where the code lives.

    WhyEvery future session, human or agent, starts from what is written down. A decision that lives only in your head gets re-made, differently, every time.

  4. Understand what it built. If you cannot explain the system, you cannot own it.

    WhyThe 3am incident, the security audit, and the next feature all need someone who can reason about the design. The agent is not on call.

  5. Own what you ship.

    WhyThe agent wrote it is not a defence. This is the one rule no tooling can enforce for you.

Bound the blast radius, then stop watching. That is what the boundary buys you.