Introduction
Connection Types defines the two tiers. This page answers the operational question that follows: for this agent, what will actually happen when a control fires?
It is the question to settle before you tell anyone a control is protecting something.
Where to find it
AI Governance > Agent Registry > select an agent > Overview > Agent Details > Connection type
Where an agent's tier comes from
An agent never chooses its own tier. It inherits one, by one of two routes.
Discovered agents inherit the connection's tier — Every asset a connection returns carries that connection's
CONNECTION TYPE. One connection, one tier, applied uniformly.Manually registered agents take the tier set on the registration form — Selected in
Step 2 of 2 · Agent details.
The consequence is that the connection is the unit of governance design. If two groups of agents need different treatment, they need different connections — you cannot promote one agent.
What each tier permits
Capability | Observe · Advisory | Control · Enforced |
Trace collection | Yes | Yes |
Policy evaluation | Yes | Yes |
Incident creation | Yes | Yes |
Evaluation and scoring | Yes | Yes |
| Yes | Yes |
| No | Yes, where the check supports it |
| No | Yes |
Approval before a call completes | No | Yes |
Added latency | None — out of band | Inline gateway |
Detection is identical. The difference is entirely in what may be done about a detection, and when.
Availability today
Observe · Advisory is generally available and is what every connection created through the product carries.
Control · Enforced is available where the platform supports routing calls through the UnifyApps gateway. Today that is UnifyApps and n8n when you add a Discovery connection, and Anthropic Agent SDK, OpenAI Agent SDK, LangChain and LangGraph when you register an agent manually. On every other platform the Control card is disabled with the tooltip "This platform can't route calls through the gateway yet, so it can only be observed.". The tier is chosen per connection (Discovery) or per registration (Register Agent), and every agent on that connection inherits it.
Some existing agent records nevertheless display Control · Enforced. If you are looking at one, do not assume enforcement is live for it: confirm with your UnifyApps contact what governs that agent before relying on a control to stop anything.
"The dangerous state is not knowing you are advisory. It is believing you are enforced."
How to check a specific agent
Step 1: Open the agent
From the Agent Registry, click the agent's name.
Step 2: Read Connection type on the Overview tab
The Agent Details panel on the right shows Connection type as a badge, alongside Status, Owner, Workspace and Department. An advisory tier is styled as a caution — deliberately, because it is a limitation you should notice.
Step 3: Read the agent's controls in that light
On an advisory agent, a control set to Block or Mask records violations and does not act on them. That is not a misconfiguration — it is the tier — but it is worth knowing before you report on it.
Designing around advisory
Put hard stops where they can execute — The hosting platform's own guardrails are in the path and can enforce. Use them for prevention.
Use UnifyApps for what only it can do — One inventory across every platform, one policy model, one incident trail, and exportable evidence mapped to the framework you are being audited against. No platform-native control gives you that across vendors.
Write the tier into your control documentation — The gap between what a control is named and what it does is where audit findings come from.
Separate connections by risk — Since the tier follows the connection, connection boundaries are governance boundaries. Design them that way now and the model still works as enforcement becomes selectable on more platforms.