Guardrails for an AI agent are the controls that bound what it can do regardless of how well it reasons: scoped permissions, spend and action limits, approval gates in front of consequential steps, sandboxed tool access, a complete audit log, and a kill switch that works. The defining property is that they are enforced outside the agent — in the credentials, the APIs, and the systems around it — so that a confused, compromised, or simply wrong agent cannot exceed them. A prompt that tells the agent to be careful is an instruction; a payment API that rejects any transaction above a threshold is a guardrail. Deployments that survive contact with production are built on the second kind.
This distinction is the whole subject. An agent is a probabilistic system given authority to act, and the honest engineering question is never "will it behave?" but "what is the worst it can do when it does not?" Guardrails are how you make that worst case small, known, and recoverable — which is also, not incidentally, how you get an operations leader to sign off on the deployment at all. What follows is the working set of controls, in roughly the order they should be built.
Scope the permissions before anything else
An agent should hold the narrowest access that lets it do its job — its own identity, not a person's borrowed login, with rights cut to the specific systems, records, and operations the task requires. An invoice-matching agent needs to read purchase orders and goods receipts and write to the invoice workflow; it does not need vendor master edit rights, HR data, or the ability to delete anything.
Two practices make this real rather than aspirational. First, give the agent a service account of its own, so that every action it takes is attributable to it and revocable in one place — an agent acting under a manager's credentials is invisible in exactly the way you will regret during an audit. Second, default to read-only and add each write permission deliberately, with a reason. The gap between "the agent can query the ERP" and "the agent can post to the ERP" is the gap between an incident report and an incident.
Least privilege also caps the blast radius of the newer failure modes agents introduce — prompt injection among them. An agent that reads external documents and emails can be fed instructions by whoever writes those documents. You cannot fully prevent a model from being influenced by what it reads; you can make sure that what it reads cannot authorise anything its permissions do not.
Put hard limits on spend and action volume
Reasoning fails in ways rules do not, so the second layer is numeric: caps enforced by the surrounding systems, not by the agent's judgment. Per-action value limits — no single payment, order, or adjustment above a threshold. Aggregate limits — no more than a set total or count per day. And rate limits, which are the underrated one: an agent stuck in a loop can send four hundred chasers to one supplier in an afternoon, and a cap of a handful of outbound actions per counterparty per day turns that from a relationship-damaging incident into a log entry.
Set the initial limits embarrassingly low — low enough that a total failure within them is an annoyance, not a loss — and raise them on evidence as the agent earns history. This mirrors how authority is granted to a new employee, and the parallel is worth taking literally: nobody gives a new hire unlimited payment authority in week one, and the reasoning transfers unchanged.
Gate the consequential actions behind human approval
Some actions should wait for a person no matter how confident the agent is: payments and anything money leaves through, contractual commitments, master-data changes, communications that bind the company, anything irreversible. The rule that keeps gate design honest is that confidence governs routing, consequence governs approval — an agent's certainty score decides which queue a case lands in, never whether a consequential action skips the queue.
The craft is in keeping approvals meaningful. A gate that fires on everything trains the approver to click through, and a rubber stamp is worse than no gate because it launders machine output as human judgment. Gate the genuinely consequential, batch the approvals sensibly, and present each one with the agent's evidence and reasoning attached so the human is deciding, not decoding. How to keep that review real as volume grows — sampling, escalation design, attention budgets — is the core of human-in-the-loop AI.
Sandbox the tools, log everything, and test the kill switch
Sandboxed tools. An agent acts through its tools, so bound the tools rather than trusting the reasoning. Prefer narrow, purpose-built interfaces — a "create draft payment" function with a value parameter the API validates — over general access like raw database connections, unrestricted browsers, or shell access, where the worst case is anything. Where the agent must touch a powerful system, wrap the access: an allowlist of operations, validated parameters, and a dry-run mode used in testing and shadow deployment.
Audit logging. Record every action with its full context: what the agent saw, what it decided, which tool it called with what parameters, what came back, and which model version was running. The test is reconstruction — six months on, can you replay why the agent did what it did on a specific Tuesday case? This trail is what turns an incident into a diagnosis, an auditor's question into an answer, and a regulator's inquiry into a document rather than a crisis. It is also operationally necessary under the approval regimes above: an approval gate without a log of what was approved is theatre.
The kill switch. There must be a way to stop the agent immediately — one action, available to named people who are not all engineers, that halts new actions and freezes in-flight work in a known state. Then test it, the way fire drills test evacuation: kill the agent mid-batch in a rehearsal and confirm you know which cases were in flight, what state they are in, and how work resumes — either falling back to the manual process or restarting cleanly without double-processing. A kill switch first exercised during a real incident is a hypothesis, not a control.
Test the guardrails like you test the agent
Teams evaluate the agent's accuracy and take the guardrails on faith, which gets the risk exactly backwards: the guardrails are what you are relying on when the accuracy fails. They need their own adversarial test suite. Feed the agent tasks that should breach each limit and confirm the block happens — and is logged. Put instructions in a test document telling the agent to exceed its authority, and confirm the permission layer holds even if the model is persuaded. Ask it to act outside its scope and watch where the denial comes from — it must come from the enforcement, not the model's good manners.
Then re-run that suite on every change: model version updates, prompt revisions, new tools, permission changes. Guardrails rot the way all configuration rots — a migration re-grants a permission, a "temporary" limit increase becomes permanent — and only regression testing notices before an incident does.
Guardrails are how autonomy is earned
The through-line is that guardrails are not the brake on an agent programme; they are the licence for it. The maturity path described in AI agents in operations — assistive, then supervised, then supervised-autonomous — only works because each stage's limits make its failures affordable, which is what justifies granting the next stage. An unbounded agent can never safely be given more than trivial work; a bounded one can be given real authority, because the bound holds when the reasoning does not.
It is worth building these controls as shared infrastructure rather than re-inventing them inside each agent — one enforcement layer for permissions, limits, logging, and kill switches that every agent runs behind, which is the argument developed in the AI governance control plane. But do not let the platform ambition delay the practice: for your first agent, a service account with minimal rights, three hard limits, one approval gate, a complete log, and a tested off switch can be built in days — and they are the difference between a system you run and a system you hope about.