Introduction

A control is three independent choices: what to detect, where to look, and what to do about it. Change any one and you have a different control.

That independence is the thing worth internalising, because the list of controls hides it. A control named for its check reads as though the check is the control — but the same check watching a different point, or taking a different action, is a separate rule with a separate effect.

"Check, applied-on and action are three dials, not one setting. Most confusion about controls comes from reading them as one."

Where to find it

AI Governance > Controls

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

The three axes

A control picks one check, one or more points to apply it on, and one action.

1 · The check — what to detect

Checks come in two kinds, and the difference matters more than the names suggest.

1. Checks — Picked from one searchable list, shipped by UnifyApps and resolved when you open the editor, so the list reflects what your tenant currently has rather than a fixed set. Each carries its own configuration fields — a pattern check asks for a pattern, a topics check asks for topics.

2. Custom (LLM check) — "Describe a check in plain language; an LLM evaluates each input." The fallback for anything the prebuilt list does not cover, and the default a new control starts on.

The choice has a consequence people meet later rather than sooner: a prebuilt check can offer actions the custom check cannot. See the action axis below.

2 · Applied on — where to look

An agent's traffic passes five points UnifyApps can inspect, and a control can watch any combination of them.

The two tool points are the ones teams forget, and they are where the interesting failures live. An agent that never says a credential out loud may still pass one to a tool, and a tool that returns someone else's record hands the agent data it was never meant to see.

Controls guard "LLM calls, responses, and tool use" — all five points (User input, Agent output, Tool name, Tool input, Tool output), not just the conversation.

3 · The action — what happens on a hit

Flag is the default for a new control.

Why Mask is sometimes missing

Both act on a span of matched text, so they can only be offered by a check that reports where the match was, not merely that there was one. A check that answers yes-or-no can flag or block; it cannot mask, because it cannot say what to mask.

This is why Custom (LLM check) offers only Flag and Block. If the action cards you expected are not there, the check you selected is the reason — not a permissions problem.

Refer: Whether an action can execute at all depends on the asset's governance tier. On an Observe · Advisory connection, only Flag takes effect. See Connection Type & Control Mode.

The same check, three times over

A catalogue will often show one check appearing several times with different actions — a pattern check set to Mask, the same check set to Block, the same check again set to Flag.

These are three separate controls. Nothing is duplicated and nothing is wrong. It is the axes doing their job: one detection, three responses, applied to different assets through different policies.

Name controls for what they do, not for what they detect. A list of controls all named after their checks is unreadable the moment the same check appears twice.

What a control does not decide

1. Which assets it covers — A control does nothing on its own. It reaches assets through a policy. See Policies.

2. Whether its action can execute — That is the asset's connection tier.

3. How severe a hit is — Severity is stamped by the control's own grading. A control with no grading raises incidents with no severity. See Severity & How It Is Assigned.

Best Practices

1. Name for the action, not the check — Block credentials in tool input tells the next person what happens. Credentials check does not.

2. Start on Flag — Run a new control in flag mode long enough to see what it catches. Promoting to Block afterwards is a one-field change; un-blocking production traffic at 2am is not.

3. Cover the tool points deliberately — Decide about Tool input and Tool output rather than defaulting past them.

4. Prefer a prebuilt check where one fits — It is cheaper to run than an LLM check, and it is what makes Mask available.

5. Split rather than broaden — Two narrow controls with clear names beat one control watching everything with an action that suits none of it.