Governance

The Governance page in Ultra Hub lets administrators block specific MCP servers, tools, and clients across an organization, a workspace, or a single gateway. When a governance rule matches a tool call, the call is denied at the gateway before it ever reaches the upstream server, and the denial is recorded in the audit log. Use governance when you need a fast, blunt control: removing access to a deprecated server, cutting off a server or client 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: servers and clients.

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

A rule can target servers, clients, or both. Multiple values within the same target type are treated as “any of these.” When both server and client 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 server. 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.).

​

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 by default and can be overridden per workspace. Workspaces with no override inherit the org posture. Gateways inherit from their workspace. 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.

​

Scoping

Governance rules can be configured at three levels, exactly like guardrails: Workspace and gateway rules add to the rules inherited from higher scopes, they do not replace them. Use the workspace and gateway 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 Servers page

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

​

Full rule editor from the Governance page

Use the full editor when you need to target clients, filter to specific tools, or scope the rule to a workspace or gateway 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. Tool calls that the rule was blocking are allowed again after the change syncs to your gateways. 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 server, tool, and client 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 automatically: every posture-generated allow rule in the scope is deleted in the same action, restoring the previous “rules as a blocklist” model. Rules you created by hand (not posture-generated) are left in place.

​

Audit log behavior

Every governance decision generates an event_type: guardrail event in the audit log with guardrail_type: governance. 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 server that was targeted
• The tool the client tried to call
• The user and client identity behind the call

Use these events to confirm a decision is taking effect and to track who or what attempted to use a server, tool, or client 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-server 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 server, with timestamps, the client 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 alerting without disrupting traffic, use custom guardrails instead.

​

Related