Introduction

Controls are the rules that decide what your agents may say, accept and do. Everything else in AI Compliance exists to carry them: policies deliver controls to assets, and incidents are what controls produce when something matches.

A control on its own governs nothing. It is a rule waiting for a policy to apply it.

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.

What a control is

Three independent choices: a check that decides what counts as a violation, one or more points in the agent's path to apply it on, and an action that says what happens on a hit.

Read the list with that in mind and it stops looking repetitive. The same check watching a different point, or taking a different action, is a different rule with a different effect.

Refer: The three axes and how they interact are covered in Anatomy of a Control. Read it before creating anything.

The Controls table

One row per control, with the count beside the page title.

The Controls list has no on/off switch. A control is switched on or off inside each policy: open the policy's Controls tab and use the switch on that row. Switching it off there affects that policy only — which makes it the right first move when a control is misfiring in one place and you are not yet sure why.

Controls, policies and incidents

1. A control defines a rule — Detect this, here, and do that.

2. A policy applies it to assets — Controls reach agents and models only through policies. A control in no policy evaluates nothing. See Policies.

3. An incident records a hit — Every match raises an incident carrying the asset, the policy, the control, the action taken and the severity the control graded it with. See Incidents.

The chain runs one way — control, policy, asset, incident — and every debugging question in this section is answered by walking it.

"A control nobody applied is a policy document. A control in a policy is a control."

Controls are reusable by design

One control can sit in many policies. That is deliberate, and it has a consequence worth stating: edit a control and you change its behaviour everywhere it is used.

Before changing a live control, check which policies carry it. A tightening that makes sense for one policy's assets can be badly wrong for another's.

Best Practices

1. Name for the action, not the check — Block credentials in tool input is readable in a list of eighty. Credentials check is not.

2. Test before you save — The editor can run sample inputs and show you what the control would do. Use it — it is faster than reading incidents to find out.

3. Start on Flag — Every control, without exception, until the incident stream looks sane.

4. Grade severity when you promote — An ungraded control raises incidents nobody can prioritise.

5. Switch off rather than delete while investigating — Deleting loses the configuration and its policy attachments. Switching a control off in a policy is reversible.

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