Why do unverified AI tools create supply chain risk in enterprise environments?

Why This Matters for Security Teams

Unverified AI tools are not just another app approval problem. They are often high-trust integrations that can read mail, index documents, inspect tickets, call APIs, and move data across business systems with very little human review. That creates supply chain risk because the tool’s behaviour, dependencies, and data flows may change after approval, especially when the tool is updated through an external package, plugin, or hosted service. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward tighter asset visibility and access governance, but AI tools complicate both. NHIMG research on The 52 NHI breaches Report shows the same pattern repeatedly: once a third-party identity or integration is trusted, it becomes a durable path into the environment.

One additional concern is secrets exposure. NHIMG’s The State of Secrets Sprawl 2026 reports that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which is a good signal of how quickly AI-related integrations can create hidden credential paths. In practice, many security teams encounter the problem only after an unexpected data flow, token abuse, or third-party compromise has already turned a convenience tool into a supply chain entry point.

How It Works in Practice

The risk usually starts when a business user or developer connects an AI tool to production-adjacent systems for speed. The tool may request OAuth scopes, API keys, webhook access, or service account credentials so it can summarise documents, generate tickets, or automate workflows. If those permissions are broad, the AI tool becomes part of the trusted software supply chain, even if it was never reviewed like one. That is why the OWASP Non-Human Identity Top 10 treats non-human access paths as first-class security objects rather than background plumbing.

Operationally, security teams should map each AI tool to four questions:

• What identity does the tool use, and is it a human account, service account, or workload identity?
• What permissions does it actually need versus what it was granted?
• Where do prompts, logs, embeddings, and outputs travel after ingestion?
• How is the tool updated, revoked, and monitored after approval?

This is where NHI control becomes supply chain control. A tool that can access repositories, ticketing systems, or internal knowledge bases can also ingest secrets, generate malicious prompts, or exfiltrate sensitive content through normal workflows. The right pattern is to prefer narrow scopes, short-lived credentials, explicit vendor inventory, and continuous review. NHIMG case research such as the LiteLLM PyPI package breach and the Shai Hulud npm malware campaign shows how quickly package or plugin trust can become credential theft. These controls tend to break down when the tool is allowed to self-update or expand scopes inside a loosely governed SaaS environment because the approved risk profile no longer matches the live integration.

Common Variations and Edge Cases

Tighter tool approval often increases friction for developers and business users, so organisations have to balance speed against inspection depth. There is no universal standard for this yet, but current guidance suggests treating AI tools differently based on their access surface rather than their vendor brand or user popularity.

Some tools are relatively low risk, such as standalone assistants with no internal connectors. Others are high risk because they sit inside CI/CD, code review, chat, or content management systems and can inherit broad enterprise permissions. The edge case that surprises teams most is the “benign plugin” that later gains new capabilities through an update or a connected app marketplace. That is why change control must include permission drift, not just version drift.

For broader governance, the 52 NHI Breaches Analysis is useful for spotting recurring failure modes, while the JetBrains Marketplace AI Plugin Campaign illustrates how marketplace trust can be abused at scale. The practical takeaway is simple: if an AI tool can touch sensitive systems, it should be treated as an external supplier plus an identity-bearing workload, not as a harmless productivity add-on.

Related resources from NHI Mgmt Group

• Why do AI agent skills create supply chain risk in enterprise environments?
• Why do generative AI tools create more data leakage risk than traditional collaboration apps in enterprise environments?
• Why do unverified container registries create supply chain risk in modern DevSecOps environments?
• Why do AI coding environments create more secret exposure risk than standard developer tools?