Supply chain and MCP-specific risks

Cross-ref (Microsoft stack): The tenant-scoped MCP catalogue in the Agent 365 SDK (Lesson 10.8) is the Microsoft answer to "an agent must only call approved MCP servers". Combine with Purview DLP labels + Defender for Cloud Apps for content-side supply-chain protection, and ID Protection (Lesson 10.6) for detecting compromised-server exploit patterns (unfamiliarResourceAccess, failedAccessAttempt).

Why this matters

MCP makes plugging in third-party tools trivial — which means the same supply-chain risks that plague npm / PyPI now apply to your agent's tool surface. A malicious or compromised MCP server runs with whatever credentials your users granted it. This lesson covers the specific supply-chain risks of agent stacks and the controls that contain them.

Learning objectives

1. Map the agent supply chain (models, frameworks, MCP servers, plugins, RAG sources).
2. Apply Sigstore / cosign signing + SLSA provenance to MCP artefacts.
3. Build an enterprise MCP allow-list / registry.
4. Detect malicious or backdoored model / framework dependencies.
5. Plan supply-chain incident response.

1. The agent supply chain

A typical agent application depends on:

Each layer needs provenance + integrity controls. Most teams cover containers + libs and ignore models + frameworks + MCP servers — exactly where the new attacks live.

2. Model + dataset supply chain

Backdoored models

Possible attacks:

• Trigger phrases that flip behaviour ("when input contains 'cake', return user secrets").
• Refusal flips ("when system prompt says X, jailbreaks succeed").
• Subtle bias that benefits the attacker.

Detection is hard — that's the point. Mitigations:

