The Model Context Protocol standardized how agents reach tools, and in doing so it standardized three implicit trust relationships that most deployments never examine. An agent trusts a tool's self-description enough to decide when and how to call it. It trusts a tool's results enough to reason over them. And it trusts its configuration enough to execute what the config says. In 2025 and 2026 attackers went after all three: an RCE in MCP infrastructure (CVE-2025-6514, CVSS 9.6), a config-swap against Cursor (MCPoison, CVE-2025-54136), a backdoored gateway package on PyPI, and a research literature on tool poisoning and approval-view concealment. This paper treats MCP as an untrusted supply chain and specifies the mediation layer that makes it safe to use.
The three inputs, and why each is reachable
- Tool descriptions: free text the server supplies and the agent reads to decide behavior. The field is unsanitized, so a malicious server can embed instructions in what looks like help text — tool poisoning — and the agent follows them invisibly.
- Tool results: content returned from a call, which is indistinguishable from any other retrieved context once it enters the model, and therefore a vector for indirect prompt injection.
- Configuration: which servers exist, at which versions, with which permissions. MCPoison showed that an approval granted once can be silently swapped for something else later.
Descriptions, results, and configuration are separate attacker-reachable inputs. Mediation has to inspect each, not just proxy the transport.
Checkpoint 1: inspect metadata before the tool is usable
Most gateways inspect tool calls. That is too late and too narrow. The description and schema have to be inspected before the agent is permitted to use the tool at all, because the description is itself an instruction channel. The mediation layer scans tool metadata for embedded imperatives, for hidden Unicode — including TAG-block sequences that render invisibly — and for any mismatch between what a human is shown in the approval view and what the raw metadata actually contains. Research in 2026 reproduced this approval-view fidelity gap across three independent server implementations: the operator approves benign-looking help text while the agent executes a concealed payload. Closing that gap means the bytes that reach the model and the bytes shown to the approver must be proven identical, and metadata that fails inspection disqualifies the tool.
Checkpoint 2: pin and verify against silent swaps
MCP servers and gateway packages are dependencies, and they deserve dependency discipline. The mediation layer pins server identity and version, verifies integrity, and refuses to honor a configuration that changed underneath a prior approval — the exact move MCPoison exploited. Trust is bound to a verified artifact, not to a name that can be repointed. In a multi-tenant deployment this binding is per-tenant and derived from the tenant's own key material, so one tenant's tool configuration can never be resolved or swapped into another's execution context.
Server identity, versions, and permits are derived per tenant, so a compromised or swapped tool in one tenant cannot cross into another.
Checkpoint 3: authorize the call that actually executes
The final checkpoint evaluates the concrete tool call at the moment before execution: this resource, these arguments, this tenant, this provenance. Pre-action authorization is what separates “the agent decided to call the tool” from “the call was permitted to run.” Two properties make it robust. First, the permit is issued by a component that does not read model prompts, so it cannot be argued out of a denial. Second, a call whose justification traces to an unverified tool description or an externally injected result is precisely the pattern to refuse — provenance from checkpoint one feeds the decision here.
The permit is evaluated against the actual call at pre-action time. An approval granted earlier does not authorize a different action now.
Fail-closed and observable
Every checkpoint denies by default. An unverified server, an inconclusive metadata scan, an unreachable permit service, a version that no longer matches its pin — each results in refusal, not a pass. And each decision is emitted as an evidence event: which tool, which tenant, what was flagged in the metadata, what was denied and why. This is what turns a compromised MCP server from a blind spot into a finding. The CVEs of 2026 were damaging partly because the compromises were silent; mediation that records its refusals removes the silence.
Scope of the claim
Mediation does not make MCP safe in the absolute; it makes MCP inspected, pinned, tenant-bound, and fail-closed, with a record of every refusal. That is a bounded, defensible claim, and it maps directly onto the failure modes the year's incidents exercised: tool poisoning is caught at metadata inspection, silent swaps are caught at pinning, injected results are constrained at authorization, and every one of them leaves evidence. The alternative — proxying MCP transport and trusting the three inputs — is the design the CVEs were written against.