Management Summary
AI has quietly become one of the most concentrated, least-governed supply chains in the enterprise. In the last 18 months, organizations have onboarded dozens of AI models, APIs, agents, copilots, and embedded features — often without the due diligence that would be standard for a mid-sized SaaS vendor.
The problem for boards and CISOs is not that AI is risky in the abstract. It is that AI supply chain risk is fundamentally different from traditional third-party risk:
- the "supplier" may be a model you cannot inspect,
- the "dependency" may be a dataset you cannot audit,
- the "update" may silently change model behavior overnight,
- the "access path" may be an autonomous agent acting on your behalf,
- and the "incident" may be invisible until data has already left the building.
Most existing supply chain controls — SBOMs, vendor questionnaires, penetration tests, and SOC 2 reports — were not designed for probabilistic systems, opaque training data, or agentic execution. The regulatory environment is also shifting fast: the EU AI Act, NIST AI RMF, ISO/IEC 42001, and updated expectations under NIS2 and DORA all now touch AI supply chain governance directly or indirectly.
For leadership, five questions should be answerable today:
- Which AI models, providers, and agents are in production — and who owns them?
- What data leaves our perimeter through AI APIs, copilots, or embedded features?
- Which critical business decisions already depend on third-party AI output?
- What happens if our primary model provider is breached, degraded, or cut off?
- Can we detect and contain an AI-specific incident — prompt injection, model poisoning, agent compromise, or data exfiltration via inference?
If the answers are unclear, the AI supply chain is already ahead of the governance model.
Executive lens
AI governance should not start as an abstract ethics program. It should start with a practical question: what AI dependencies already exist, what data do they touch, and what would happen if they failed or were compromised?
1. Why AI Changes the Supply Chain Conversation
The big picture
Traditional supply chain security assumes a vendor ships software, which can be inventoried, scanned, patched, and replaced. AI breaks most of these assumptions.
An AI supply chain includes:
- foundation model providers such as OpenAI, Anthropic, Google, Meta, Mistral, and open-weight model ecosystems,
- model hosting platforms such as Azure OpenAI, AWS Bedrock, Vertex AI, and Hugging Face,
- training and fine-tuning data, often third-party and often difficult to verify,
- vector databases and retrieval systems feeding models with enterprise data,
- AI agents and orchestration frameworks such as LangChain, LlamaIndex, and AutoGPT-style systems,
- embedded AI features in SaaS tools already used by the business, including Microsoft 365, Salesforce, Zoom, Slack, and GitHub,
- model marketplaces and package ecosystems, including Hugging Face and npm / PyPI packages wrapping models,
- shadow AI — employees using consumer AI tools without IT, security, or procurement knowledge.
Each of these is a distinct trust relationship, and most organizations have never mapped them.
Why this matters for boards
The uncomfortable truth is that AI adoption has outpaced AI governance by 12–24 months in many enterprises. The typical pattern is familiar:
- business units adopted AI tools during 2023–2024,
- IT and security were pulled in after the fact,
- procurement signed contracts without AI-specific clauses,
- legal is now catching up on data, IP, and liability questions,
- and the board is being asked to approve AI strategy without a full inventory of what is already running.
This is the same dynamic that created the cloud security debt of 2015–2018 — except AI moves faster and the blast radius is larger.
2. The New Attack Surface: What Is Actually Different About AI
The big picture
AI does not just add new suppliers. It adds new categories of risk that existing controls were not designed to detect. The five that matter most at board level are model poisoning, prompt injection, inference-based data leakage, agentic identity risk, and foundation model concentration.
2.1 Model supply chain poisoning
Hugging Face hosts well over 1.5 million models. Researchers have repeatedly demonstrated malicious models containing embedded backdoors, pickle-based code execution, or subtly manipulated weights. In 2024, JFrog researchers reported around 100 malicious models on Hugging Face with code execution payloads, and subsequent scanning initiatives continue to show that model repositories need to be treated as software supply chain infrastructure.
The question for the board: Do we know which models — by exact version and origin — are in production, and did any of them come from a public repository without integrity verification?
2.2 Prompt injection as the new "SQL injection"
Prompt injection is the #1 risk in the OWASP Top 10 for LLM Applications. It is not a theoretical problem. Indirect prompt injection — where malicious instructions are hidden in a document, email, webpage, or calendar invite that an AI agent reads — has been demonstrated against Microsoft Copilot, Google Gemini, ChatGPT, and most major agent frameworks.
The supply chain angle is simple: you do not have to be attacked directly. If your AI agent ingests content from a compromised supplier, partner, or public source, the attacker can hijack your agent's behavior through someone else's data.
2.3 Data exfiltration through inference
Every prompt sent to an external model is, by definition, data leaving your perimeter. The controls that matter are not abstract. They are specific operational questions:
- Is the data logged by the provider?
- Is it used for training now or later, including under changed terms?
- Who at the provider can access it?
- What happens if the provider is breached?
- What happens if the provider is acquired or shuts down?
Samsung's 2023 ChatGPT leak — employees pasting proprietary source code into a consumer tool — is now the prototype incident. Most organizations still cannot answer, with evidence, what prompts their employees sent yesterday.
2.4 Agentic AI and the identity problem
AI agents now execute real actions: sending emails, writing code, approving transactions, calling APIs, and clicking through SaaS interfaces on behalf of users. Each agent is effectively a non-human identity with privileged access — and most do not fit neatly into existing IAM, PAM, or zero-trust models.
The blast radius question is uncomfortable but necessary: If our AI agent is compromised through prompt injection or a poisoned tool, what is the maximum damage it can do before anyone notices?
Most organizations have no answer.
2.5 Concentration risk in foundation models
A very small number of foundation model providers now underpin a large share of enterprise AI. If OpenAI, Anthropic, or a major cloud AI platform experiences a breach, outage, policy change, or geopolitical disruption, the impact is simultaneous and global.
This is the same concentration risk logic that DORA Article 29 was written for — except the financial sector is far from the only one exposed.
Control implication
AI risk is not only a vendor risk issue. It is also a data governance, identity, software supply chain, incident response, and operational resilience issue.
3. What Regulators Already Expect
The big picture
AI governance is not waiting for a single unified regulation. Obligations are already arriving through multiple overlapping frameworks:
| Framework | What it requires — AI supply chain angle |
|---|---|
| EU AI Act | Risk classification of AI systems; provider and deployer obligations; transparency on training data; incident reporting for high-risk systems; GPAI obligations including systemic risk. |
| NIST AI RMF 1.0 + Generative AI Profile | Governance, mapping, measurement, and management of AI risk across the lifecycle, including third-party components and generative AI-specific risk scenarios. |
| ISO/IEC 42001 | The first certifiable AI management system standard — a direct analogue to ISO 27001 for AI governance, roles, risk treatment, monitoring, and continual improvement. |
| NIS2 | AI systems supporting essential or important services fall under supply chain security and cybersecurity risk-management obligations, especially where suppliers support critical operations. |
| DORA | AI-based ICT services used by financial entities are ICT third-party services. The Register of Information, due diligence, contract, concentration risk, and exit expectations apply. |
| Sector-specific guidance | Supervisory expectations from bodies such as EBA, EIOPA, FDA, and other sector regulators increasingly extend model risk management obligations to GenAI and AI-enabled services. |
The practical implication is clear: AI suppliers are already regulated third parties under laws many organizations are already subject to. You do not need a new AI regulation to be accountable. You need to apply existing supply chain, model risk, cybersecurity, and operational resilience obligations to AI.
Key references:
- EU AI Act — Regulation (EU) 2024/1689
- NIST AI RMF 1.0
- NIST AI RMF Generative AI Profile
- ISO/IEC 42001:2023
- OWASP Top 10 for LLM Applications
- DORA Article 29
- NIS2 Article 21
4. Five Moves for the Next 90 Days
The big picture
The goal is not to solve AI governance in one quarter. It is to close the visibility gap and establish the minimum controls that prevent the largest, most common failure modes.
4.1 Build an AI inventory — including shadow AI
Map every AI system in use: approved, embedded, experimental, and unsanctioned. Include:
- model name, version, provider, and hosting location,
- business owner, use case, and data types processed,
- whether decisions are human-in-the-loop or automated,
- contractual terms around training, logging, retention, and data residency.
If you cannot produce this list, every other AI control is theoretical.
4.2 Classify AI use cases by risk — not by hype
Not every AI use case needs board-level scrutiny. But high-risk use cases — those affecting customers, employees, safety, financial decisions, regulated data, or critical operations — need explicit risk assessment, approval, and monitoring. The EU AI Act's risk tiers are a reasonable starting taxonomy even outside the EU.
4.3 Extend third-party risk to AI specifically
Update vendor due diligence to cover:
- model provenance and training data transparency,
- security of the model provider's infrastructure,
- prompt and output logging policies,
- data use, retention, and training opt-outs,
- sub-processors, including the underlying foundation model,
- incident notification terms for AI-specific incidents,
- exit and portability for fine-tuned models, embeddings, prompts, and evaluation data.
4.4 Apply zero trust to AI agents
Treat every AI agent as a non-human privileged identity:
- scoped, least-privilege access,
- per-action authorization for high-impact operations,
- full logging of agent actions,
- human approval for irreversible or material decisions,
- kill switches and rate limits.
4.5 Run an AI incident tabletop
Pick a realistic scenario and walk it through with security, legal, privacy, communications, and the business owner. Examples:
- an employee pasted confidential customer data into a consumer AI tool,
- your AI agent sent a fraudulent email because it followed instructions in a phishing message,
- your primary model provider announced a breach of logged prompts,
- a fine-tuned model was found to leak training data under adversarial prompts,
- a regulator asks for a list of every AI system making automated decisions about customers.
If the response is improvised, the governance model is not ready.
5. What an AI Supply Chain Program Should Produce
Boards do not need a technical lecture on model architecture. They need evidence that management understands AI dependencies and can control them. A minimum viable AI supply chain program should therefore produce five outputs:
- An AI inventory covering approved tools, embedded AI, agents, models, APIs, and shadow AI.
- A risk-tiering model that classifies AI use cases by business impact, data sensitivity, automation level, and regulatory exposure.
- AI-specific third-party due diligence covering model provenance, logging, retention, training use, sub-processors, incident notification, and exit provisions.
- Controls for AI agents based on least privilege, human approval, logging, rate limits, and kill switches.
- An AI incident response playbook covering prompt injection, model compromise, data leakage, provider breach, unsafe output, and agent misuse.
These outputs are simple enough to explain to the board and concrete enough to test in an audit.
Conclusion: AI Is Not a Tool Category — It Is a New Supply Chain
The organizations that will handle AI risk well are not necessarily the ones with the most sophisticated models. They are the ones that recognized early that AI is a supply chain discipline, not just a technology program.
The board-level questions will not be about benchmarks or model performance. They will be:
- Do we know what we depend on?
- Do we control what leaves the building?
- Can we detect when something goes wrong?
- Can we contain the damage when it does?
- Can we defend our decisions to regulators, customers, and auditors?
AI has moved from experiment to dependency faster than almost any technology in recent memory. The governance models need to catch up — and the supply chain lens is the fastest way to get there.
Board-Ready AI Supply Chain Evidence Pack
For teams that need to turn the AI supply chain discussion into evidence, the following pack is a practical starting point:
- AI inventory with model, provider, owner, use case, and data classification,
- shadow AI discovery results and remediation plan,
- AI use-case risk classification methodology,
- AI-specific vendor due diligence questionnaire,
- contract clauses covering training use, logging, retention, incident notification, and exit,
- list of AI agents and associated non-human identities, permissions, and business owners,
- logging and monitoring standard for prompts, outputs, agent actions, and high-risk decisions,
- AI incident response playbook and tabletop evidence,
- concentration risk analysis for foundation model and cloud AI providers,
- board dashboard covering AI adoption, risk exposure, incidents, exceptions, and overdue remediation.
Back to Writing