“You can vet a counterparty’s credit all you want. It doesn’t set the position limit — the limit is what fires when the trade goes against you.”
Why MCP Sprawl Matters Now
The Model Context Protocol won the plumbing war faster than anyone underwrote. In under two years it went from an Anthropic proposal to the default way models reach into source control, ticketing systems, databases, and internal APIs — with Cursor, Cline, Continue, Claude Desktop, Goose, and Aider all speaking it. That’s the good news. The bad news is that every large rollout now carries a thicket of MCP servers stitching AI into the most sensitive systems in the building, and almost none of them have an owner. Procurement never saw them. The TPRM register doesn’t list them. They arrived the way npm install arrives — one developer, one config file, broad permissions, no review.
This is a supply-chain exposure wearing a productivity costume. An MCP server is code you did not write, running with the file and network scope of an engineer, brokering a model’s access to production. In capital-markets terms, every connector is a counterparty, and the estate has quietly opened thousands of lines of credit with names nobody ran a check on.
| Metric | Figure | Source |
|---|---|---|
| Organizations that have deployed AI agents / plan to within a year | 17% / 42% | Gartner CIO survey |
| Unauthorized agent transactions caused by internal misuse through 2028 | ≥80% | Gartner SPA |
| Value-at-stake Ospiri attributes to ungoverned agent exposure | +$670K | Ospiri published research |
| Agentic AI projects canceled by end of 2027 | 40%+ | Gartner (2025) |
Here’s the bet this post argues: reputation tells you who is safe to trade with; kernel runtime control is the position limit that fires when a vetted counterparty does something it shouldn’t. You need both, and most of the market is selling only the first.
Two Sides of One Control: Reputation vs. Runtime
The instinct is to treat MCP governance as a vetting problem — build an allowlist, approve the good servers, block the rest. That’s necessary and insufficient. A reputation verdict is a point-in-time credit rating; it says nothing about what the connector does at 2 a.m. three weeks after approval, when a dependency update quietly widens its scope. The two controls answer different questions and fail in different places.
| Dimension | Connector reputation (pre-authorization) | Kernel runtime control (in-flight) |
|---|---|---|
| Question answered | Should this MCP server be trusted at all? | Is this trusted server behaving right now? |
| Timing | Before broad permissions are granted | At the moment of the syscall |
| What it catches | Known-bad, unmaintained, over-scoped-by-design connectors | Drift, compromise, over-permissioned behavior in an approved server |
| Signal | Research-vetted verdict on MCP / skill / agent-file | Kernel evidence of file access and egress |
| Blind spot | Zero-day behavior in a “clean” server | A server that was never a good idea to begin with |
| Failure mode if used alone | Approved-then-drifted goes unenforced | Firewall with no idea which connectors are junk |
Reputation screens the counterparty. Runtime control enforces the limit. Buy one without the other and you’ve either got a clean list with no enforcement, or enforcement with no priors.
The Anatomy of an Over-Permissioned MCP
Walk a single connector from install to incident and watch where a monitoring-only stack loses the thread:
- Frictionless install. A developer adds an MCP server for “read my repo and open tickets” from a registry entry with 400 stars. It requests filesystem and network scope. Nobody negotiates the scope down — the default is broad because the protocol is young and the ergonomics reward permissiveness.
- Scope creep by dependency. Weeks later a transitive update expands what the server touches. No changelog entry flags it. The credit rating from install day is now stale, but nothing re-rates it.
- The local-filesystem move. The server reads a privileged memo, a
.envwith production keys, or an NPI-laden export sitting in the developer’s working directory. This is entirely on-disk — no watched API call, no SaaS log line, invisible to the layer most teams instrument. - Ambiguous egress. When it finally makes a network call, the payload is a plausible size to a plausible endpoint. The API log shows something; it doesn’t show anything actionable. Because MCP support is uneven across platforms, the inspection surface is non-standardized and the alerts are full of false positives.
Four steps, and the two that carried the actual loss — the on-disk read and the drift — are exactly the two the connector’s install-day reputation and the network log both missed.
Pricing the Connector: A Counterparty-Risk Frame
If you want a number the board will respect, treat the MCP estate like a book of counterparty exposures. The risk each connector carries is the product of how much it can touch and how blind you are to what it does.
Connector Risk = (Permission Scope × Reversibility) + (Reputation Uncertainty × Runtime Blindness)
| Factor | What it measures | Why MCP sprawl scores badly |
|---|---|---|
| Permission scope | Breadth of file + network access granted | Defaults are broad; scope-down is rare |
| Reversibility | Can the action be undone once taken? | An exfiltrated key or deleted file is irreversible |
| Reputation uncertainty | Confidence in the connector’s provenance and maintenance | Registry stars are not a security review |
| Runtime blindness | Share of the connector’s actions you can’t see live | Local filesystem + non-standard protocol = large |
The math forces an uncomfortable read: a stack that only screens reputation optimizes one term and leaves runtime blindness untouched, while a stack that only monitors traffic leaves both scope and reputation unpriced. The exposure lives in the cross-terms, which is precisely where single-sided tooling has no coverage.
The Architectural Answer: Verdict at the Door, Limit at the Kernel
The fix is to put the two controls where each actually works — reputation at the point of authorization, enforcement below the protocol at the one layer every connector shares regardless of whether it speaks MCP cleanly: the kernel.
| Control point | Reputation-only stack | Reputation + kernel enforcement |
|---|---|---|
| New MCP / skill / agent-file | Allow or block on a research-vetted verdict | Same verdict — plus scope is enforced, not assumed |
| Approved server accessing a sensitive file | Trusted, unwatched | Copy-on-write redirection — server gets a sandboxed copy, the real file never moves |
| Proof of what happened | Inferred from network metadata | Kernel evidence — the syscall itself, captured at the source |
| Drift after approval | Invisible until an incident | Caught at the first out-of-policy file or egress operation |
| Response | Revoke the entry, after the fact | In-line decision: allow, block, or allow-with-evidence |
Two distinctions vendors blur, named precisely. Block-on-deny halts the connector and breaks the developer’s workflow — the control engineering teams rip out within two quarters. Copy-on-write lets the connector run against a redirected copy, so the work proceeds and the sensitive original is never exposed. And this is a layer, not a replacement: kernel enforcement sits alongside your EDR (CrowdStrike, SentinelOne, Defender), your DLP (Purview, Forcepoint), and your prompt guardrails (Lakera, Protect AI). Guardrails read the prompt; reputation rates the counterparty; the kernel enforces the limit. None of the three substitutes for the other.
What CISOs Should Do This Quarter
| Step | Action | Output | Effort |
|---|---|---|---|
| 1 | Inventory every MCP server, skill, and agent-file across the dev estate | An honest counterparty list — most of it currently unowned | Low |
| 2 | Screen each connector against a research-vetted reputation verdict | A rated book: trusted, watch, block | Medium |
| 3 | Enforce scope at the kernel on the highest-exposure endpoints | Copy-on-write + kernel evidence for approved-but-broad servers | Medium |
| 4 | Set a re-rating trigger on drift, not a calendar | Alerts when an approved connector’s behavior changes, not an annual review | Low |
The Bottom Line
An MCP server is a counterparty you extended production credit to without running the check — and reputation alone is a credit rating that goes stale the moment the position moves against you. Screening tells you who to trade with; kernel runtime control is the limit that fires when a vetted connector reaches for a file it was never scoped to touch. Because MCP support is uneven and the most dangerous operations happen on the local disk, the kernel is the one control point every connector shares. Rate the counterparty, then enforce the limit — doing only the first is how a clean allowlist still prints a loss.
If your team is sizing this for the next budget cycle, request a working session. We will inventory your live MCP estate, rate the connectors against research-vetted reputation, and scope a kernel-enforcement deployment against your actual endpoints. Ninety minutes to turn an unowned supply chain into a priced, limited book.