Should MCP permissions be granted per server or per tool?

Per tool. A single MCP server typically exposes many tools, and granting an agent access to the server grants it every tool on that server, including the destructive ones it will never legitimately need. The review unit should be the individual tool.

Is a CVE feed a reliable signal of MCP exposure?

No. The community tracker at vulnerablemcp.info appears to stop at early February 2026, with newest entries CVE-2026-25536 and CVE-2026-23744, and it does not list CVE-2026-75130, published on 18 August 2026. Exposure should be derived from your own inventory of what is deployed and what each server can reach.

MCP governance: inventory, review and decommission

Why is this a governance problem rather than a protocol problem?

MCP servers spread for three reasons that have nothing to do with MCP. An individual adds one to solve a problem in front of them. It works immediately, so nobody asks whether it should exist. And it carries a credential — usually one that already existed, attached to a person, with no expiry. A correctly implemented server nobody can name is still an ungoverned integration into a live system; the 2026-07-28 release and the vulnerability record are covered separately.

The NSA's Cybersecurity Information Sheet on MCP (Ver. 1.0, May 2026, U/OO/6030316-26 | PP-26-1834) reaches the same place from the technical side: secure-by-default behaviour must be enforced through implementation rigour rather than assumed from protocol guarantees. Organisationally, rigour means a named person is accountable for a named deployment — which is why the NSA's control list includes maintaining inventories of deployed MCP agents with versioning and patch history.

What does an MCP server inventory need to record?

Versioning and patch history are the floor. A register that supports a decision — should this server exist, should this agent reach it — needs eight fields.

Field	What it records, and why
Server name	Internal identifier plus upstream project. Two teams running the same project are two rows.
Owner	A named individual, not a team. Teams are reorganised; the row survives, the accountability does not.
Data classes reachable	What it can read or write. Drives hosting, trust-zone placement and approval thresholds.
Tools exposed	Every tool by name, not a count. The unit of permission review, and the field most registers omit.
Local or external	Inside your boundary, or a third party's deployment.
Authentication method	How it authenticates and how the credential expires. `OAuth`, a static API key and a personal access token are three different governance positions.
Version and patch status	Protocol version, server release, date of last patch.
Date last reviewed	Plus a next-review date. A row with no review date is one nobody is looking at.

The version field earns its place for a reason easy to miss. The 2026-07-28 specification is marked Current, not Final. A deprecated feature must remain at least twelve months before removal, but the expedited path floors that at ninety days given an active security risk and Core Maintainer approval. Ninety days is your worst-case upgrade window, plannable only if you know what you are running.

What should onboarding a new MCP server require?

Seven checks, run before the server is connected to anything in production.

Is the upstream project actively maintained, with established code review? The NSA's phrasing is a deployment gate, not a preference.
Local or external, decided by data class. Where the server can reach sensitive data, run a local instance rather than an external deployment. Convenience is not the input to that decision; classification is.
How does it authenticate, and how does the credential expire? An audit of 5,200+ MCP servers found 53% relying on static API keys or personal access tokens against 8.5% using OAuth (Astrix, October 2025 — vendor-run, directional). The direction is the point: the default posture is a long-lived secret with no expiry. Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents (CIMD); Enterprise-Managed Authorization is an official extension at modelcontextprotocol/ext-auth.
Which individual tools does it expose, and does the agent need all of them? Enumerate them — see below.
Where does it sit relative to your trust boundaries? "Clearly define trust boundaries between MCP components, including agents, plugins, models, and end users", segregate tools into data classification zones, and put filtering proxies on outbound connections. Validate parameters against schemas, expected ranges and execution context.
Does its telemetry reach the SIEM? Log every tool and model invocation with exact parameters, identities and cryptographic hashes of results, into the existing SIEM before go-live — the standard for any agent audit trail.
Who owns it, and when is it next reviewed? A named person and a date. Without both, the server has been deployed rather than adopted.

Why should the review unit be the tool, not the server?

A single server typically exposes read, list and create operations and, very often, delete or configuration operations. Access is granted at the server. So an agent needing one read tool is handed the destructive ones too, permanently, because they arrived in the same package.

