AI projects depend on a category of components a conventional software dependency inventory usually never captures: models and their weights, training and fine-tuning datasets, embedding models, agent frameworks, prompt libraries. Each one is a dependency in exactly the same sense as any package or library an application relies on, and each carries supply chain risk that deserves the same due diligence already applied to conventional software dependencies, just extended to cover these newer categories.
Model weights and checkpoints are dependencies, not just configuration
A model checkpoint, whether downloaded from a public repository or handed over by a vendor, is a dependency with its own provenance, integrity, and potential vulnerability considerations, not unlike a downloaded software package. Verify the source and integrity of any model weights you use, particularly for open-weight models pulled from public repositories, and treat a model checkpoint's provenance with the same scrutiny you'd apply to any other downloaded artifact about to run inside your infrastructure.
Training and fine-tuning datasets carry poisoning risk
If your organization fine-tunes models on external or crowd-sourced datasets, those datasets carry the poisoning risk covered in AI-specific threat guidance elsewhere: a dataset with deliberately manipulated examples baked in can bias the resulting model in ways that are hard to catch through conventional testing. Apply provenance and integrity review to training datasets the same way you'd review a third-party code dependency, and stay especially cautious with datasets aggregated from many independent, unverified contributors.
Agent frameworks and libraries need conventional dependency scanning
Agent frameworks, orchestration libraries, and other AI-specific software dependencies belong in the same dependency vulnerability scanning and update processes already applied to conventional software dependencies. This category is growing fast and includes a lot of newer, less mature projects compared to established conventional libraries, which means the actual security maturity, maintenance activity, and vulnerability disclosure practices of a given AI-specific dependency deserve direct evaluation, not an assumption of maturity just because the project looks popular.
Third-party prompt libraries and templates are an underexamined dependency
Organizations sometimes adopt third-party prompt templates or prompt engineering libraries with none of the scrutiny given to code dependencies, even though a prompt template that's never been reviewed for the security properties covered throughout prompt security guidance, proper separation of instructions and data, no embedded secrets, can introduce exactly the same risks as a prompt built internally without that review. Treat adopted prompt templates as a dependency that needs review, not as harmless configuration you can skim past.
Vector databases and embedding services are infrastructure dependencies
The vector database and embedding service dependencies covered in RAG security guidance deserve the same operational and security due diligence as any infrastructure dependency: understanding their own dependency chains, security update practices, known vulnerability history, rather than treating them as a black box just because their specific function is less familiar than a conventional relational database.
Build an AI-specific dependency inventory
Extend the organization's existing dependency inventory, or build a parallel one specifically for AI-related dependencies if the existing tooling doesn't naturally fit these categories, listing models, datasets, agent frameworks, and prompt libraries alongside their source, version, and last review date. This connects directly to the broader AI system inventory covered in governance guidance, just applied at the dependency level instead of the system level.
Monitor for security advisories specific to AI dependencies
Beyond conventional vulnerability databases, monitor sources specifically covering AI-related security research and advisories, since vulnerability disclosure practices and databases for this category are a lot less standardized and mature than for conventional software. Relying solely on conventional vulnerability feeds can easily miss issues specific to AI frameworks, models, or related tooling.
Where TELEON fits
TELEON's audit trail, applied through the gateway or supported middleware, can help identify which models and agent frameworks are actually in use across an organization's deployments, supporting the AI-specific dependency inventory described above.
Verifying model and dataset provenance, scanning agent framework dependencies, and reviewing prompt libraries for security properties remain engineering and procurement work that has to be conducted directly against each specific dependency.
A short checklist
- Verify provenance and integrity of model weights and checkpoints,
especially for downloaded open-weight models.
- Review training and fine-tuning dataset provenance for poisoning risk.
- Apply conventional dependency vulnerability scanning to agent
frameworks and libraries.
- Review adopted third-party prompt templates for the same security
properties as internally built prompts.
- Apply infrastructure due diligence to vector databases and embedding
services.
- Build an explicit AI-specific dependency inventory.
- Monitor AI-specific security advisory sources, not only conventional
vulnerability feeds.
AI projects introduce dependency categories, models, datasets, agent frameworks, prompt libraries, that a conventional software dependency inventory often misses entirely, and applying the same due diligence already practiced for conventional dependencies to these newer categories closes a supply chain gap that is easy to overlook simply because these components are less familiar.