MCP Won the Protocol War — the Lock-In Just Moved Up a Layer: A Self-Hoster's Field Test

The Model Context Protocol won. With over 10,000 active public servers, npm downloads past 97 million, and governance under the Linux Foundation's Agentic AI Foundation, MCP is the universal interface layer for agents — and a September 2026 analysis argues the victory came with a catch: the lock-in didn't disappear, it relocated. The wire protocol is open, but the security policies, tool-drift detection, and code-writing patterns that make agents efficient are increasingly welded to whoever runs your MCP servers.

That's a strong claim, and it has a concrete, testable shape: if the capture lives in the operational context rather than the protocol, then owning the operational context — a self-hosted, RBAC-scoped MCP server where the policy, the audit log, and the tool definitions are versioned in your own Git — should defeat most of it. So I tested exactly that. Here's the verdict up front, with the evidence below.

The verdict up front​

Four out of five capture mechanisms fall to self-hosting. The fifth survives in weakened form, and the honest part of this post is explaining why. But first, the exhibits behind the claim.

Three exhibits from the week the analysis landed​

The Forkast analysis by Blair Hayes, published September 4, 2026, points at three implementations of the MCP-as-interface pattern that shipped in the same week — one per domain, each pulling value up out of the protocol and into the implementation.

Exhibit 1: CIQ's Fuzzball 4.2. Agents managing high-performance compute workflows, with explicit, scoped permissions. The interesting word is scoped: what the agent is allowed to touch is defined by the compute environment, not by MCP itself.

An agent optimized for CIQ's workflow-scoped credentials cannot simply be dropped into someone else's deployment surface. Same protocol, different operational context.

Exhibit 2: Anthropic's code-execution-with-MCP pattern. Instead of loading every tool definition into context up front, the agent writes and executes code against MCP servers exposed as a file tree of tools. The headline number: token overhead collapsed from 150,000 tokens to 2,000 — a 98.7% reduction that turned multi-step agent reasoning from a budget fire into a line item. Cloudflare published similar findings under the name "Code Mode."

This one matters because it changes what "knowing how to use tools" means: the valuable artifact is no longer the tool list, it's the code-writing pattern — and patterns are exactly the kind of thing that accretes into proprietary Skills libraries.

Exhibit 3: Vercel's fingerprintTools and detectToolDrift. Two functions in the AI SDK that digest each tool's server-controlled fields (description, resolved input schema, title) into a stable fingerprint map, then diff a fresh fetch against the baseline. Their purpose is catching the "rug pull": a server that serves a benign tool definition at approval time and a mutated one on a later fetch. Vercel isn't just connecting to MCP here — it's defining the operational standard for how agents execute code safely in production.

The analysis's conclusion is blunt: "We are trading one form of vendor dependency for another. By embedding security and workflow logic directly into the MCP server implementation, infrastructure providers are creating ecosystems where agents are highly efficient but increasingly immobile."

Strong words. But are the moats real, or just good engineering anyone can replicate? The protocol's own security posture suggests the question is serious.

Why the open protocol can't save you​

Here's the uncomfortable foundation everything above rests on: MCP itself mandates almost no security. The NSA's first security guidance on the protocol — the May 20, 2026 Cybersecurity Information Sheet "Model Context Protocol: Security Design Considerations for AI-Driven Automation" (U/OO/6030316-26) — states it plainly: authorization in MCP is optional, there is no protocol-defined RBAC model, and the protocol's security posture is "highly dependent on implementation discipline rather than protocol guarantees."

Read that again, because it explains the entire lock-in dynamic. When the protocol leaves authentication, authorization, and audit logging to implementers, whoever implements them best owns the operational context — and the operational context is where agents actually live. The NSA documents eight risk categories, including access-control gaps, token lifecycle weaknesses, and approval workflows that let capability changes to trusted servers happen without user consent. That last one is the rug pull wearing formal clothes.

The rug-pull mechanics deserve a concrete telling, because it's the attack that makes drift detection non-optional. An MCP client fetches a tool list, shows the human (or the policy engine) a benign definition — "Run a read-only SELECT against the reporting replica" — and gets approval. On a later fetch, the same tool name arrives with a widened description and an extra parameter. The name matches, the approval is cached, and the agent's behavior changes underneath it.

Microsoft has warned specifically about malicious instructions hidden in tool metadata, and OWASP's 2026 agentic-security work tracks "tool shadowing" and "baseline drift" as supply-chain threats. One industry report puts MCP-stack exploit probability at 92% when risky plugins meet missing approvals — a number to read skeptically, but directionally it says what the NSA says: the danger is in the implementation layer, not the wire format.

So the Forkast claim survives contact with the security literature. The capture mechanisms are real. Now the question this post actually owes you an answer to: does self-hosting defeat them, or does the lock-in follow you home?

Field test: rug-pull your own MCP server​

