Unify Logo Footer.svg
AI Governance
Logo
Create a Control

Create a Control

Logo

5 mins READ

Introduction

Creating a control is four decisions and a test: what to detect, where to watch, how the verdict is reported, and what happens on a hit — then a dry run before anyone is affected by it.

The dry run is the part worth not skipping. It is the difference between finding out what a control does in a sandbox and finding out from an incident queue.

Where to find it

AI Governance > Controls > New Control

Access to AI Governance is granted through platform roles. Ask your workspace administrator, or see Settings > Governance > Roles for how permissions are assigned.

Before you begin

  1. Know what a violation looks like — Write down one example that should trip the control and one that should not. You will use both in the test step.

  2. Check for an existing control — Controls are reusable across policies. If one already detects this, applying it to another policy beats creating a near-duplicate.

  3. Decide the action honestly — Start on Flag. Promoting later is a one-field change.

Create the control

Step 1: Open the editor

From Controls, click New Control. The control opens as Untitled control; name it for what it does rather than what it detects.

Step 2: Choose the check

Pick the check from one searchable list. Custom (LLM check) — "Describe a check in plain language; an LLM evaluates each input." — is one of the entries: the default for a new control, and the fallback where nothing else fits. There are no saved custom checks.

Prefer a purpose-built check where one exists: several cost no model call, and only checks that report match positions offer Mask.

Step 3: Choose where it applies

Select one or more inputs — User input, Agent output, Tool input, Tool output, Tool name. Until you do, the check's configuration stays locked behind "Select at least one input above to configure this check."

The two tool points are the ones teams skip. Decide about them rather than defaulting past them.

Step 4: Configure the check

What appears here depends on the check. Three common shapes:

  1. Denied topics — Each topic takes a Name, a Description of what it covers, and Example phrases. The examples do real work — they are how the check learns the boundary of the topic.

  2. Detectors — Content categories — Hate, Violence, Sexual content, Self-harm, Harassment, Criminal misconduct, Profanity — tick each category to check and set its threshold to High, Medium or Low, and choose a Classifier model. Higher settings mean higher likelihood and fewer false positives.

  3. Blocked tools — "Block a tool when it matches the condition set for these rules." Build rules with Contains / Doesn't contain conditions, combined with Match any or Match all.

Step 5: Set the output

For a custom check, choose how the model reports its verdict.

Output

You configure

Use when

Binary (Yes / No)

"Breach when the answer is" — Yes or No

The question has a clean answer

Scale (0-100)

A breach threshold — the control trips at or above it

The question is a matter of degree

A scale gives you a dial to turn when the control is too noisy, which a binary check does not. Where the judgement is genuinely graded, use the scale.

Step 6: Grade the severity

Turn on Check severity (off by default), then choose one of two modes. The choice changes how the incidents read.

  1. Fixed level — "Every finding is tagged with this level." Critical, High, Medium or Low; the default is Critical. Predictable.

  2. Graded by the model — Each finding is scored on its own against the risk area the control governs. Returns Critical, High, Medium or Low.

Leaving Check severity off is what produces the blank SEVERITY column. See Severity & How It Is Assigned.

Step 7: Choose the action

Flag, Block, and — where the check reports match positions — Mask. Flag is the default and the right starting point.

Step 8: Test it

Use Test this control — "try sample inputs to see what it would do". Enter sample content and click Run test.

You get No issues detected ("nothing in your sample matched this control") or Issues detected, naming which inputs matched. Run both examples you wrote down: the one that should trip it, and the one that should not.

A control that passes only the first test is half tested. False positives are the failure mode that fills incident queues.

Step 9: Save and apply

Click Save. The control is created but governs nothing until a policy carries it — add it to one from the policy's Controls tab. See Apply a Policy to Assets.

Result

The control is saved to the catalogue. It starts running once you add it to a policy; each policy has its own on/off switch for it. Once a policy carries it and that policy covers assets, it begins evaluating their traffic and raising incidents on a match.

Important considerations

  1. Editing changes every policy that carries it — Check which policies use a control before tightening it.

  2. The action may not execute — That depends on the covered assets' connection tier, not on the control.

  3. Testing is not coverage — A passing test proves the control works on your samples. Real traffic is more varied — which is what the Flag period is for.

  4. An ungraded control is hard to triage — Grade severity at creation rather than after the queue is full.

FAQs

Why can I not configure the check?

Select at least one input first — the configuration depends on what the check will read.

Why is Mask missing?

The selected check does not report where the match occurred, so there is nothing to mask.

Can I test a control after it is live?

Yes. Test this control stays available on a saved control and does not affect its behaviour.

What if the test automation is not configured?

The editor says so. The control can still be saved — you lose the dry run, not the control.