The Illusion of the Clean Vendor Assessment
Your SaaS provider has a flawless SOC 2 report. Their ISO 27001 certificate is current. The security questionnaire you sent last quarter came back with every box ticked. You approved the renewal. And then you discover months later, perhaps from a regulator or a news alert that their AI feature has been routing your customer data through a foundation model provider you never assessed, on infrastructure you never reviewed, under data retention terms you never negotiated .
This is the fourth-party problem. It is not a hypothetical future risk. It is operating in your environment right now, whether or not your vendor risk register acknowledges it.
The core structural challenge is straightforward: your AI vendors increasingly depend on sub-processors cloud hosts, model inference providers, data annotation services that sit entirely outside your contractual visibility . You signed an agreement with a company you chose. Your data is flowing through companies you did not.
Why AI Makes Third Party Risk Structural, Not Incidental
Traditional third-party risk assumed a stable vendor relationship: you contract a provider, assess them annually, and monitor for material changes. Fourth-party dependencies existed, but they moved slowly and appeared in audit reports.
AI has broken that cadence. A vendor can integrate a new foundation model through a product update without triggering a procurement review or contract amendment. A SaaS tool’s new AI assistant may route your prompts containing customer data, internal documents, or proprietary code through a model provider whose terms of service permit training on submitted data. Your vendor relationship looks unchanged. The data flows have not.
The LiteLLM compromise in March 2026 illustrated how deep this exposure runs. Attackers uploaded malicious versions of the open-source package versions 1.82.7 and 1.82.8 to PyPI after compromising the build process through a Trivy CI/CD workflow . The malicious code executed a hidden payload on import, stealing SSH keys, cloud credentials, Kubernetes secrets, and AI-provider API keys . Version 1.82.8 went further, installing a .pth file that triggered the payload on any Python startup, even if LiteLLM was never explicitly used . LiteLLM, which helps developers route requests across multiple LLM providers, had over 95 million monthly downloads at the time . A company might never contract with LiteLLM directly but if their vendor’s vendor used it, exposure could materialize several steps beyond their direct relationship.
This is concentration risk disguised as vendor diversity. When forty “independent” suppliers all depend on the same model provider or cloud inference platform, you do not have forty risks. You have one multiplied forty times.
The NIST RMF Gap and What It Actually Requires
The NIST AI Risk Management Framework’s Map function asks organizations to understand their AI context, capabilities, and risks . The Generative AI Profile (NIST AI 600-1) explicitly recommends supplier vetting, SBOM/AIBOM requirements, and dynamic monitoring for third-party GenAI risks, including fourth-party components .
What the framework does not do is prescribe the operational mechanics. Map outcomes are voluntary and high level. Organizations can satisfy the letter of the Map function while leaving fourth-party dependencies entirely unmapped .
The practical implication: you cannot rely on framework compliance as evidence of fourth-party governance. You need specific, operational controls that frameworks inform but do not replace.
What Every AI-Vendor Review Must Ask
The annual questionnaire, a document that captures a vendor’s posture on the day it was completed, is structurally incapable of tracking AI dependencies that change between assessment cycles . Supplemental diligence must be continuous and specific.
At minimum, every AI-vendor review should demand:
Which foundation model providers or sub-processors process our data? Vendors should disclose the full chain model provider, cloud inference host, data annotation services and commit to advance notification of material changes .
Is our data used to train or fine tune models? This is not a privacy policy question. It is a contract negotiation. Without an express model training opt-out, your confidential information can end up embedded in a model that serves your competitors .
How do you govern your own AI? Frameworks, human oversight, audit trails, and model change notification procedures are legitimate due-diligence questions. A vendor that cannot describe its AI governance cannot be meaningfully assessed .
Can we opt out of AI features or data use? Not every AI feature is material to the service you purchased. The ability to disable data flows you have not assessed is a control, not a preference .
What is your continuity plan if a model provider changes terms or discontinues service? Critical AI services that depend on a single provider’s availability, pricing, or policies create operational risk that belongs in your vendor assessment .
From Annual to Continuous: A Different Operating Model
Point-in-time assessments are not merely insufficient. They are the wrong instrument for the risk profile . A vendor’s AI posture can change with a product update. A sub-processor relationship can form between quarterly reviews. A model provider’s terms can shift without your vendor’s involvement.
Continuous monitoring means different things at different maturity levels. At baseline, it means tracking external risk signals for critical vendors and establishing notification requirements for material AI changes. At maturity, it means network level detection of AI tool usage, vendor-provided attestations of sub-processor changes, and automated monitoring of model behavior for silent updates .
The evidence trail matters as much as the monitoring. Regulators from the SEC’s AI-related comment letters to the EU AI Act’s conformity assessment deadlines are asking for documentation of AI supply chain oversight . “We assess our vendors annually” is no longer a defensible answer when the vendor’s AI capabilities change weekly.
What Comes Next
Fourth-party risk is not a problem to be solved once. It is a condition to be governed continuously. The organizations that manage it well will not be those that adopt AI fastest, but those that maintain visibility into the dependencies AI creates .
The starting point is inventory: every AI tool, every embedded AI feature, every model provider behind every vendor. The operating principle is skepticism: trust the contract, verify the data flows.
Reader question: When was the last time you asked a vendor which foundation model provider processes your data and received an answer specific enough to act on?