Governance

Block specific MCP servers, tools, and clients with organization-wide allow and deny rules

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 always-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 block only 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).

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

When a governance rule matches, Ultra denies the tool call before it reaches the upstream server.

Scoping

Governance rules can be configured at three levels, exactly like guardrails:

Scope	Description
Organization	Applies to every workspace and gateway in your org. The default starting point for blanket policies.
Workspace	Applies to every gateway in a workspace. Inherits all organization-scoped rules and adds to them.
Gateway	Applies to a single gateway. Inherits all organization and workspace rules and adds to them.

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.

1. Open the Servers page

   Navigate to Servers in the Ultra Hub sidebar.

2. Click Block on the server you want to deny

   Admins see a Block action on each server row.

3. Confirm the block

   The dialog creates an organization-wide governance rule that denies every tool call to that server, for every user in your organization.

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.

1. Open the Governance page

   Navigate to Governance in the Ultra Hub sidebar and click + Create rule.

2. Pick a scope

   Choose Organization, Workspace, or Gateway. The form previews exactly which clients the rule will apply to once active.

3. Name the rule

   Use a short, descriptive name (for example, Block github-mcp or Sandbox new finance-mcp). The name appears on the Governance page and in audit log events.

4. Add target servers

   In the Servers section, pick one or more servers from the dropdown. The list is populated from upstream servers Ultra has seen across your organization.

   Click the tool summary on a server row to optionally restrict the block to specific tools. Leave it as all tools to block the entire server.

5. Add target clients

   In the Clients section, pick one or more clients to limit the rule to specific MCP clients. Leave both lists populated to require a match on both server and client. Leave the Servers section empty to block every call from a listed client regardless of which server it targets.

6. Save the rule

   Click Create rule. The rule appears in the Governance table and syncs to every gateway in scope.

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.

Audit log behavior

Every blocked tool call generates an event_type: guardrail event in the audit log with outcome: deny and guardrail_type: governance. Each event records:

• The MCP server that was targeted
• The tool the client tried to call
• The user and client identity behind the call
• The governance rule that matched

Use these events to confirm a block is taking effect and to track who or what attempted to use a server, tool, or client after it was disabled.

Common scenarios

Scenario	Recommended action
Decommissioning an internal MCP server	Quick-block the server from the Servers page, then remove it from your gateway configs once traffic has stopped.
Vendor outage or compromise	Quick-block the affected server, unblock once the issue is resolved.
Blocking a server only inside one workspace	Create a workspace-scoped rule targeting that server. The block applies inside the workspace and adds to any org-wide rules already in effect.
Blocking a single dangerous tool but keeping the server	Create a rule with the server selected and a tool filter listing only the tools to block.
Sandboxing a new client until reviewed	Create a client-scoped rule blocking that client across the org while the integration is evaluated.
Fine-grained matching on parameters or content	Use a custom guardrail instead. Governance only matches on server, tool, and client identity.

Governance vs. guardrails

Governance and guardrails answer different questions:

	Governance	Guardrails
Question it answers	Should this server, tool, or client be reachable at all?	Is this specific tool call safe?
Granularity	Server, tool, or client identity	Tool name, parameters, content patterns, user, and more
Action	Always block	Block, alert, monitor, or redact
Scope	Organization, workspace, or gateway	Organization, workspace, or gateway

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

Guardrails

Enforce policies on tool names, parameters, and content

Servers

Browse upstream servers and quick-block from the table

Audit Log

Review every governance and guardrail enforcement event

RBAC

Control who can manage governance rules