Slide 24 of 28
Part 4 — PreventionSlide 24
Slide 24 · MIT06 + MIT07 — Continuous Validation and Content Hash Pinning
MIT06: Keep checking after deployment. MIT07: Pin to content, not version numbers.
Both controls address the fact that a component can be legitimate when first loaded and malicious later.
MIT06 — Continuous validation and monitoring

Supply chain attacks often succeed because the compromise happens gradually or after the initial security check. A package is scanned at install time and passes. Three weeks later, the registry entry is hijacked and a malicious update is pushed. If you only check at install time, you don't know the running version is now compromised.

Continuous validation means periodically re-checking every loaded component against known-good hashes, scanning tool descriptors for unexpected changes, monitoring agent behavior for anomalies that suggest a poisoned component, and alerting when the running environment diverges from the approved inventory (AIBOM).

Tools: SBOM drift detection, agent behavioral baselines, anomaly alerting on unexpected network calls, tool call frequency monitoring.

MIT07 — Content hash pinning

Version numbers are mutable labels. A package at version 2.3.1 today can have different content than the same version number tomorrow if the registry is compromised or the maintainer republishes.

Content hash pinning means every dependency is locked to a specific SHA-256 hash of its actual bytes — not its version number. If the bytes change, the hash changes, and the load fails. The attacker can't substitute a malicious package without changing its hash, which breaks the pinned reference.

For prompt templates: store a hash of the approved template and verify it at load time. For MCP servers: store a hash of the approved server manifest. For agent cards: store the expected public key fingerprint and verify the signature.

← Back MIT08 + MIT09 — Kill Switch and Zero Trust →