# Ep. 2: Can you trust your AI Agents? Securing the AI Software Supply Chain | Security in the AI Era

[Watch on tuber](https://tuber.guzus.xyz/video/KoKF5c2Iurc/summary) · [YouTube](https://youtu.be/KoKF5c2Iurc)

**Score: 56/100 · skim**

Amy Chang, who leads Cisco AI Threat Intelligence and Security Research, says that downloading an open-source (usually "open-weight") AI model also pulls in its upstream history: earlier versions, training data, fine-tuning choices, files, licenses and any security exposure. Teams should check this "provenance" against their specific use case instead of trusting the model name, provider, license or model card. Cisco's free Provenance Explorer and its open-source Model Provenance Kit are presented as tools that help with this, but they don't guarantee a model is safe.

- **0:00-0:56** — **Intro and framing.** Host Chad Skipper opens the "Cisco Security in the AI Era" series, which looks at how AI and AI agents change attacks and how companies and security teams respond. This episode is about trusting the AI supply chain: the models and components entering companies as teams build agents. The goal is practical risk guidance, not headlines.

- **0:58-2:31** — **What a downloaded model actually brings in.** A model from a site like Hugging Face isn't a clean, self-contained file. It reflects upstream weights, data, training methods, tools, licenses and every organization that worked on it before. Chang notes that most of these are open-weight models: you can download the weights, but the full training data, code and recipe may not be available. The repository can also contain config files, tokenizers, custom code, serialized objects and usage restrictions. You also inherit the model's history, including its base checkpoint (the earlier saved version it was built from), fine-tuning choices and training data. That history can affect how the model behaves, what the license lets you do, and your security exposure. Problems found upstream later still have to be handled, so they shouldn't be dismissed.

- **2:33-4:08** — **Why name, provider and license aren't enough.** These facts still matter, but they answer narrow questions. The name tells you how the model is presented, the provider tells you who released or maintains it, and the license tells you what use is allowed. None of them confirms the model's technical ancestry, whether it was modified, whether its files are safe to load, or how it will behave in your use case. Chang introduces **model provenance** as the missing layer. Teams can't manage dependencies they can't see, and provenance affects due diligence, incident response, licensing and compliance. It also lets you find other models that need review when an upstream problem is discovered. Model cards and repository metadata are useful disclosures, but they can be incomplete, inconsistent, outdated or self-reported, so they aren't verified facts.

- **4:08-5:50** — **What the Provenance Explorer shows.** Provenance means the model's technical family tree: a verifiable history of how the trained weights were derived. It shows earlier checkpoints and whether the model was fine-tuned, distilled (trained to copy a larger model) or re-released under a different name. An Explorer entry, aimed at security, development and governance teams, shows:
  - basic public details about the model;
  - its lineage, meaning declared ancestors and earlier variants;
  - flags for license or usage restrictions;
  - repository security information. Cisco scans as many repository files as it can and flags known suspicious artifacts or reported vulnerabilities.

- **5:51-6:44** — **Start with the use case, not the signal.** Teams shouldn't treat any single signal as an automatic yes or no. First, define what the model will do:
  - Will it power an agent?
  - Will it connect to internal services?
  - What sensitive data will it see?
  - Can it call tools or take actions with real consequences?
  - What would a failure look like?

  The answers decide which signals matter most.

- **6:44-8:03** — **Matching each signal to the risk it answers.**
  - **Licensing:** Is your intended use legally allowed and within the provider's stated restrictions?
  - **Where the provider is based:** Are there jurisdiction, procurement, privacy or geographic concerns tied to where the provider or lab is headquartered?
  - **Lineage:** Do upstream models or datasets need review? They can change behavior or pass along biases and vulnerabilities.
  - **Deployment:** Who hosts the model, does it receive your data, and who controls updates further down the chain?

- **8:03-9:12** — **How customers are approaching it.** Practices vary. Chang's advice is not to feel overwhelmed by the idea of verifying your entire model supply chain across the whole AI lifecycle. Let the use case decide which risk checks and procedures apply. Use the signals as inputs, not as shortcuts that label models "OK" or "not OK", and focus on the technical details you actually need. She compares this to the software bill of materials (SBOM), which lists a program's components and third- and fourth-party dependencies. The same approach should apply to AI models.

- **9:12-10:00** — **The tool is not a guarantee; related resources.** Skipper says outright that the Explorer doesn't certify a model as safe or suitable for every use. Chang points to two other Cisco resources:
  - the open-source **Model Provenance Kit** on GitHub;
  - a **repository of fingerprints** you can run in your own environment to check whether the models you download are related to known models.

- **10:00-11:35** — **Recommended steps after using the tool:**
  1. Confirm the file and version you downloaded match the entry you reviewed.
  2. Read the model card and license, especially where the Explorer flags missing information or restrictions.
  3. Scan the whole repository and check any custom or serialized code before loading it, because malicious model files can hide executables inside them.
  4. Test the model against risks that matter for your use case: simulated adversarial behavior, attempts to leak data, bias, reliability and tool misuse.
  5. Use the results to decide whether to keep the model, limit it to other uses, or add controls and guardrails.

- **11:35-12:27** — **Wrap-up and outro.** Skipper sums up that the AI supply chain is much more than a Hugging Face model card. The Model Provenance Kit is on Cisco AI Defense's open-source GitHub, and the Explorer is free at provenance.aidefense.cisco.com. The rest is a newsletter plug and series sign-off, with no new content.

**Practical takeaways:**
- Treat every downloaded model as a dependency with a history (base checkpoints, data, fine-tunes, code, licenses), not as one standalone file.
- Define the use case first: data access, tool calls, autonomy and what failure would cost. Then decide which provenance signals matter.
- Don't trust self-reported model cards on their own. Check lineage with tools such as Cisco's Explorer, Provenance Kit and fingerprint repository.
- Never load serialized or custom code before scanning it, since model files can hide executables.
- After vetting, run adversarial and use-case-specific tests, and add guardrails or restrict use when you find risks.

## Audience signal

- No high-signal audience themes available.