How to write and enforce AI guardrails

Most organisations that have done any AI governance own a policy that says what people must not do with AI. Almost none of them own anything that stops it happening. The distance between those two states is the distance between a document and a guardrail, and closing it is less about technology than about writing rules that can be enforced at all.

What a guardrail is

A guardrail is a governance decision made executable, meaning a specific rule about AI traffic or agent actions, applied at request time. It can cover what may not go into a model, such as personal information, credentials, client data or material outside a system’s approved purpose. It can cover what may not come out, such as content that fails your standards for the context it ships into. And it can cover what an agent may not do, such as tools it may not call and actions beyond its approved scope. Budgets and rate limits belong here too, since a cap on spend or volume is a rule the gateway can apply to each request.

The test of whether something is a guardrail is whether a machine could apply it to a single request. “Staff must exercise care with confidential information” fails the test and belongs in the policy. “Detect and redact personal information in prompts to these three systems” passes. Both have a job, and confusing the two is how organisations end up with policies that pretend to be controls.

Start from assessed risk, not a blank page

The tempting way to write guardrails is to brainstorm everything that could go wrong and block it all. The result is a wall that teaches people to route around it, and a rule set with no connection to any finding, which makes every rule equally arguable. The better path runs through work you have already done. Each risk assessment finding that calls for a control is a candidate guardrail, scoped to the systems the finding concerns. The connection matters twice over. It keeps the rules specific enough to live with, and when someone asks why a rule exists, the answer is an assessment rather than an opinion.

Write each rule with its scope, its action and its owner. Name which systems and agents it applies to, whether it blocks, redacts, reroutes, warns or escalates for review, and who answers for it. A guardrail without an owner is a rule nobody will defend when it inconveniences someone senior.

Layer the rules. A global floor that applies to every system, such as personal information redaction and prompt injection screening, plus system-specific rules where an assessment calls for more, keeps the common protections consistent without forcing every system into the strictest setting.

Test each new rule before it blocks anything

A new rule enforced on day one will catch things nobody expected, some of them legitimate. Run it in observe-only mode first, where it evaluates every request and records the verdict it would have applied without touching the traffic. A week of observed verdicts tells you whether the rule is too broad, too narrow or about right, and gives you the numbers to defend switching it on.

Enforcement lives where the traffic is

A rule enforced nowhere is a policy with better formatting. Enforcement means the request path, the route every AI request takes, so a gateway or enforcement point that AI traffic passes through, where the rule can act on each request as it happens. If your organisation already routes AI traffic through a gateway, the right move is usually to compile your rules to the enforcement points you have rather than adding another. Decide in advance what happens when a scanner or the gateway itself is unavailable, failing open or failing closed, because that choice is a governance decision too.

What matters is that the deployed rules are versioned and attributable, so at any later date you can say which rules were enforced on which systems, in which versions, when. An unversioned enforcement point enforces whatever it enforces, and you will not be able to prove what that was.

Agent guardrails deserve their own attention. For a system that acts, the consequential rule is not about words but about actions, meaning which tools the agent may call, what scope its actions may have and what happens when it exceeds them. The guide on governing AI agents covers the wider practice.

The record is half the value

Every intervention should leave a record of what fired, on which system, under which rule and version, and when. Partly this is operational, because firing patterns tell you which rules are working, which are too broad and where unmet demand is pooling. Mostly it is evidentiary. The difference between a control that exists on paper and a control with a record of operating is the difference between asserting your governance and demonstrating it.

Where Aicura fits

At Essentials, Aicura suggests rules drawn from your register, permissions and the controls your risk assessments produced, so each suggested rule carries its origin. You write them as guardrail sets against registered systems and agents, with a global floor and system-specific rules layered on top, and publishing creates a signed version that cannot be changed afterwards. Rule types cover personal information redaction, topic denial, prompt injection, jailbreak, secrets and toxicity scanning, and lists of approved tools and models, and any rule can run observe-only.

At Pro, published versions deploy to Aicura’s AI gateway or export as signed rule packages for a gateway you run, and every intervention is recorded as an enforcement event against the system it concerned and the version that fired. Which rules to run and how strict to be stay with your accountable owners.

A note on this page

This guide describes an approach to writing and enforcing guardrails, and the right rules for your organisation depend on your systems, your obligations and your risk appetite. It maps to the controls expected under ISO/IEC 42001 Annex A and the Manage function of the NIST AI RMF. It is general information, not legal advice, and rules that touch monitoring of staff activity should be checked against your own workplace and privacy obligations first.