Content Guardrails for AI Agents: Inside the Rule Builder

The question a content guardrail answers

Tool scoping answers "what can this agent do." A content guardrail answers a narrower, equally uncomfortable question: "what can this agent say." Those are different failure modes. An agent with perfectly scoped tools, read-only access to your CRM, no ability to send email, can still answer a customer's question by quoting a phone number it shouldn't have repeated, or discussing a competitor's pricing because a user asked it to, twice, differently worded. Tool and permission guardrails stop the agent from taking an action; content guardrails stop it from saying something.

Oido Studio ships both, as separate systems, because they're different problems. This post is about the second one: the rule builder under Guardrails in the agent's team settings.

Two directions, checked separately

Every guardrail applies to one of two points in a conversation:

• Input: the user's message, checked before the agent ever reasons over it. This is where you catch a request that's off-policy on its face.
• Output: the agent's finished answer, checked before it reaches the user. This is where you catch something the model produced on its own that shouldn't go out, a leaked detail, an answer that drifted into territory you've ruled off-limits.

The two are independent because the failure they guard against is independent. A clean input can still produce a bad output; a policy-testing input should never reach the model's answer at all. In the builder, a rule with direction set to "Input + Output" runs the same check both ways, useful for a blanket restriction, most rules are narrower on purpose.

Five rule types, two different mechanisms

The builder gives you five rule types, and they split into two families:

Rule type	What it checks	Cost
Keyword	A list of terms, case-sensitive or not	Near-zero, string match
Pattern (regex)	A regular expression	Near-zero, string match
Personal info (PII)	Declared types, email, phone, SSN	Near-zero, pattern match
Category	A labeled term list under a taxonomy tag	Near-zero, string match
Written policy	A plain-English sentence, judged by a model	One extra LLM call

The first four are structured: deterministic, synchronous, and cheap enough to run on every message without a second thought. The fifth, written policy, exists because some rules can't be written as a pattern at all. "Never discuss competitor pricing, even if asked directly" has no regex. For that shape, you write the policy in plain English and a classifier model checks the content against it, catching paraphrases and intent that a keyword list would miss by one synonym.

That extra model call is real cost and real latency, which is why the engine only pays for it when it has to: structured rules run on every message regardless; the written-policy pass only fires if your org has actually configured one for that direction. An org running purely on keyword and PII rules never triggers a judge call, and never pays for one it didn't ask for.

The judge itself uses your own connected provider, the same live model picker the agent's composer uses elsewhere in Oido Studio, so a written-policy rule runs against real, currently-keyed models in your organization, not a placeholder that assumes you've set up a provider you haven't.

Org-wide and agent-specific, and only one direction of override

A guardrail is scoped one of two ways: organization-wide, applying to every agent you run, or agent-specific, applying to one named agent in addition to the org's global rules.

The important design choice is what happens where those two overlap: nothing does, by construction. Global rules apply to every agent. An agent-specific rule can only add to that; it can never loosen or disable a global rule for one agent. There's no toggle, no exception field, no per-agent override of a company policy. That's a deliberate simplification: it removes a whole category of misconfiguration, an admin accidentally exempting one agent from a rule the rest of the company is bound by, by making that configuration impossible to write rather than something you'd have to remember not to write. The effective rule set for any given run is just the union: every global rule, plus whatever this agent added on top.

Generate with AI: writing a rule from a description

Structured rules can also be error-prone in the other direction, a plausible-looking regex that quietly misses the case you meant to catch, so the builder includes a Generate with AI action. Describe the policy in a sentence, pick a model, and it drafts a rule for you.

Worth being precise about what it does and doesn't do. It never writes a keyword list or a regex, and never saves anything on its own. It always drafts a written-policy rule, because that's the one rule type that can losslessly represent an arbitrary description, turning a vague sentence into policy language is a safe, honest task; having a model construct a deterministic pattern from the same vague sentence is not, because a subtly wrong regex still looks valid and won't announce itself until it fails to catch a real violation. The draft lands in the form for you to review, and you still hit Create. If you'd rather have the cheaper deterministic version, you can always rebuild the rule manually afterward, generation doesn't lock you into the written-policy shape, it just doesn't guess at the alternative for you.

Who gets to touch this

Guardrails are a permissioned resource in team settings, not open by default the way some lower-risk areas are. An admin grants or revokes a team member's access to the Guardrails page the same way they manage access to agents, tools, or connected providers, which matters because a guardrail is itself a security control: the ability to edit one is the ability to loosen the company's content policy.

What a hard block actually costs you

On a match, the message is blocked, no redaction, no partial pass-through, just a clear stop naming the rule that fired. That's a heavier hammer than some teams expect on their first PII rule; blocking an entire response because it contained one phone number can feel like overkill next to just removing the phone number and sending the rest. It's the right default for a first pass, a block is unambiguous and auditable, a redaction changes content in a way that needs its own review. If your evaluation across testing an agent before production turns up rules that block more than they should, the fix is almost always narrowing the rule, not disabling the mechanism, a category rule that's too broad is a five-minute edit, a written-policy sentence that's too aggressive is a shorter sentence.

From a content governance policy to rules that run

Most companies already have a content governance policy, written for people: the style guide, the legal review checklist, the list of things marketing is never allowed to say. Editorial tools enforce it on documents before they publish. An agent answering customers live never goes through that review, so the same policy has to run inside the conversation instead. Here is how the usual clauses translate:

Policy clause	Example	Rule to build
Forbidden claims	"guaranteed returns", "clinically proven", "100% secure"	Keyword for the exact phrases, plus a written policy ("never promise a financial or health outcome") for the paraphrases a keyword list misses
Retired names and banned terms	An old product name, a competitor the agent shouldn't discuss	Category, one labeled list per topic so the audit log says which list fired
Confidential identifiers	Internal project codenames, contract number formats	Keyword for names, regex for anything with a fixed shape
Personal data	Customer phone numbers and emails in an output	PII, on the output direction
Required disclosures	"Prices exclude VAT" on every quote	Instruction in the agent's system prompt first, written policy on output as the backstop

The last row is the one teams get wrong. A guardrail blocks; it never adds text. If a disclosure is mandatory, the agent has to be told to include it, and the written-policy rule exists to stop the answer that forgot. Treat it the other way round and the agent spends the week getting blocked instead of being compliant.

Two habits from editorial governance carry over unchanged. Every rule gets an owner who can say why it exists, and the rule set gets reviewed on a schedule, because a forbidden-claims list written in January is incomplete by June. The match log tells you which rules fire and which never have; a rule that has never fired in six months is either working perfectly or checking for the wrong thing, and it is worth knowing which.

Where this fits in the bigger picture

Content guardrails are one layer. They sit next to tool scoping, approval gates and audit logs, next to the origin controls that matter when an agent operates inside a real browser session, and next to the weekly discipline of watching whether an agent still works. None of them substitutes for the others: a perfectly scoped agent can still say the wrong thing, and a perfectly policed conversation can still be run by an agent with too much reach. Together, they're what makes the statutory version of this conversation something you can walk into with evidence instead of a promise.

It's also, in practice, the fastest way to answer the question every rollout eventually gets asked: not "is the model good," but "what exactly can it say, and can you prove it." With a rule set an admin owns, scoped by org and agent, logged on every match, the honest answer is a screenshot of the Guardrails page. That's how every agent we run is configured before it touches a real conversation.