Tool and MCP Security

Module B4 · Course 2B — Securing & Attacking Harnesses and LLMs

90 minutes · The tool layer is a dual attack surface — description and output — and MCP made it a software supply-chain problem wearing an LLM costume.

B2 defended what the agent does with a tool's output. It deliberately did not defend what the agent believes a tool is for. The tool's own description is text the model reads as prompt — and it arrives before any tool call exists for the taint gate to inspect.

Pillar 2 — Trust Surfaces

Why this module exists

OWASP names both halves

MCP turned third-party tool providers into a registry the agent trusts. That is the exact transition npm/PyPI made when they moved from vendored to dynamically-loaded dependencies — and it inherited the exact same threat model.

B4.1 — The tool layer as a dual attack surface

Description + output · why the description surface is upstream of B2's gate

The dual surface — description + output

Schema poisoning — the timing is the vulnerability

B2's taint gate runs on that read_file call. It checks whether the args derive from tainted output. They do not — they derive from the trusted description. The taint check finds nothing tainted. The gate passes. The injection succeeded, and it succeeded because the description was trusted without verification.

B4.2 — The MCP threat model & the four attacks

Schema poisoning · evil twins · output forgery · supply-chain compromise · the SolarWinds parallel

The four MCP attacks

SolarWinds is the precise parallel

B4.3 — Provenance, signing, and registry trust

Signed manifests · output provenance · registry pinning · TOFU defeated · the Sigstore/SLSA parallels

Signed-manifest verification — the load-bearing gate

// B4.3 — runs at REGISTRATION time, BEFORE the tool enters the trusted layer.
export function verifyToolManifest(manifest: ToolManifest, verify: VerifyFn): ManifestDecision {
  // 1. Publisher MUST be in the pinned registry. NO TOFU.
  const pinnedKey = REGISTRY.get(manifest.publisher);
  if (!pinnedKey)
    return { allow: false, reason: `publisher not in pinned registry (TOFU refused)` };

  // 2. Signature MUST verify against the pinned key.
  const canon = canonicalManifestBytes(manifest);
  if (!verify(canon, manifest.signature, pinnedKey))
    return { allow: false, reason: `manifest signature invalid` };

  // 3. Description sanity — refuse hidden/zero-width chars.
  if (/[\u200B-\u200F\u202A-\u202E\u0000-\u0008]/.test(manifest.description))
    return { allow: false, reason: `hidden chars in description` };

  return { allow: true, reason: "manifest signed by pinned publisher key" };
}

The load-bearing line: if (!pinnedKey). The evil twin's publisher is not in the pinned registry → refused, regardless of how legitimate its description reads. Deterministic. No model in the loop.

Output-provenance check — before the result enters context

// B4.3 — runs at RESULT-ENTRY time, BEFORE the result enters the context window.
export function verifyResultProvenance(
  result: ToolResult, expectedPublisher: string,
  seenNonces: Set<string>, verify: VerifyFn,
): ProvenanceDecision {
  const att = result.provenance;
  // 1. Server identity must match the tool's publisher (anti-forgery).
  if (att.serverIdentity !== expectedPublisher)
    return { allow: false, reason: `identity mismatch`, trust: "unverified" };
  // 2. Result hash must match content (anti-tamper).
  if (sha256(result.content) !== att.resultHash)
    return { allow: false, reason: `hash mismatch`, trust: "unverified" };
  // 3. Nonce must be fresh (anti-replay).
  if (seenNonces.has(att.nonce))
    return { allow: false, reason: `nonce replay`, trust: "unverified" };
  seenNonces.add(att.nonce);
  // 4. Signature verifies against pinned key.
  const pinnedKey = REGISTRY.get(att.serverIdentity);
  if (!pinnedKey || !verify(`${att.serverIdentity}|${att.resultHash}|${att.nonce}`, att.signature, pinnedKey))
    return { allow: false, reason: `signature invalid`, trust: "unverified" };
  return { allow: true, reason: "provenance verified", trust: "verified_internal" };
}

Provenance is the input to B2's taint boundary. Verified trust level → correct taint tag → B2's gate behaves correctly on the tool layer.

TOFU defeated — the evil twin's enabler

B4.4 — The defense stack & the measured trust surface

Five defenses · determinism/probability from B2.3 · the measured surface as the deliverable

The five defenses — B2.3 applied to the tool layer

The measured trust surface — not "trusted"

Anti-patterns

Lab & what's next

Lab (07): Build the Tool-Trust Gate — (a) a signed-manifest verifier that refuses registration of tools whose publisher is not pinned or whose signature is invalid, (b) an output-provenance checker that refuses entry of results whose attestation does not verify, (c) a tool-description injection scanner wired as an advisory hook. TypeScript, type-safe, no GPU. Includes a schema-poisoning demo and an evil-twin demo so you can watch your gate catch each.

The load-bearing principle

Determinism on the identity boundary (signing, pinning, provenance). Probability on the semantic boundary (the description scanner). Capability minimization as the floor. That is B2.3 applied to the tool layer.