Governance

The Governance page in Ultra Hub lets administrators block specific MCP connectors, tools, and agents across an organization, a workspace, or a single device. When a governance rule matches a tool call, the call is denied at the device before it ever reaches the upstream connector, and the denial is recorded in the audit log. Use governance when you need a fast, blunt control: removing access to a deprecated connector, cutting off a connector or agent during incident response, or sandboxing a newly registered integration while it is reviewed.

​

How governance rules work

A governance rule is an explicit allow or block decision keyed on two target types: connectors and agents.

• Connectors: Tool calls to a specific upstream MCP connector. Add an optional tool filter to scope the decision to specific tools instead of every tool on that connector.
• Agents: Tool calls originating from a named MCP agent (for example, claude-desktop, cursor, claude-code). You can also target an agent type (a whole category of agents) when you want the decision to apply to every instance of that agent.

A rule can target connectors, agents, or both. Multiple values within the same target type are treated as “any of these.” When both connector and agent targets are set, both must match for the rule to apply. When a governance rule matches, Ultra applies the rule’s decision immediately, before the call reaches the upstream connector. Block rules deny the tool call and emit a deny event into the audit log. Allow rules let the call through governance and hand it to the rest of the pipeline (guardrails, anomaly detection, etc.).

​

Connector identity

Where Ultra can determine one, a connector’s rule target is its durable identity. What serves as that identity depends on the connector:

• A remote connector’s identity is the canonical form of the URL Ultra dials.
• A stdio connector’s identity is the source coordinate declared in its config, so a rule follows the connector even when devices label it differently.
• A stdio connector with no source has no identity a rule can match on, and is targeted by its local name.

If the same connector is configured under different names on different devices, Hub treats it as one connector for governance and shows it as a single entry. A no-source stdio connector is the exception: the Governance page lists it once per configured name, each targeted by that name.

​

Governance Posture

Posture is the baseline admission decision for tool calls that no rule matches. It is set per scope and answers a single question: “If governance has no opinion, what should happen?” Posture is set at the organization level as a baseline, and a workspace can tighten it. A narrower scope can add restrictions but never remove them: the effective posture is the stricter of the organization and workspace settings, so a workspace can move from default_allow to default_deny, but it cannot sit at default_allow beneath an organization on default_deny. Workspaces with no setting of their own inherit the org posture, and devices inherit from their workspace. A workspace value that is not currently the effective one is still stored. If the organization later relaxes its posture, that workspace value takes over. The Posture section appears at the top of the Governance page with a status badge showing the effective posture for the current scope (and a note when the value is inherited from a higher scope). Owners and admins can flip the setting from the same panel, and the control is unavailable in both directions for a workspace whose organization mandates a stricter posture. That control is a dashboard affordance: what actually holds the mandate is posture resolution, not a rejection at the API.

​

Drift enforcement

Governance is also where you set drift enforcement for your organization: whether Ultra keeps itself installed in the MCP agents it finds on your members’ devices, and how far it goes when it finds one it does not manage. A Policy configuration panel at the top of the Governance page shows the current posture and the current drift-enforcement mode. Everyone can see it; owners and admins get a Manage button.

​

Setting it

Manage opens the drift-enforcement dialog. Choose the scope first (Organization or Workspace), then the mode. The dialog offers the same five modes the CLI does (Off, Detect only, Default, Auto install, and Enforce all), each described under drift enforcement in the CLI reference. The dialog shows a one-line explainer as you select one. Two further options are not modes but ways of not setting one:

• Device setting (organization scope) leaves drift enforcement to each device’s own local configuration.
• Use organization setting (workspace scope) clears a workspace’s value so it follows the organization again.

Drift enforcement is set at the organization or workspace level only; there is no per-device setting in Hub. A workspace value takes precedence over the organization’s.

​

How it reaches devices