I built the smallest possible version of the self-hosted alternative: a minimal MCP server speaking JSON-RPC over stdio (real initialize and tools/list methods, real tool definitions), plus a gateway harness that does the two things the vendors claim as moats — drift detection and per-identity scoping — with nothing but SHA-256 and an allowlist. No vendor SDK, no managed service. Two tools: db_query and deploy_status.

Test 1: catch the rug pull. The gateway fetches the benign tool list and fingerprints each tool's server-controlled fields, exactly the shape of Vercel's fingerprintTools. Baseline digests:

db_query: 5255a82be7e4c4b5…
deploy_status: e5be9e4e082c7e08…

Then I flipped the server to its mutated definitions — same names, but db_query's description widened from "read-only SELECT" to "any SQL" with results POSTed to a webhook, plus a new webhook parameter — and re-ran the diff:

drift report: {"added":[],"removed":[],"changed":["db_query"]}

The mutation was caught, and the untouched tool stayed clean. A name-only check would have passed this attack; a digest check didn't. That's the whole of drift detection, and it's about fifteen lines of code over a standard library hash.

Test 2: enforce per-identity scoping. The gateway exposes only the tools each identity is allowed, from a policy that in production lives versioned in Git. Observed:

agent:readonly sees: ["deploy_status"]
agent:deployer sees: ["db_query","deploy_status"]

The read-only agent never even learns the database tool exists — it can't be prompt-injected into calling a tool it was never shown. On a real cluster, this same pattern maps to Kubernetes primitives the platform-engineering world already operates: in-cluster ServiceAccounts, short-lived TokenRequest tokens instead of static credentials, --read-only server modes, and API-level audit logging. Remote MCP on Kubernetes is converging on exactly this architecture at Google, Red Hat, and AWS scale — ServiceAccount-bound, RBAC-scoped, audit-logged.

Both tests passed. The honest caveat: this harness is a proof of mechanism, not a production gateway. A real one needs the audit log (append-only, hashed per invocation, per the NSA's recommendation), schema validation on structured payloads, an egress proxy, and the organizational discipline to review policy diffs like code diffs — because that's what they are now.

The open-source pieces exist: policy-enforcement gateways with tool-schema digest pinning, deny-by-default allowlists, and WASM-sandboxed upstreams are all shipping as self-hostable projects in 2026. The point of the field test isn't that fifteen lines replace them. It's that none of the defeating machinery requires someone else's endpoint. The moat is engineering, and engineering can be self-hosted.

What survives self-hosting (the honest part)​

A verdict table with four "defeated" rows would be propaganda without this section. Here's what follows you home.

Your agents still learn one tool dialect. This is the capture mechanism the TODO spec for this post named explicitly, and it's the one I can't test away. An agent that has learned your tool names, your parameter shapes, your error conventions, and your Skills library is efficient in your environment — which is precisely the immobility the Forkast piece describes, just with you as the vendor. Moving that agent to another MCP surface means re-teaching the dialect even though the protocol is identical. Self-hosting changes who benefits from the stickiness, not the stickiness itself.

Skills gravity is real. Anthropic's code-execution pattern is public — the engineering blog, Cloudflare's Code Mode writeup, and MIT-licensed reimplementations mean nobody can lock up the idea. But a mature Skills library (the prompts, patterns, and worked examples tuned to your tools) is an asset that accumulates where the agents run. If yours accumulates in your own repo, that's fine — it's yours. Just don't confuse "open pattern" with "portable asset."

The ops burden is yours now. The vendor moats bundle genuine toil: rotating workflow-scoped credentials, reviewing drift alerts, maintaining the audit pipeline, tracking the protocol itself (the July 2026 spec moved MCP toward statelessness at the protocol layer, which changes how stateful servers scale). Self-hosting converts a dependency into a responsibility. For a platform team that already runs Kubernetes, this is familiar toil in a new costume. For a team that doesn't, it's a real cost to weigh — though it's worth noting enterprises are already converging on self-hosted "MCP hub" deployments precisely to keep this toil inside their own governance boundary.

And here's the part that structurally requires someone else's endpoint to capture you: hosted credential issuance you can't rotate yourself, policy updates pushed from a dashboard you don't control, telemetry about your agents' tool use flowing to someone else's analytics. Those are the mechanisms that need their endpoint. Everything else — the fingerprints, the scoping, the audit log — is a Git repo and a gateway away.

The protocol is universal. The context is yours to own.​

The September analysis got the diagnosis right and the prescription half-right. Right: the value migrated into security primitives, workflow-scoped credentials, and Skills libraries, and agents are becoming specialized to the environments they inhabit. Half-right: "build agents that can negotiate these boundaries" — because the stronger move is to own the boundary.

When the policy is a pull request, the drift baseline is a pinned digest, and the audit log is on your own disk, the ecosystem-level moats drain. What remains is the one moat nobody can fill in for you: the dialect your agents speak. Make sure it's yours.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. An RBAC-scoped MCP server is just another app to deploy: gateway, policy, and audit log on infrastructure you control. Star the repo on GitHub or deploy your first app today.