Three Guardrails for Letting an Agent Operate Real Infrastructure

Part three of a four part series on building infrastructure that survives success, following my NITHUB Innovation Fair masterclass, Building Technology Infrastructure for Scale. Part two drew the line between the work an agent should do and the work it should not. This part is about how you enforce that line, because a line you only hope the model respects is not a line.

Say you have decided to let an agent help you operate your product. You are small, you are growing, and you want the help. There is no single switch that makes that safe. There are three separate limits, and they are independent. Constrain the procedure it follows. Gate the privileged actions it can take. Limit what it is even allowed to see. Each one closes a different way things go wrong, and skipping any one of them leaves a hole the other two do not cover.

Guardrail one: constrain the procedure

Left to itself, a model diagnosing a problem will improvise. It will infer steps that sound right, substitute a field name it half remembers, reach for a way of doing things it saw in training instead of the way your actual system works. Most of the time that produces something plausible. Some of the time plausible is wrong, and on infrastructure wrong is expensive.

The fix is to stop letting it improvise. The agent follows a verified, written down recipe, and the recipe opens by telling the model exactly that: follow this procedure, do not infer steps, do not substitute names or paths from memory, verify, then stop. In the demo, that recipe is served to the agent by the Reoclo MCP server, which is just a way for a tool to hand an AI a documented procedure it can follow step by step. That single instruction is the difference between a party trick and something I would run on a Friday afternoon. It turns an unpredictable generalist into a reliable operator that happens to be good at reading logs.

Guardrail two: gate the privileged action

Diagnosis is free. The agent can read deployments, logs, and configuration all day, because reading is cheap and reversible. Acting on secrets or on your live data is not free, and that is where the gate goes.

The important word is gate, not caution. I am not relying on the model to decide it should be careful. The platform decides. When the proposed action is writing a secret and redeploying, the system stops and requires a human, no matter how confident the agent is. The agent can propose the fix, and it can have every tool it needs to apply it, and it still cannot apply it alone. Approval is a property of the system, not a mood of the model.

Guardrail three: limit the blast radius

This is the one people forget, and it is my favourite, because it is not about approval at all. It is about what the agent can see in the first place.

In the demo, the agent works out that a deploy failed because a required secret is missing from the environment. It names which secret. It never reads the value, it never asks for the value, and it never prints one, because it does not need the value to know it is absent. The whole diagnosis runs on the shape of the problem, not its contents. Nothing in the system, not the app, not the status page, not the logs, not the agent output, will show a secret value, so there is no path by which one leaks through the agent even if you wanted it to. This is the same instinct behind envsitter-guard, a small tool I built to keep AI coding tools out of your .env files: let the agent work with your configuration without ever handing it the secrets themselves. When you are moving fast, the leak you never have to worry about is the one where the value was never in reach.

Approval gates limit what an agent can do. Blast radius limits what an agent can touch. You want both, because a gated action that still exposes a password in a log has already failed before anyone clicks approve.

Bounded, not trustworthy

Put the three together and you do not get a trustworthy agent. You get a bounded one. It follows a procedure you verified, it cannot take a privileged action without you, and it cannot see the things that would turn a mistake into a breach. None of that is trust. It is containment, and containment is what actually lets you put an agent in front of a live product without holding your breath.

Next, and last in the series: the ninety seconds where the agent refuses to act, why that stop is the whole point, and the one class of action I do not give it hands on at all.