AI Guardrails

AI Guardrails are Security Gateway rules you describe in a sentence instead of a pattern. Standard Entity Rules and Custom Regex Rules match on shape, so they catch things that look a certain way. A guardrail states what you want caught, “any information about Project Alpha, including code names, timelines, or team members”, and an evaluator decides whether a given tool call violates it. Reach for a guardrail when the thing you want stopped is a topic or a judgment call rather than a string.

Guardrails are available to every organization, and nothing is screened until you write one. Adding your first guardrail is what turns the layer on.

How evaluation works

Before a tool call runs, Agent Handler sends the request to an evaluator together with every guardrail that applies to that call. The evaluator reads the content, compares it against each instruction independently, and answers yes or no per guardrail. On yes, that guardrail’s action fires. When the evaluator is unsure, it answers no and the call continues.

Guardrails screen in both directions, which makes them the one rule type that can inspect a result rather than an argument:

Two properties are worth knowing before you write your first one. Content reaches the evaluator as data inside per-request boundary markers, so an instruction planted in a tool argument is judged rather than obeyed. And when evaluation itself fails, because the evaluator is unreachable or returns no verdict for a guardrail, the call continues and that guardrail is marked as an evaluation failure rather than a pass, so the gap does not read as a clean run.

Configurable per guardrail

Configuration lives at Security → AI Guardrails. Each guardrail can start from a template, which prefills the fields and leaves every one of them editable.

One scoping consequence to plan for: a call that runs without a Tool Pack, which is how the employee MCP endpoint in Agent Handler for Employees resolves tools, matches only the guardrails that are not limited to Tool Packs. If a guardrail has to cover your employees, leave its Tool Pack limit off.

The two actions

There is no redact action. Redaction needs a matched span to replace, and a guardrail verdict is a judgment about the call as a whole, so Block and Log are the only two choices.

Writing an instruction the evaluator can act on

One subject per guardrail. The evaluator judges each instruction independently, and a guardrail that covers three unrelated topics gives you one verdict where you wanted three, in the table and in every violation you investigate.

Name the thing and the forms it takes. “Project Alpha” alone leaves the evaluator guessing about code names and internal shorthand; naming those forms in the instruction is what makes the verdict predictable.

Pick the direction deliberately. A topic you don’t want leaving your organization is a pre-run guardrail. A category you don’t want an agent pulling back in, credentials in a tool result for instance, is a post-run guardrail. Screening both costs two evaluations per call.

Three worked examples

A confidential project

An unannounced project that must not reach any third-party system, in either direction.

Name:         Block Project Alpha
Instruction:  Any information about Project Alpha, including code names,
              timelines, or team members
Action:       Block
Screens:      Requests and responses
Applies to:   All tool packs

Screening both directions matters here: the agent should neither write the project into a ticket nor read it back out of one and carry it into the next call.

Competitor mentions on outbound calls

You want the agent to stay off the subject of competitors in anything it sends to a customer-facing system, without stopping it from reading what is already there.

Name:         No competitor mentions
Instruction:  Mentions of competitors or their products in outgoing messages
Action:       Block
Screens:      Requests
Applies to:   The Tool Packs backing customer-facing surfaces

Requests only, so the agent can still summarize an inbound email that mentions a competitor. Scoping to specific Tool Packs keeps an internal research agent unaffected.

Credentials coming back from a tool

A repository or a ticketing system can hand an agent a secret that somebody pasted into a comment years ago. You want to know when it happens before you decide to block it.

Name:         Leaked credentials
Instruction:  API keys, passwords, tokens, or other secrets appearing in
              tool responses
Action:       Log
Screens:      Responses
Applies to:   All tool packs

Log first. Run it for a week, read what it caught, then switch the action to Block once you trust the instruction.

Picking an evaluation model

Pre-run and post-run each get their own model class, set on the AI Guardrails tab:

Pre-run evaluation sits in front of every call the guardrail applies to, so its class is the one that shows up as latency your users feel. Post-run runs after the third party has already answered, so a slower class there costs less. A common split is Fast on pre-run and Balanced on post-run.

Testing before going live

The Rule Tester runs a sample input through the whole Gateway and streams the result back in order: entity detections first, then each pre-run verdict, then whether the call was blocked, then the post-run verdicts. Use it to confirm an instruction catches what you meant and leaves benign content alone, which is where most instructions need a second draft.

Where guardrails fit

A guardrail evaluates content, so it does not decide who may call which tool. That is what Tool Packs and tool access are for. Guardrails also run alongside the pattern rule types rather than replacing them: an entity rule is the cheaper and more precise way to stop a credit card number, and a guardrail is the only way to stop a topic.

Next

Investigate what your rules and guardrails are catching in Violations and alerts.