A mode you set here overrides whatever a device has configured locally with ultra config set drift-enforcement, including when the mode you set is Default. Devices pick it up on their next contact with Hub, but apply it when Ultra next starts. A device that is running keeps the mode it started with, so expect a lag between saving here and seeing the behavior change on a fleet. A device that is not linked to Hub follows its own local setting. Linking a device to a workspace clears any mode stored from a previous one. Changes are recorded in the Admin Log.

​

Scoping

Governance rules can be configured at three levels, exactly like guardrails: Workspace and device rules add to the rules inherited from higher scopes, they do not replace them. Use the workspace and device filters at the top of the page to view rules in effect for a specific scope. Inherited rules appear faded in the table, with an indicator showing where they came from.

​

Who can manage governance

Only users with the owner or admin role can create, edit, move, or delete governance rules. Members and viewers can see the Governance page and the list of active rules, but the Create rule, Edit, and Delete controls are hidden. See RBAC for the full permission matrix.

​

Creating a rule

There are two ways to create a governance rule.

​

Quick block from the connector controls

The fastest way to block an entire MCP connector organization-wide. The rule appears immediately on the Governance page and is synced to all connected devices within seconds.

​

Full rule editor from the Governance page

Use the full editor when you need to target agents, filter to specific tools, or scope the rule to a workspace or device instead of the whole organization.

​

Editing or moving a rule

Click Edit on any rule you own at the current scope to change its name or its targets. Inherited rules are read-only at lower scopes; navigate to the scope they came from to edit them. To move a rule to a different scope, open it and click Change scope…. Picking a new scope creates the rule at the new scope and deletes the original. Both events are recorded in the audit log.

​

Removing a rule

Click Delete on the rule’s row, then proceed through the confirmation dialog. Tool calls that the rule was blocking are allowed again after the change syncs to your devices, falling back to the active posture and any other explicit rules. Existing audit log entries for past denials are preserved.

​

Transitioning to default_deny

Switching a scope from default_allow to default_deny is a meaningful change: every connector, tool, and agent without an explicit allow rule will immediately stop working in that scope. Ultra Hub helps you make the transition without breaking live traffic. Flipping back to default_allow cleans up after itself: the dashboard removes the posture-generated allow rules it created at that exact scope, restoring the previous “rules as a blocklist” model. Rules you created by hand are left in place, and so is an inherited organization-scope posture-generated allow, which a workspace flip does not touch. If any of the cleanup does not go through, Hub tells you. A workspace cannot flip back to default_allow while its organization is on default_deny. The control is unavailable in that case, because the flip would delete the workspace’s generated allow rules without changing what actually enforces.

​

Audit log behavior

Every governance decision generates a governance event in the audit log, shown under the Governance Rule filter in the dashboard. Each event records:

• The decision (outcome: deny for blocks, outcome: allow for allow rules)
• The reason (explicit rule, default deny posture, or the rule’s name)
• The MCP connector that was targeted
• The tool the agent tried to call
• The user and agent identity behind the call

Governance decisions recorded before the dedicated event type shipped remain guardrail events and stay under the Guardrail filter; new decisions use governance. Use these events to confirm a decision is taking effect and to track who or what attempted to use a connector, tool, or agent after it was disabled. Posture changes themselves also emit a governance event so the audit trail captures every flip between default_allow and default_deny.

​

Access view

The Access panel on the Governance page is a per-connector view of how governance is treating live traffic in the selected scope. Each row carries: Click a row to open the Audit samples drawer, which shows the most recent denied and allowed calls against that connector, with timestamps, the agent that initiated each call, and the IdentityLink for the user behind it. This is the fastest way to confirm a posture or rule change is having the effect you expected before you tighten further.

​

Common scenarios

​

Governance vs. guardrails

Governance and guardrails answer different questions: If you need finer control, for example matching on parameter values, redacting matched content instead of blocking, or raising an alert without disrupting traffic (a guardrail in Monitor mode, switched on under Alerts > Configuration), use custom guardrails instead.

​

Related