The correct unit of review is the tool. For each: what does it do, what data class does it touch, is the effect reversible, and does this agent need it? Tools failing the last question are not connected, whatever else the server offers. This is the MCP-specific form of the argument in scoping agent permissions — the read, propose and commit distinction does most of the work, and only exists if you look below the server.

Two controls sit at the same level: sandbox tool execution with OS-level frameworks (AppContainers, SELinux, AppArmor, seccomp) under least privilege, and treat all tool outputs as untrusted input. Preventing unauthorised actions depends on both.

Who decommissions an MCP server?

Nobody, usually — and that is the missing lifecycle stage. A server with no owner is never removed, because removal requires someone to decide it is no longer needed. Meanwhile its credential keeps working. Given how many deployments authenticate with a static key, the common failure is not a breach of a live integration but a forgotten one: a valid, unexpiring credential on a server that stopped being useful eighteen months ago.

Decommissioning is three steps in fixed order. Revoke the credential first — that is the step that removes capability. Then strip the server configuration from every agent and client referencing it. Then confirm by scan.

The scan is also how you find what onboarding never caught. The NSA recommends regularly scanning networks with tools such as MCP Scanner, Ramparts or CyberMCP to identify unauthenticated, vulnerable or unauthorised MCP servers. Run it against the inventory: anything found that the register does not list is an onboarding failure, and that discrepancy count is the better governance metric.

Is a CVE feed a usable exposure signal?

No — though it is commonly used as a substitute for one. The tracker at vulnerablemcp.info appears to stop at early February 2026 — newest entries CVE-2026-25536 (4 February) and CVE-2026-23744 (1 February) — and does not list CVE-2026-75130, published 18 August 2026. It is not a current index; the full argument and the disclosure timeline behind it are set out separately. Your exposure signal has to come from your own register of what is deployed, what it can reach and what it is patched to — something you maintain, not a feed you subscribe to.

Frequently asked questions

What should an MCP server inventory record?

Name, a named individual owner, data classes reachable, tools exposed, local or external hosting, authentication method, version and patch status, date last reviewed.

Per server or per tool?

Per tool. Granting the server grants every tool on it, including destructive operations the agent will never legitimately need.

Should an MCP server run locally or externally?

The data class decides. Run local instances where sensitive data is in scope, and segregate tools into data classification zones.

How do you find MCP servers nobody registered?

Scan for them — MCP Scanner, Ramparts or CyberMCP — and reconcile against the inventory. The gap is the finding.

Why a named owner rather than a team?

Because decommissioning requires a decision, and teams do not decide about integrations they inherited without knowing they had them.

BarzelVault operates at the level this article argues for: policy evaluated per tool rather than per server, before the call executes, with identity, parameters and decision recorded either way — backed by policy-as-code with versioning and rollback, credential isolation so agents never hold plaintext secrets, and cryptographically signed audit receipts. Barzel Central Gateway is the federation layer above it: tool registration and sync across upstream systems, virtual MCP server composition, per-tool enforcement on identity, policy, region, cost and health, identity mapping via OIDC, Entra ID, Okta, SAML-proxy or SPIFFE, and observability exports over W3C trace context, OTLP/HTTP and SIEM. Together they do not replace the inventory; they make it enforceable.

In practice

Permission before the action. Evidence after it.

The duties on this page attach to the moment an automated system acts: who permitted it, on which data, under which policy version, and what a person saw before approving. Barzel enforces that decision before execution and writes the record an auditor, a regulator or a data subject can be shown.

MCP 2026-07-28: approval and authorization primitives are now in the protocol

BarzelVault

The AI action firewall: decide what an agent may do before it does it.

Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
Credential isolation, spend and action limits, and an emergency kill switch.

Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize

Start free Ask by email Product page Documentation

Barzel Central Gateway

The AI governance control plane: one inventory and one policy layer across every MCP server and agent.

Registers and synchronises every tool; enforces identity, policy, region, cost and health per tool.
Identity mapping through OIDC, Entra ID, Okta, SAML and SPIFFE, with credential brokerage.
Trace and SIEM export (W3C trace context, OTLP) for the security team and the regulator.

Free tier: 1,000 calls a monthPaid plans from $10 a monthLive on MCPize