The rules we give Claude before it touches a live server

We use Claude every day to run client platforms: it reads logs, writes the fix, tests it on staging and prepares the deployment. It has access to the servers. That sentence should make anyone responsible for a live store pause, and it made us pause too. So before Claude touched the first production system we wrote the rules it works under, and they have held up for months across every site we run. Here they are.

Read freely, change deliberately

Reading is cheap and reversible. Claude can inspect any log, config or database on any server without asking. Changing is neither. Any command that writes to a live system is announced first with what it will do and why, and the destructive class of commands, such as deleting data, dropping tables, restarting services, is off limits in automatic mode and only runs when a person approves that specific command. The distinction is enforced by the tooling, not by good intentions: the allow-list of commands that may run unattended is a short file we maintain by hand.

Staging first, always

Every change goes to the site’s staging copy before production. Claude follows the same staging discipline we ask of ourselves: clone from live, test the change, run the checklist, then apply the identical steps to production. A fix that cannot be tested on staging is a fix that waits.

Never edit what we did not write

Vendor code, purchased themes, core application files: never patched, by Claude or by us. A fix goes into configuration first, then into a module or plugin of our own, then into a child theme. This is the rule that keeps upgrades boring, and it is the one Claude is most tempted to break, because the quickest fix is usually one line in a file that belongs to someone else. The rule is written down, so the quickest fix is not the one it proposes.

Verify before claiming

A fix is not done when the command ran. It is done when the live page, the live checkout or the live form has been exercised and the result observed. Claude reports what it saw, not what it expects, and a statement that is true but beside the point counts as wrong. When tests fail, the failure and its output go in the report. This rule exists because the most dangerous assistant is a confident one.

Nothing leaves without a person

Claude drafts email, never sends it. It prepares client reports, and a person reads them before a client does. It never posts to a client’s social channels, never changes a DNS record and never modifies an account setting without that step being approved in the moment. Anything outward-facing or hard to reverse has a human in front of it, every time, even when the same action was approved yesterday.

One identity per client

Each client’s systems are accessed with that client’s credentials, keys and service accounts, kept apart from every other client’s. Claude is never given a key that opens two clients’ doors. This is good practice for people too, but it matters more for an assistant that works across a dozen platforms in a day and could, without this rule, carry context from one into another.

It remembers what it has been told

Every correction becomes a written rule with the reason behind it, and Claude reads those rules at the start of every session. “Do not run the cache clear as root on that site” is not a thing we want to discover twice. Over months the rulebook has become a fair description of how we work, which was not the aim but is a useful side effect.

What this buys

With these rules, Claude does the work of an experienced operations engineer across every platform we run, and it does it with better notes than most. Without them it would be a fast way to make a bad day worse. The rules are the deployment. The model is the easy part.

This is the same discipline we set up when we deploy Claude in a client’s business: the guardrails come first, and they are specific to the work.