Introduction

A control is not attached to an agent. It is attached to a point — one of five places in a request where content can be read and judged. Choosing the point is most of the design work, because the same check at two different points catches genuinely different things.

The five apply points

The control editor calls this section Inputs — "The surfaces this check reads. Pick at least one."

Apply point	Reads	Catches	Blocking here stops
`User input`	What the person sent	Attacks and disallowed requests, before the model sees them	The request
`Tool input`	Arguments the agent passes to a tool	Data leaving, and actions being taken	The action
`Tool name`	The name of the tool the agent is about to call	Calls to tools the agent must never use	The call
`Tool output`	What a tool returned	Poisoned or unvalidated data entering the agent	The agent acting on it
`Agent output`	What the agent is about to say	Disclosure, fabrication, unsafe content	The reply

The five are a sequence, and the order is the point

A single turn passes through them in order: the user's message arrives, the agent may call tools and read what comes back, and eventually it replies. Each point sits earlier or later in that sequence, and earlier is cheaper.

Catching it at User input costs nothing but the check — Nothing has been spent and nothing has happened. This is the ideal place for anything you can detect from the request alone.
Catching it at Tool name or Tool input prevents the irreversible thing — A tool call is the agent affecting the world. This is the last point at which a payment, a deletion or a disclosure can still be stopped.
Catching it at Tool output stops bad data spreading — The retrieval already happened, but the agent has not acted on it yet.
Catching it at Agent output is the last line — The work has been done and paid for. You are preventing the user from seeing something, which is worth doing and is the most expensive place to do it.

Note: Tool input is the apply point most teams under-use, and it is the one that matters most. Four of the eight controls in the shipped ISO 42001 pack run on the tool call — two on Tool input and two on Tool name. What an agent says can be embarrassing; what an agent does can be irreversible.

The same check at two points is two different controls

This is the idea worth taking away from the page. Consider PII detection:

At	It means	You would probably
`User input`	The user typed their own personal data at your agent	Flag, or mask — they chose to
`Tool input`	Personal data is being sent to an external system	Block — this is exfiltration
`Agent output`	The agent is about to disclose personal data	Block or mask, depending on who is reading

One check, three risks, three appropriate actions. A control that selects all three inputs and one action treats them as the same thing — which is why the editor lets you pick multiple inputs and why you usually should not.

"Selecting every input looks thorough. It usually means you have not decided which risk you are managing."

Whether the control can act depends on the connection

Detection happens wherever the check is pointed. Whether the verdict can do anything is a property of the connection, and the product states the rule under the action picker, verbatim:

"Outcomes other than Flag only run on agents connected in Control mode. On Observe-only agents the control can flag, but cannot intervene."

So the apply point decides what is seen and the connection type decides what can be done about it. Configuring a blocking control on an advisory connection is not an error and will not warn you — it simply will not block. See Connection Type & Control Mode.

Two things this page cannot tell you

Both are common design questions, both are backend behaviour, and neither is documented from the sources this KB is written against. Rather than guess:

Question	Status
How much latency does a control add to a request?	Not documented here. It will vary by check — a regex is not an LLM call — but no published budget exists
If a check fails or times out, does the request proceed or stop?	Not documented here. Fail-open and fail-closed have opposite risk profiles and we will not assert one

If your design depends on either — a latency-sensitive path, or a control you are treating as a hard security boundary — get the answer from your UnifyApps account team before you build on an assumption. Both questions have been raised; this page will be updated when they are answered.

Choosing a point, in practice

Ask what the harm actually is — Money moving, data leaving, a person being misled, an attack succeeding. The harm has a location in the sequence, and that location is your apply point.
Choose the earliest point where the harm is visible — Not the earliest point at all — a check cannot see what has not happened yet.
Use one input per control unless the risk is genuinely identical — Two controls with clear names beat one control with five inputs and an ambiguous action.
Test it before enabling — The editor will run your check against sample content at each selected input. See Test a Control Before Enabling.

Where Controls Run