Provenance is the documented origin of a component. Provenance verification means confirming — cryptographically, not just by name — that a component came from who it claims to come from, has not been modified since it was published, and matches a hash or signature you have on record.
For traditional software, this means package signatures and checksums. For agentic systems, it extends to: tool manifests, MCP server identities, model weights, prompt templates, agent cards, and knowledge base snapshots.
A Software Bill of Materials (SBOM) is a machine-readable inventory of every software dependency in a system — versions, hashes, licenses, and known vulnerabilities. SBOM standards like SPDX and CycloneDX are already used in regulated industries.
An AI Bill of Materials (AIBOM) extends this concept to AI-specific components: the model and its version, the tools and plugins with their exact manifest hashes, the prompt templates with their version IDs, the knowledge base and its ingestion pipeline provenance.
If you can't produce an AIBOM for your agentic system, you don't know what you're running.
MIT01 directly addresses Scenarios 1 (Amazon Q update), 2 (GitHub tool data), and 5 (poisoned npm package). If you pin every dependency to a content hash in your AIBOM and verify that hash before loading, a compromised registry version will fail the hash check — even if it passes signature verification from a hijacked key.
Ask your team: do you have a documented list of every AI model, tool, and data source your agents depend on — and does anyone verify that list hasn't changed before a deployment goes live? An undocumented dependency is one an attacker can replace without anyone noticing.