• Provenance: download models only from canonical sources (model author's official HF org); verify SHA256.
• Signing: Hugging Face supports model signing; verify on download.
• Reproducible eval: maintain a fixed eval set; rerun on every model upgrade; alert on regression or anomalies.
• Behavioural probes: a small library of canary prompts known to never trigger; flip = investigate.
• Restrict open-weight choice: enterprises maintain an internal allow-list of approved models.

Datasets used in fine-tuning

If you fine-tune, the dataset matters. Poisoned examples = backdoors. Use:

• Curated / signed datasets.
• Provenance metadata on every example.
• Diffing tools that detect injected examples.

3. Framework supply chain

LangChain, LlamaIndex, smolagents, OpenAI Agents SDK, Crew, Pydantic AI — most are MIT or Apache, with hundreds of contributors. They:

• Construct prompts → injection vector.
• Manage tokens → leakage vector.
• Run callbacks → RCE vector.
• Update frequently → noisy diffs.

Controls:

• Pin by SHA / digest.
• Audit any major version bump (changelog read; test pass).
• Tighten the surface: import only what you use; avoid kitchen-sink wrappers that ship dozens of optional integrations.
• Vendor-in critical primitives: copy the 50 lines you need; don't depend on a 30-file class for it.
• Watch for typosquats: langchain-comminuty, llama-indexx. Use pip-audit, osv-scanner.

4. MCP server supply chain

The most novel risk in 2026.

Threats:

• Malicious MCP server in a marketplace — installs cleanly, exfils every input.
• Compromised legitimate server — upstream maintainer breached; backdoor in v2.5.1.
• Trojan server — looks like a known one (github-mcp-helper impersonating github-mcp).
• MCP server that overrequests scopes — asks for repo:admin when only repo:read is needed.
• MCP-as-confused-deputy — server has broad access; gets manipulated by injection in tool args.

Controls:

Signing + provenance

Servers built in CI sign their artefacts with cosign (keyless via GitHub OIDC) and produce SLSA provenance:

cosign sign --yes ghcr.io/acme/github-mcp@sha256:abc...
cosign verify --certificate-identity-regexp "https://github.com/acme/" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/acme/github-mcp@sha256:abc...

Verify at deploy + at runtime startup; refuse to run unsigned.

Server identity transparency

Servers should publish:

• Maintainer + contact + key.
• Scope manifest — exact scopes requested per tool.
• Permissions diff between versions (added scopes → require re-consent).
• SBOM + VEX (vulnerability disclosure status).

Marketplaces (Anthropic, OpenAI, third-party MCP registries) increasingly require this. Treat the manifest as part of the security review.

Enterprise allow-list

For company use:

• Maintain an internal registry of approved MCP servers (forked, pinned, signed).
• All agents in the org install only from the registry.
• New server requests go through a review: scope analysis, source review, threat model, monitoring plan.
• Auto-block direct installs from public marketplaces in production.

This is the same model orgs use for npm / PyPI proxying (Artifactory, Nexus, GitHub Packages). Apply it to MCP.

Sandboxing (lesson 4.2)

Even allowed servers run sandboxed. Compromise of one server cannot reach another's data or the host.

5. Detecting a compromised dependency

Signals:

• New egress destinations from a server you trusted.
• New scope requests on upgrade.
• Anomalous output patterns (long encoded strings; URLs to unfamiliar hosts).
• Sudden change in tool latency / size profile.
• Failing SBOM scans.
• CVE published for a pinned version.

Pair with the SIEM (lesson 7.1) and a per-MCP-server traffic profile.

For models: anomaly detection on eval scores, behavioural canaries, refusal-rate drift.

6. Container + runtime supply chain

Standard cloud-native hygiene applies:

• Minimal base images (distroless, alpine).
• Non-root, read-only root FS, drop capabilities.
• Image scan in CI; block on high CVEs.
• Image sign + verify (cosign).
• Admission control on K8s (Kyverno, OPA Gatekeeper) blocks unsigned images.
• Runtime security (Falco, Tetragon) alerts on unexpected syscalls / exec / outbound.

For LLM inference containers specifically: CUDA driver versions matter; pin the whole stack; don't apt-get install -y at startup.

7. Plugin auditing

Even within an allowed MCP server, individual tools can be added or removed. Treat each tool as its own dependency:

• Tool name + version registered.
• Per-tool changes require re-review.
• Telemetry tags every call with tool version.
• Removed tools get deprecated, not silently disappear (clients still in production may call them).

8. Incident response for supply-chain compromise

When (not if) a dependency is found compromised:

1. Identify blast radius: which agents / tenants used the artefact since when? (Audit logs make this 5-minute work; without them it's a week.)
2. Pin + freeze: block the bad version in your registry; disable the relevant MCP server cluster-wide.
3. Rotate credentials: any OAuth/refresh tokens used through the compromised tool — revoke + re-issue.
4. Notify affected users + tenants per your incident policy.
5. Replace: deploy a fixed version with explicit changelog + signed; require re-consent if scopes changed.
6. Post-mortem: how did the malicious version pass review? Add the new check.

Practice this drill at least annually with a tabletop exercise.

9. Hands-on lab (3 h)

1. Sign your MCP server image with cosign (keyless via GitHub OIDC). Verify locally.
2. Add a Kyverno policy to your kind/k3d cluster: refuse to admit any image without a valid cosign signature from your CI identity. Try to deploy an unsigned image; verify it's blocked.
3. Generate an SBOM (syft) for your MCP server image; scan with grype; fix one CVE.
4. Build an internal MCP registry — a simple service that lists approved server image digests + their scope manifests. Deploy a "client" that refuses to install anything not in the registry.
5. Add Falco runtime detection rules for "unexpected outbound connection from mcp-server pod"; verify alert fires when you curl evil.example.com from inside.
6. Run the supply-chain incident drill: simulate a backdoor; trace blast radius with audit logs; rotate creds.

10. Common pitfalls

1. Cosign signatures generated but never verified — adds no security.
2. Trusting any image from a "known" registry without verifying the identity behind the signature.
3. Allow-list maintained by hand and out of date.
4. SBOM generated but never scanned post-deploy.
5. No per-tool version tracking — can't trace blast radius.
6. Letting users install arbitrary MCP servers into shared agents.
7. Model upgrades without behavioural canaries.

11. Self-check

1. Five layers of the agent supply chain.
2. SLSA in two sentences.
3. Cosign keyless via OIDC — how it works.
4. Three signals of a compromised MCP server.
5. Why an internal MCP registry matters for enterprise.

12. References

• Sigstore + cosign + Fulcio + Rekor docs.
• SLSA framework (slsa.dev).
• "Securing the AI/ML Supply Chain" — Microsoft Research / OWASP.
• "MITRE ATLAS" — adversarial threats to AI systems.
• CNCF Catalog: Falco, Tetragon, Kyverno, OPA Gatekeeper.
• HuggingFace model signing docs.
• "OpenSSF Best Practices for OSS Maintainers".
• US NIST SSDF (Secure Software Development Framework).