MCP Governance
Overview
MCP Governance is not a separate product inside Cerbera AI: it is the MCP Servers view in AI Discovery, combined with the same Rules engine used for every other kind of AI traffic. The registry tells you what MCP servers exist and how risky they look; rules let you allow, monitor, redact, or block the traffic to them.
Detection requires the Cerbera proxy. See Deployment to roll it out.
The MCP Servers View
The MCP Servers tab gives a fleet-wide view of MCP activity, with one row per server:
| Column | Description |
|---|---|
| Server name | The MCP server, as discovered from client configuration and traffic. |
| Risk | A risk band (critical, high, medium, low) and score, based on factors like whether the server is provider-maintained and vetted, or a third-party/community server of unknown provenance. |
| Transport | stdio, http, or sse. |
| Endpoint | For stdio servers, the launching package (for example an npx package name); for http/sse servers, the URL. |
| Clients | Which AI clients (Claude Desktop, Cursor, and others) connect to this server. |
| Users | How many people connect to it. |
| Tool calls | Volume of tool invocations observed. |
| Last seen | When the server was last active. |
Drilling into a server shows its full detail: every client and user connected to it, and the individual tool calls observed.
Risk Scoring
Every discovered server gets a vetted flag and a risk score/band. A server maintained directly by a well-known provider (for example Slack's own MCP server) scores lower risk than a third-party or community wrapper around a vendor's API, maintained by unknown parties, that users frequently connect to and hand API keys or tokens over to. Reviewing the highest-risk servers first is the fastest way to triage a large inventory.
Enforcing Policy with Rules
There is no dedicated "MCP rule" object with its own form. Instead, you write a rule the same way you would for any other AI traffic, and scope it to MCP servers, for example by matching on the server's host, URL, or transport. Give it the action you want:
Allow a known-good server
Scope a rule to a specific server (for example by URL) with action Allow, so it is never caught by a broader block rule.
Block an unwanted server
Scope a rule to a specific server or transport (for example all stdio servers launched via a given package) with action Block.
For a tiered approach, allow the servers you have reviewed and consider provider-maintained, and write a broader monitor or block rule for everything else, using the risk score in the MCP Servers view to decide where to draw the line. See Rules for how to build and simulate a rule before shipping it.
Alerts
An unverified or unvetted MCP server connection is one of the detection types that feeds alerts: when Cerbera sees a client connect to a server it does not consider vetted, or a rule you wrote matches, an alert is raised the same way any other rule match is.
Use Cases
Prevent shadow AI
Review the MCP Servers view regularly, and write block rules for servers you have not reviewed or do not sanction.
Prevent credential exfiltration
Watch the risk score and the alerts it feeds for token exposure and misconfiguration, then block the offending server and rotate the leaked credential.
Audit AI usage
Export MCP activity and alerts as evidence for SOC 2 or ISO 27001 audits covering AI tool usage and data access. See Openness & Interoperability.
Roll out an approved MCP catalog
Start in monitor mode, observe for a few weeks which MCP servers employees connect to, then add block rules for the ones you do not sanction, starting with the highest-risk entries.