> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Feature Governance
> How MCP Manager applies least privilege to MCP capabilities: provisioning tools, resources, and prompts with an allowing-all, allow-if-conditions-met, or blocking-all scheme; pinning a capability by matching its name, title, and description so a changed description stops passing the gateway (a defense against tool poisoning and rug pulls); why it uses an allowlist rather than an 'allow everything except these' denylist; the fail-closed allowlist mode; and how feature governance differs from runtime rules.
**Feature governance** is how **MCP Manager** decides *which* MCP capabilities — tools, prompts, and resources — a gateway exposes from each server, and which it hides. It is the principle of **least privilege** applied to MCP: an agent should see only the specific capabilities its job requires, not the entire, over-provisioned surface a server happens to offer. This is distinct from [runtime protections](/security/runtime-protections), which scan the *content* of calls that are allowed through; feature governance controls what is exposed and callable in the first place.
Configuring which features a server exposes is gated by the **Manage feature provisioning settings** capability. If you don't see provisioning controls on a server within a gateway, your role doesn't have it — capabilities are assigned per role and fully configurable, so access depends on the capability, not on any fixed role name. See the [capabilities reference](/deployment/rbac-and-roles/capabilities).
## Why govern features: the over-provisioning problem
Every tool a server exposes is described to the model in metadata — a name, a description, and an input schema — and **that metadata is read straight into the model's context** on every request. Servers routinely expose far more tools than any one task needs (a single server's tool count can swing from dozens to over a hundred between releases). Exposing all of them has three costs at once:
* **Cost.** Tool metadata is frequently many times larger than the user's actual prompt, and you pay for those tokens on every call.
* **Accuracy.** Irrelevant tool definitions pull the model off course; a tighter, relevant toolset measurably improves how reliably it picks the right tool.
* **Security.** Every exposed tool is attack surface — a capability the agent could be tricked into calling, and a description that could carry a hidden instruction.
Feature governance addresses all three by letting an administrator expose only what's needed. And because the **gateway** enforces the exposure, least privilege doesn't depend on the vendor: a server that ships no tool-level enable/disable controls natively is governed exactly like one that does. The same idea is introduced from the gateway's side in [Curating which tools are exposed](/mcp-gateway-concepts/mcp-gateways#curating-which-tools-are-exposed); this page covers the security model and the matching rules in depth.
## The three provisioning modes
For each server on a gateway, and **independently for each feature type** (tools, prompts, resources), you choose one of three schemes:
* **Allowing all** — every capability of that type passes through. Convenient, and the scheme a server gets when first assigned to a gateway, but it exposes the full surface.
* **Allow if conditions are met** — only capabilities matching an explicit **allowlist** pass; everything else is hidden and uncallable. This is least privilege in practice.
* **Blocking all** — no capability of that type is exposed. Use this to switch off, say, prompts or resources entirely while keeping tools.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart TB
Req["Capability from upstream server"] --> Mode{"Provisioning scheme"}
Mode -->|"Allowing all"| Pass["✅
Exposed and callable"]
Mode -->|"Blocking all"| Drop["🚫
Hidden — denied"]
Mode -->|"Allow if conditions are met"| Match{"Matches an
allowlist condition?"}
Match -->|"Yes"| Pass
Match -->|"No"| Drop
classDef trust fill:#2fedb4,color:#062b4c,stroke:#059669,stroke-width:1.5px;
classDef blocked fill:#ec9c9d,color:#12141d,stroke:#eb5757,stroke-width:2px;
class Pass trust;
class Drop blocked;
```
**Allow if conditions are met** is **fail-closed by design**: the moment you switch a feature type to it, an empty or unmatched allowlist passes **nothing** — a capability is exposed only once it matches an entry you added, never by default. A freshly assigned server, by contrast, starts at **Allowing all** so a simple setup works without curation; tightening it to an allowlist is the deliberate act that locks it down.
## Pinning a capability by its metadata
Under **Allow selected**, each allowlist entry is a **condition** that matches a capability on the fields you choose — its **name**, its **title**, and its **description**. The matching is exact, and it combines in two directions:
* Within one condition, **all the fields you specify must match** (a logical AND). A condition that pins both name and description matches only a capability whose name *and* description are exactly what you approved.
* Across multiple conditions, **any one match is enough** (a logical OR). The first condition a capability satisfies admits it.
A capability that matches no condition is **filtered out of the capability list** the client sees and is **denied if called directly** — it is as if the tool does not exist on that gateway. You decide how tightly to pin each entry: match on **name only** to tolerate the vendor improving a description over time, or match on **name and description** to freeze exactly the wording you reviewed.
## A defense against tool poisoning and rug pulls
Pinning on the description is the control that neutralizes two specific MCP attacks:
* **Tool poisoning** — a server embeds hidden instructions in a tool's description or schema. Because that text enters the model's context, a poisoned description is effectively untrusted code aimed at your agent.
* **Rug pulls** — a tool that was benign when you approved it is silently changed afterward, so its description (or behavior) turns malicious without any visible signal.
Both depend on the metadata changing out from under you. When you pin a tool by name **and** description, a changed description **no longer matches the condition**, so the tool stops passing the gateway — it is filtered out rather than forwarded to the model with its new, unreviewed wording. In effect, you approve a specific version of a tool's metadata, and anything that doesn't match what you approved is dropped.
Be precise about the mechanism: this protection is the **allowlist condition no longer matching**, which filters the changed capability out. It is enforcement by exact match, not a separate change-detection system that diffs against a stored snapshot or notifies you that a specific field changed. The security outcome — unreviewed metadata never reaches the model — is the same, and every filtered or blocked capability is recorded in your logs (see below).
## Why an allowlist, not a denylist
MCP Manager filters by **allowlist** — you name what passes, and everything else is hidden. It deliberately does not offer the inverse: a **denylist** that exposes every capability except a named few you block. A denylist reads as convenient ("expose this server, just hide its `send_email` tool"), but it fails *open* the moment the upstream server changes, because the block is anchored to capability metadata the server itself controls:
* **A renamed capability escapes the block.** Block `send_email`, and if the server later renames it to `dispatch_email`, your rule no longer matches — the tool passes the gateway unblocked.
* **A newly added capability is exposed unreviewed.** If the server adds `bulk_send_email`, a denylist that names only `send_email` lets the new tool through with no chance for you to see it first.
Both are the [rug pull](#a-defense-against-tool-poisoning-and-rug-pulls) above in another guise: the server changes what it offers, and a block-based rule silently stops protecting you. An allowlist fails the other way — closed. Anything you didn't explicitly approve, including renamed or newly added capabilities, simply doesn't pass until you review and add it.
To get the convenience of "everything except one," use **Allow if conditions are met**: add every capability the server currently offers, then remove the one you don't want. You end up with an explicit allowlist, so any capability the server adds or renames later still has to be reviewed before it can reach a client.
## How a governed decision appears in logs
Feature-governance decisions are recorded so you can audit them. In your [logs](/features/viewing-logs), a capability removed from a list because it didn't match the allowlist is logged with the type `gateway_feature_filtered`, and a directly attempted call to a disallowed capability is logged as `gateway_feature_blocked`. This lets you confirm what a gateway is exposing and catch the moment a previously-passing tool stops matching — for example, when an upstream server renames or rewrites it.
## Feature governance versus runtime rules
Feature governance and [runtime protections](/security/runtime-protections) are complementary layers, and it helps to keep them distinct:
* **Feature governance** decides *which capabilities exist* on the gateway — applied to **tools, prompts, and resources**, before any call is made. It is about exposure and least privilege.
* **Runtime rules** scan the *content* of allowed calls — applied to **tool calls and results** — and can block, redact, or rewrite them in flight.
Together they form defense in depth: governance shrinks the surface to only the tools you intend, and runtime rules inspect what flows through that smaller surface.
## Further reading
The complementary layer that scans the content of the calls governance allows through.
How a gateway presents one filtered, namespaced toolset across many servers.
The how-to for building allowlists and pinning tools by their metadata.
The `gateway_feature_filtered` and `gateway_feature_blocked` log types, and the full column reference.
## External sources
How tools, their descriptions, and schemas are defined in the protocol.