Unify Logo Footer.svg
AI Governance
Logo
Connection Types

Connection Types

Logo

4 mins READ

Introduction

A connection's type is its governance tier: how much UnifyApps is allowed to do about what it sees. It is set when you add the application, it applies to every asset that connection returns, and it is the single fact that determines whether a control can stop something or only record it.

This is the most consequential setting in AI Governance, and the one most often assumed rather than checked.

Where to find it

AI Governance > Discovery — the CONNECTION TYPE column. It is set in the + Add Application panel, and shown again on each agent's Overview tab under Agent Details.

Access to AI Governance is granted through platform roles. Ask your workspace administrator, or see Settings > Governance > Roles for how permissions are assigned.

The two tiers

The product states each tier in one line. Those lines are precise, and worth reading literally.

  1. Observe · Advisory — "Monitors, evaluates, flags, but cannot block calls in real time." UnifyApps sits beside the agent, not in front of it. It receives what the agent did, scores it, compares it against your policies and raises incidents. Everything it reports is a fact about something that has already happened.

  2. Control · Enforced — Can block and mask a call before it completes. UnifyApps sits in the path. A control can intervene while the call is still in flight, which is what makes Block and Mask meaningful rather than advisory.

"Out-of-band tells you what happened. Inline decides what happens."

What changes between them

The distinction is not about how much UnifyApps can see. Both tiers see the same telemetry. It is about what a control is permitted to do when a check fires.

  1. Detection — Identical in both tiers. The same checks run against the same traffic.

  2. Incidents — Identical in both tiers. A violation is recorded either way.

  3. Flag — Works in both tiers. Flagging is a record, and a record can be made after the fact.

  4. Block and Mask — Require the inline path. Stopping a call or replacing a matched span with a mask token both have to happen before the call completes, which an out-of-band observer cannot do.

So the practical reading of Observe · Advisory is: you will know, you will have evidence, and you will not have prevented it.

Availability today

Observe · Advisory is generally available and is the tier applied to connections created through + Add Application.

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.".

Refer: Per-platform availability is listed in the Supported Providers Matrix. For what a tier means once an agent is registered, see Connection Type & Control Mode.

Designing controls for advisory

Advisory is not a lesser version of enforcement waiting to be upgraded. It is a different operating model, and controls written for it look different.

  1. Write checks for evidence, not interception — A check whose value depends on stopping the call will disappoint. A check whose value is a defensible record of every occurrence will not.

  2. Put the enforcement where it can happen — The platform hosting the agent usually has its own guardrails. Use them for hard stops, and use UnifyApps for the cross-platform record, the policy mapping and the incident trail.

  3. Tune for signal early — Advisory controls produce incidents, and incidents accumulate fast. A policy nobody triages is indistinguishable from no policy. See Tuning Policy Noise.

  4. Say which it is, out loud, in your control design — The most common governance failure here is a stakeholder who believes a control is blocking something it is only recording. Name the tier in your own runbooks.

Important considerations

  1. The tier is a property of the connection, not the agent — Every asset a connection returns inherits it. To govern two groups of agents differently, put them behind different connections.

  2. It is not editable in place — There is no edit action on a Discovery row. Changing the tier means deleting the connection and adding it again.

  3. An agent's detail panel is the authoritative display — When you need to know what governs a specific agent, read Connection type on its Overview tab rather than inferring it from the platform.

FAQs

If I cannot block, what am I actually getting?

A complete, cross-platform record of what every agent did, scored against your policies, with incidents you can investigate down to the individual trace and export as evidence. For most regulated programmes the record is the requirement; enforcement is the second phase.

Does Observe · Advisory add latency to my agents?

No. Out-of-band means UnifyApps is not in the request path.

An agent's detail page shows Control · Enforced. How?

Enforced records can exist that the current picker cannot create. If you see one and need to know what governs it, confirm with your UnifyApps contact rather than assuming enforcement is active.

Can I mix tiers across one platform?

Yes, by using separate connections. The tier follows the connection.