> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ultra.security/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/observability/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 | Behavior for unmatched calls | When to use |
| ------------------ | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **default\_allow** | Allow the call through. This is the historical behavior and the default for new organizations. | Permissive baseline. Rules act as a blocklist that carves exceptions out of "everything is allowed." |
| **default\_deny** | Block the call. Only servers, tools, and clients covered by an explicit allow rule can reach the upstream server. | Zero-trust baseline. Rules act as an allowlist of pre-approved access. Use this when you want to ensure nothing reaches an upstream server without being explicitly named. |
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:
| 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](/hub/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.
Navigate to **Servers** in the Ultra Hub sidebar.
Admins see a **Block** action on each server row.
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.
Navigate to **Governance** in the Ultra Hub sidebar and click **+ Create rule**.
Choose Organization, Workspace, or Gateway. The form previews exactly which clients the rule will apply to once active.
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.
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.
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.
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, then proceed through the confirmation dialog. Tool calls that the rule was blocking are allowed again after the change syncs to your gateways, 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 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.
Navigate to **Governance** in the Hub sidebar and select the scope (organization or workspace) you want to lock down.
Click the posture control and choose **default\_deny**. A confirmation dialog opens listing every server currently in use within the scope that does not yet have an allow rule.
Confirm the dialog to auto-generate one allow rule per listed server, scoped to the same place as the posture change. These rules are tagged as posture-generated so Ultra can clean them up later. The posture flips to `default_deny` once the rules are saved.
Use the [Access view](#access-view) to see what is being allowed by the auto-generated rules versus by explicit policy. Replace the auto-generated rules with narrower allow rules (specific tools, specific clients) as you build out your allowlist, and delete the ones you no longer need.
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 a `governance` event in the [audit log](/observability/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 server that was targeted
* The tool the client tried to call
* The user and client 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 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:
| Column | Description |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Server** | The upstream MCP server. |
| **Status** | `Managed` when Ultra is the source of truth for the server, `Unmanaged` when drift was detected on a client, or `Partial` when some clients have it and others don't. |
| **Access** | Allowed or Blocked, based on the effective rules and posture at the row's scope. |
| **Reason** | One of: `Explicit allow rule`, `Explicit block rule`, `Default allow`, or `Default deny`. |
| **Rule** | The matched governance rule, if the decision came from a rule rather than the posture. |
| **Context** | Whether the decision is set directly at this scope or inherited from a parent. |
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
| 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 block 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 block 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 block rule across the org while the integration is evaluated. |
| Zero-trust for a sensitive workspace | Set the workspace posture to `default_deny`, accept the auto-generated allow rules for currently-used servers, then narrow them down to specific tools and clients over time. |
| Fine-grained matching on parameters or content | Use a [custom guardrail](/hub/guardrails) 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](/hub/guardrails) instead.
## Related
Enforce policies on tool names, parameters, and content
Browse upstream servers and quick-block from the table
Review every governance and guardrail enforcement event
Control who can manage governance rules