Can a control both mask and flag?

One action per control — but every action raises an incident, so a masked hit is recorded as well as altered. You do not need a second control to get the record.

Why is Mask greyed out?

The selected check does not report match positions.

Introduction

Q: What does the user see when something is blocked?

The request does not complete and returns: "This query cannot be answered due to content guidelines. Can you please rephrase your request and try again?" A variant is used for tool calls. On UnifyApps agents the message appears in the chat. It does not say which control fired, which is worth designing around before you promote a control to Block.

The action is the only part of a control that changes what your users experience. The check decides whether something matched; the action decides whether anyone notices.

Three are available, and one of them is conditional.

Where to find it

AI Governance > Controls — the ACTION column, set when you create or edit a control.

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 actions

Action	What it does	User sees	Always available
`Flag`	Allow it through but log an incident for review.	Nothing	Yes
`Block`	Stop the request or response from proceeding.	A fixed content-guidelines message	Yes
`Mask`	Replace the matched span with a mask token.	Content with the span replaced	No

Flag

The observation action. Traffic passes untouched and an incident is recorded.

Flag is the default for a new control, and it is the only action that works on every asset regardless of governance tier — because recording something after the fact does not require sitting in the request path.

It is also the honest starting point for any control you have not yet tuned. A control in flag mode tells you exactly what it would have blocked, without anyone finding out the hard way.

Block

The hard stop. The request or response does not proceed.

Blocking is the action most likely to generate a support ticket, because a blocked interaction is a failed interaction from the user's point of view. Two consequences worth planning for: the user gets a fixed message rather than an explanation — "This query cannot be answered due to content guidelines. Can you please rephrase your request and try again?" (a variant is used for tool calls; on UnifyApps agents it appears in the chat) — and a false positive on a Block control is an outage for whoever hit it.

Tune in Flag first. Promote to Block when the incident stream has convinced you the control is right.

Mask

The surgical action. Rather than allowing or refusing the whole payload, it alters the part that matched and lets the rest through.

Mask replaces the matched span with a mask token. The shape of the content survives, and it is visible that something was removed.

Why it is sometimes not offered

Mask acts on a span, so it can only be offered by a check that reports where the match occurred — not merely that there was one. A check answering yes-or-no can flag or block; it cannot mask, because it cannot say what to mask.

So the action cards you see depend on the check you selected. Custom (LLM check) offers Flag and Block only. If Mask is absent, the check is why.

What the governance tier decides

Choosing an action and having it execute are two different things.

Action	Observe · Advisory	Control · Enforced
`Flag`	Takes effect	Takes effect
`Block`	Recorded only	Takes effect
`Mask`	Recorded only	Takes effect

Two of the three need UnifyApps to be in the request path, and that is a property of the asset's connection, not of the control. A Block control on an advisory asset detects and records exactly as it should — and does not block.

Refer: Check what governs a given asset before you promise anyone an action will fire. See Connection Type & Control Mode.

How the action appears in Incidents

Every incident carries the action that was taken, so the incident list tells you not only what was detected but what happened about it. MASK only ever appears on incidents raised by checks that report match positions.

Best Practices

Every control starts on Flag — Without exception, and for as long as it takes for the incident stream to look sane.
Match the action to the harm — A leaked identifier is a masking problem. A prohibited topic is a blocking problem. Using Block for everything makes the agent unusable; using Flag for everything makes governance advisory by accident.
Say the action in the control's name — Reviewers read the list, not the config.
Do not promise enforcement you cannot execute — Confirm the tier before telling a stakeholder something is blocked.

Actions