Evidence — Context Fence

// the current issue

The exposure gap keeps widening

The SDK now clocks tens of millions of monthly downloads. The number of exposed, unsecured instances climbs right alongside it — adoption without a fence just makes the attack surface bigger.

est. 2026 · reality editionmonday, 2 mar 2026 · vol. 1 · no. 1

The Evidence

Reporting from the supply chain, where the models live.

nov 2024 → mar 2026price: one deployment cycle

lead story · investigated

One in eighteen public MCP servers describes its tools dishonestly

A first-of-its-kind scan of 1,899 open-source servers finds 5.5% carry poisoned tool descriptions and 3.6% hard-code live credentials — eight vulnerability classes, only three overlapping traditional software.

The survey's 1,899 public instances split into eight identifiable failure classes — and only three of them have a direct counterpart in traditional software. The other five are peculiar to the agent stack: the way models pick tools, trust descriptions, and chain calls together.

None of the eight required advanced skill. That is the finding's real weight: every class was demonstrated with ordinary tooling, and the credential play in the survey was pulled off with undergraduate-level Python in an afternoon.

by m. hasan · the evidence bureau

Rows of server racks in a dimly lit datacenter aisle — Public servers advertise production readiness. The survey suggests otherwise.photo: pexels · server aisle

keystrokes, weaponized

agentic audit

Auditors coerce flagship LLMs into code execution and credential theft

A safety audit drives flagship models into malicious code execution and remote access through ordinary tool calls — then ships a scanner to catch it before deployment.

In repeated trials all three flagship models accepted the chain when the calls were phrased as ordinary tool use — executing code, reading files, opening remote access. The scanner makes the same chain detectable before deployment.

clear skies, empty accounts

proof of concept

A 'weather' server, a vault of credentials

Free web tools and an afternoon of work: a disguised server walks off with bank account balances. Undergraduate-level Python is the whole skill bar.

The server advertised one harmless tool and sat behind it with a vault of harvested credentials, filled by calls the model made on its own after a single plausible request.

chip-scale trust

threat taxonomy

When MCP servers attack: the malicious-server playbook

The first systematic taxonomy of what malicious servers actually do — capability smuggling, tool chaining, full system compromise — each staged as a working exploit.

Sixteen risks grouped into four attacker classes, each staged as a working exploit against a production-configured server — and each mapped to the control that closes it.

the quiet channel

no payload required

MPMA: preference manipulation bends MCP tool choice

Crafted preference entries nudge models toward the attacker's own tools — no payload, no prompt injection, just statistics.

No payload, no injected prompt: the manipulation worked through preference statistics alone, which makes it invisible to every detector that watches for text patterns.

reputation as attack surface

ecosystem sweep

Mind your server: parasitic toolchains in the MCP ecosystem

Parasitic toolchains ride legitimate servers' reputation to funnel models into attacker-controlled tools — a sweep measures how deep the infection goes.

Parasites live in the shadow of well-known servers — same reputation, different endpoint. Models follow the trail because the ecosystem has no provenance signal to check.

scopes over promises

supply-chain defense

Tool squatting and rug pulls get a protocol-level answer

OAuth-scoped tool definitions and policy-based access control close the supply-chain gap the ecosystem scans keep finding.

Scoped tool definitions, OAuth, and policy-based access turn the supply chain from a trust exercise into an authorization one — the protocol-level answer to everything else on this page.

feature · threat model

The MCP attack surface, mapped end-to-end

Sixteen distinct security risks across four attacker classes, each confirmed with a working exploit — and a roadmap for the protocol to fix itself.

Sixteen distinct risks, grouped by who carries them: the protocol layer, server authors, model providers, and the client itself. Every one is confirmed with a working exploit rather than a hypothetical — some as blunt as credential theft, others as quiet as preference statistics that nudge a model toward an attacker's tool without ever injecting a prompt.

four attacker classes, sixteen doors

The same curve keeps compounding the gap: monthly SDK downloads grew tenfold across the survey window while exposed instances grew fortyfold. Adoption without a fence just makes the attack surface bigger — the numbers on this page are the proof of that sentence.

hou et al. · huazhong univ.

fig 1 · telemetry

sdk downloads (monthly) vs exposed unsecured instances

gap widens 16× month-over-month

sdk downloads (monthly)10M → 97Mexposed unsecured instances60K → 200K

analysis · governance & controls

Securing MCP: risks, controls, and governance for production agents

Three adversary classes — content injection, compromised supply chains, and overstepping agents — plus the control stack to stop them: scoped authorization, provenance, sandboxing, and central governance.

The control stack the authors propose is deliberately unglamorous: scoped authorization so a tool can only do what it was hired for, provenance so a tool is only as trustworthy as its publisher, sandboxing so a bad tool is boring, and central governance so a team can say no in one place. Familiar controls, applied to a new surface.

The first and last of those need nothing from the model provider. A policy proxy running on the machine can enforce both locally, before any call leaves the box.

errico, ngiam & sojan

the response · zero cloud routing

A policy proxy sits in front of the tools

Seventeen rules, checks under ten milliseconds, and nothing leaves the machine.

Where the survey found eight ways a server can lie, the response is deliberately simple: every tool call is checked against a policy before the model sees it. The checks are schema work — types, scopes, provenance — not an LLM judge, which is why they stay under ten milliseconds.

The policy is a single file on disk, the audit log is a file on disk, and the proxy runs entirely on the machine. There is no telemetry endpoint, no control plane in the default path, and no dependency on a model provider to enforce any of it.

download the fence ↗

the ledger · eight ways a server can lie

01Poisoned tool descriptions
02Hard-coded credentials
03Over-permissive scopes
04Credential exfiltration paths
05Prompt-injection seams
06Unbounded tool chains
07Dependency confusion
08Impersonated publishers

none required advanced skill — all eight demonstrated with ordinary tooling.

fig 2 · findings · 1,899 servers · field survey · 2025

share of public servers with vulnerabilities

8 vulnerability classes found — only 3 overlap traditional software

telemetry · nov 2024 → mar 2026