Introduction

Not every platform an agent runs on offers a place to intervene. Some expose telemetry and nothing more. That is a fact about the integration surface, and it decides what governing an agent on that platform can mean — which is a narrower thing than most people assume, and more useful than they expect.

Two tiers, one difference

Every connection is one of two tiers, and the difference is exactly one thing:

	Observe · Advisory	Control · Enforced
Telemetry	Yes	Yes
Controls evaluate	Yes	Yes
Incidents recorded	Yes	Yes
Can flag	Yes	Yes
Can block or mask	No	Yes

Or in the product's own words, shown under the action picker:

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

Why some connections are advisory

Enforcement requires a point in the request path where a verdict can stop something. That point has to be offered by the platform serving the agent — it is not something an observer can create from outside.

Platforms differ in what they expose, and for entirely reasonable reasons: some are managed services with a fixed request path, some expose telemetry through a standard interface and nothing further, and some predate the idea that an external system might want to intervene. Whether a connection can enforce is a property of that integration surface, not a judgement about the platform.

Note: Where a platform exposes an enforcement point, UnifyApps uses it. Where it does not, we say so rather than implying coverage we do not have. The tier is visible on the agent record precisely so that nobody has to guess. See Supported Providers Matrix for what each connection currently supports.

What advisory governance actually gives you

"Cannot block" reads as "cannot govern", and that is wrong. Most of the value of a governance programme is in the parts advisory tiers deliver in full:

You know the agent exists — An inventory is the first thing every framework asks for, and the thing most organisations cannot produce.
You know what it does — Traces, tools called, cost, error rates.
You know when it breaches — Controls evaluate identically. An incident on an advisory connection is the same durable, immutable record as one on an enforced connection.
You can prove all of the above — Which is what an auditor is asking for. Evidence of detection is evidence.

What you do not get is the last step: automatic prevention. The response has to be human and after the fact — which is exactly how most security operations worked for decades.

Designing around an advisory connection

Set controls to Flag deliberately — A blocking control on an advisory connection does not warn you and does not block. Setting it to Flag makes the configuration honest about what will happen.
Commit to reading the queue — A flag nobody reads is not a control. There are no notifications, so the review cadence is the mechanism — see Escalation & Notifications.
Push prevention into the agent itself — What the platform cannot enforce from outside, the agent's own instructions and tool permissions can often prevent from inside. An agent that is not given a destructive tool cannot call one.
Route the highest-consequence work to enforced connections — If an agent can move money or delete records, the tier is a real input to where it should run.
Report the tier alongside the coverage — "Twelve agents governed" means something different at each tier. Say which.

"Advisory governance is not governance theatre. It is detection without prevention — which is most of what a governance programme is, honestly labelled."

Checking a connection's tier

The tier shows on the agent's Overview as a badge — Observe · Advisory or Control · Enforced — and on the connection itself. It is set when the connection is created or the agent is registered, and only platforms whose integration supports enforcement can offer the enforced tier.

Most manual registrations are advisory. Registering an agent by hand records its identity and prepares it for telemetry. Only agents registered on Anthropic Agent SDK, OpenAI Agent SDK, LangChain or LangGraph can choose Control · Enforced — and then only if the agent routes its calls through UnifyApps.

If you need enforcement and do not have it

The options are, in rough order of effort:

Option	When it fits
Prevent it inside the agent	The risk is about tools or capabilities you control
Move the workload to an enforced connection	The agent is portable and the risk is high
Accept detection and document the acceptance	The risk is real but tolerable — and a recorded risk acceptance is itself governance
Ask whether enforcement is on the roadmap for that platform	Your account team can tell you; this page cannot

Policy Evaluation API

An agent on Control · Enforced asks UnifyApps for a verdict before it continues. The request is a POST with the agent's ID (agentId) as a path parameter.

Request field	What it holds
`content`	The text to evaluate
`inputType`	Which point the content comes from: `user_input`, `agent_output`, `tool_input` or `tool_output`
`toolName`, `tool_input`, `tool_output`	The tool call being checked, for tool-call checks
`caseId`, `traceId`	Identifiers that tie the evaluation to a session and a trace

Response field	What it means
`block`	`true` if any control blocked; the agent should stop
`content`	The content to continue with — masked if a `Mask` control matched
`toolInput` / `toolOutput`	The checked tool input or output, for tool-call checks

Note: An unknown agent does not return an error status. The API answers 200 with an error in the body, so check the body rather than the status code. Tool-call checks (tool_input, tool_output and the tool fields) are not available in every environment yet.

Governing Vendors Without a Control API