They can enter builds with unknown origin, unreviewed behaviour and delegated access to data or tools. Once embedded, they can change runtime outcomes or expose sensitive information without appearing in normal dependency controls, which turns an inventory gap into an integrity and trust problem.
Why untracked AI components create supply-chain risk
Untracked AI components create supply-chain risk because they can arrive outside the controls that teams use to verify origin, integrity and approved behaviour. If a model, package, agent, tool, plugin or dependency is not inventoried, security teams cannot reliably tell what was introduced, what it can access, or whether it was altered upstream before it reached production.
That problem is not limited to software composition. AI components often carry embedded prompts, model weights, code, connectors, API calls, evaluation logic or runtime permissions. When those elements are invisible to the build or release process, the component can affect outcomes, data handling and trust decisions without showing up as a normal, reviewed dependency.
In practical terms, the risk is that an untracked component becomes a hidden path into the environment. It may inherit permissions from the application, reach sensitive data through a connector, or call external services during execution. For supply-chain defenders, that means the integrity question is not only “was the artifact delivered?” but also “was its behaviour understood and approved before it influenced production?”
What makes untracked AI components different from ordinary dependency drift?
Ordinary dependency drift usually creates versioning or patching problems. Untracked AI components go further because their behaviour can be partly data-driven, dynamically configured or delegated at runtime. A component may look benign in code review yet still change answers, fetch external content, invoke tools or expose information once it is live and connected to real data.
This is why inventory matters so much. If teams cannot tie an AI component back to a known owner, source, version and permission set, they lose the ability to assess whether it belongs in the software bill of materials, whether it should be signed or pinned, and whether it needs a tighter approval path before deployment. SLSA is useful here because provenance and build integrity are the controls that help distinguish approved artifacts from shadow additions.
Untracked AI also creates an evidence gap during incident response. If a model, agent or plugin was never recorded, responders may know that data moved or behaviour changed but not which component initiated it, what inputs it saw, or which downstream systems it could influence. That slows containment and makes it harder to prove whether the issue was a malicious insertion, a compromised upstream package or an internal approval failure.
How the supply-chain failure actually happens
The failure usually starts with incomplete inventory, then moves into trust by assumption. A component is copied from a registry, notebook, repository or third-party service and introduced into a pipeline because it “worked” or came from a familiar source. If it is not tracked as a distinct artifact, no one can consistently verify whether its origin, signatures, dependencies and runtime permissions match the intended design.
That is where hidden behaviour becomes dangerous. The component may load additional code, contact an external endpoint, inherit broad data access, or influence outputs in ways that were never reviewed. If the component is later updated, swapped or repackaged upstream, the team may still believe it is the same trusted object. In a supply-chain context, that is an integrity failure, not just a documentation issue.
OWASP Non-Human Identity Top 10 is relevant because untracked components often bring their own secrets, tokens or delegated access, which expands the blast radius when the component is compromised. OpenSSF is also useful because supply-chain hygiene depends on knowing what entered the build, how it was verified, and whether it can be traced back to a trusted source.
Risk and Threat Considerations
Untracked AI components create an attractive attack path because they sit in the gap between development convenience and production trust. An attacker, malicious maintainer or poisoned upstream dependency can exploit that gap to insert behaviour that is hard to inventory, hard to review and easy to deploy at scale.
Failure mechanism: A component enters the build or runtime path without a reliable record of origin, version, permission scope or behavioural review, so normal dependency controls and approval workflows do not fully cover it.
Impact: The organisation can inherit hidden data access, unauthorized tool use, altered outputs or silent exfiltration, and the resulting compromise is difficult to detect, attribute or remove quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while SLSA sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Directly addresses build provenance and artifact integrity for untracked AI components. |
| Recommendation — Require verifiable provenance and signed artifacts before promoting AI components into production. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Untracked AI components can bring hidden secrets or tokens into the supply chain. |
| NHI-05 — Overprivileged NHI | Hidden AI components often inherit more access than their known trust level justifies. | |
| NHI-03 — Vulnerable Third-Party NHI | Untracked third-party AI components create supplier and upstream compromise exposure. | |
| Recommendation — Inventory and protect every AI component that can carry secrets or tokens. Limit runtime permissions for AI components to the minimum needed for their task. Assess third-party AI components for provenance, maintenance and compromise risk before adoption. | ||
| OWASP Agentic AI Top 10 | ASI04 — Agentic Supply Chain Vulnerabilities | AI components introduced without tracking are a supply-chain weakness for agents. |
| Recommendation — Track and verify every agent component before it can reach production workflows. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | The core issue is unauthorized upstream insertion or alteration of trusted components. |
| Recommendation — Hunt for upstream tampering and validate trusted build inputs and dependencies. | ||
Practitioner Guidance
What to verify: Treat every AI model, agent, plugin, tool connector and wrapper as an inventory item with an owner, source, version, purpose and permission scope. If any of those fields are unknown, do not treat the component as production-ready.
Decision rule: If the component can read sensitive data, call external services, or change runtime decisions, require provenance checks and explicit approval before it is allowed into the release path.
What good looks like: The build and runtime record should let you answer which AI components are present, which ones are trusted, and which ones can touch secrets, data or tools without having to inspect the live system manually.
Practitioner takeaway: The main control objective is not to ban AI components, but to make sure no component can influence production outcomes unless its origin, behaviour and authority are visible enough to be trusted.
Related resources from NHI Mgmt Group
- Why do AI-generated package choices create more supply chain risk than normal developer workflows?
- Why do AI chatbots create supply chain risk for IAM teams?
- Why do AI tooling packages create higher supply chain risk than ordinary libraries?
- Why do AI-suggested dependencies create supply chain risk?