Third-party AI risk now enters through models, APIs, tools and embedded features

Introduction

A SaaS platform passes vendor review in January.

Six months later, an administrator enables an AI assistant inside the same product. The feature calls an external model, retrieves information from another system and can invoke a partner-built connector.

Procurement has not onboarded a new software vendor.

The runtime dependency chain has changed anyway.

That is the problem with third-party AI risk if it is managed only through the supplier register.

An enterprise may contract with one platform while depending at runtime on a foundation-model provider, an inference API, a connector publisher, an external data source and several software components that were not visible in the original vendor assessment.

NIST’s Generative AI Profile recognizes this explicitly. Its acquisition guidance tells organizations to address solutions that rely on embedded generative AI, as well as modeling libraries, tools and APIs, fine-tuned models and embedded tools.

The practical unit of third-party AI governance is therefore becoming smaller than the vendor and larger than the model.

It is the dependency path that makes the AI capability work.

At a glance

• A single enterprise application can depend on several AI suppliers even when procurement records show only one primary vendor.
• Model selection can change data handling, contractual responsibility and security assumptions without changing the surrounding platform.
• Tools and connectors introduce third-party authority paths, not merely third-party software dependencies.
• Embedded AI features can materially alter an existing supplier relationship without creating a conventional new-vendor event.
• Third-party AI governance works better when enterprises can trace runtime dependencies, ownership, change and contingency rather than rely on one static vendor score.

The supplier register no longer describes the full AI system

Traditional third-party risk management has a natural organizing object: the supplier.

A business contracts with a SaaS provider, cloud company, consultancy or software vendor. Procurement records the relationship, legal reviews the terms, security evaluates the supplier and periodic reassessment follows.

AI does not remove that structure. It weakens the assumption that one contracted vendor corresponds to one meaningful risk boundary.

NIST’s AI Risk Management Framework requires organizations to address risks arising from third-party software, data and other supply-chain relationships. Its Playbook notes that third-party resources can improve scalability while increasing complexity and opacity and recommends documenting the technologies, personnel and resources on which the system relies.

Generative AI makes that opacity easier to encounter inside ordinary enterprise products. A customer may buy one service but use a capability whose output depends on another company’s model. That model may sit behind the platform provider’s API or be selectable by the customer, while a third-party tool later carries the result into another business system.

The organization still needs the vendor relationship.

It also needs to understand the dependencies hidden behind it.

The model provider may not be the platform provider

One of the clearest examples is model choice inside a larger enterprise platform.

Microsoft’s current documentation distinguishes several ways AI functionality can be supplied inside Microsoft Online Services. Some models are hosted and operated by Microsoft. Others are supplied by third parties acting as Microsoft subprocessors. A third category involves independent processors operating under their own data-processing and enterprise terms.

Those differences can affect where data is processed, which contractual safeguards apply, who carries specific processing responsibilities and which administrative controls govern access to the provider.

Microsoft also allows organizations to assign access to particular third-party AI providers across Copilot and Copilot Studio experiences.

A similar dependency appears in cloud-model platforms.

AWS disclosed in July 2026 that the introduction of models requiring data sharing with third-party providers created a need for organizations to enforce model-compatible retention policies centrally. The security control therefore depends partly on which model is selected, not simply on whether the workload runs in Amazon Bedrock.

The enterprise may not have switched cloud providers or purchased another application. A model choice inside the approved platform has changed the data path and the applicable risk assumptions.

A model is both a technical component and an upstream dependency

Third-party model risk is sometimes reduced to model quality: whether the system hallucinates, whether bias testing was adequate or whether a benchmark result meets the business requirement.

Those questions matter, but supplier dependence extends beyond model performance.

A third-party model can be deprecated or replaced. Its version, acceptable-use terms, hosting arrangement, retention conditions, safety mechanisms or regional availability can change. An open model can introduce provenance or integrity concerns before it ever reaches production.

OWASP’s 2025 LLM supply-chain guidance includes vulnerable or outdated pre-trained models, weak model provenance, third-party components and changing terms or privacy policies among the risks enterprises need to manage. It recommends maintaining inventories, using verifiable model sources and regularly reviewing supplier security, access and terms.

Google’s Model Garden documentation provides a useful practical illustration. Featured third-party model checkpoints are scanned for authenticity, while Hugging Face models are scanned for risks including malware, unsafe serialization and secrets. Google still tells customers to perform their own review when models are marked suspicious.

The marketplace, cloud platform or model catalog can reduce parts of the risk without making the upstream model cease to be a dependency.

Tools turn supplier risk into an action path

Third-party AI risk becomes more consequential when external components can influence what the system does, not merely what it generates.

A connector may retrieve customer information, create a ticket or, where write capabilities are available, update records in the connected system. The security meaning of the dependency changes when a third-party component can participate in actions rather than only provide software or content.

Microsoft’s federated Copilot connectors illustrate the direction. The connectors use Model Context Protocol to access external systems in real time and can be published by Microsoft or submitted by partners. They operate using the user’s identity and permissions. Microsoft began rolling out support for write actions in early October 2026; as those capabilities become available, connectors with corresponding tools can create, update or delete external-system data.

From a third-party-risk perspective, the important point is not that connectors are inherently unsafe.

The supplier boundary has acquired an execution path.

A partner-produced connector can sit between an enterprise AI capability and a business system in which state can change.

MITRE’s 2026 OpenClaw investigation makes the security consequence more concrete. It identifies AI supply-chain compromise scenarios in which third-party skills can operate with agent privileges and interact with persistent memory, while upstream model dependencies create another supply-chain layer.

A useful third-party review therefore needs to know both who supplied the component and what authority becomes reachable through it.

Embedded AI can change the risk profile without creating a procurement event

The hardest third-party AI dependencies may be the ones introduced inside software the enterprise already owns.

NIST’s Generative AI Profile explicitly tells procurement and governance teams to account for solutions that may rely on embedded GAI technologies and to adjust policies across modeling libraries, tools, APIs and embedded tools.

Enterprise AI adoption does not always arrive through a project labelled “AI.” It may arrive as a release-note item: a model selector appears in an office application, a support platform adds an assistant, a CRM begins generating replies or an analytics product introduces natural-language querying.

The commercial relationship can look continuous while the underlying technology chain changes.

Microsoft’s current Online Services documentation is unusually explicit about this. AI functionality inside its services may be provided by Microsoft or third parties, and Microsoft distinguishes third-party providers according to whether they operate as subprocessors or independent processors. Its subprocessor documentation also provides mechanisms for customers to track changes to the approved AI-subprocessor list.

For third-party governance, an existing vendor cannot automatically be treated as an unchanged vendor simply because the company name on the contract has not changed.

The relevant question is whether the service dependency, data path or authority surface has changed underneath that relationship.

The same supplier can expose several different risk boundaries

A single platform can contain several materially different AI dependency patterns at once.

One model might operate inside the platform provider’s own trust boundary while another is supplied through a subprocessor arrangement. A third can belong to an independent processor with separate contractual terms. The same environment may also include a custom connector that acts under an employee’s permissions or an open model sourced outside the platform’s managed catalog.

Those components can coexist inside one enterprise application while presenting different data, security and contractual relationships.

This makes a single organization-wide score such as “Vendor A: medium risk” increasingly uninformative for AI use. It may describe the supplier reasonably well while saying much less about the dependency path supporting a particular production capability.

NIST’s Generative AI Profile recommends inventorying underlying foundation models, their versions and access modes. It also tells organizations to inventory third parties with access to organizational content and update vendor assessments for embedded AI, APIs, tools and model dependencies.

The implication is not that enterprises need a new risk object for every API call.

They need enough architectural resolution to know which third party is involved in the capability that matters.

Ownership now crosses procurement, security and platform operations

The supplier contract still belongs somewhere.

The runtime dependency often belongs somewhere else.

Procurement may negotiate commercial terms, service levels and change-notification rights while privacy teams examine processor relationships and secondary data use. Security needs visibility into where information travels and what privileges external components receive. Platform teams choose models, endpoints and connectors, while application owners decide which business process actually depends on them.

Each team can therefore hold an accurate piece of the picture without any one of them holding the complete dependency.

The operating problem is therefore one of shared ownership without fragmented accountability.

NIST’s Generative AI Profile places third-party AI risk across governance, procurement, operation and monitoring rather than treating it as an acquisition-only problem. It calls for supplier assessments, contracts, inventories, contingency planning and ongoing management of third-party AI resources.

The important ownership question is not which function “owns AI vendor risk” in the abstract.

It is who notices when a provider, model, tool or processing relationship changes in a way that alters the system the business is relying on.

Third-party AI risk does not stop after onboarding

Supplier review is usually strongest at the moment of purchase.

AI dependencies can keep changing afterward.

Model versions change. New providers appear inside platforms. Existing features gain tools. Connectors gain additional actions. Terms, retention options and subprocessor relationships evolve. A supplier may retire an API or introduce a new upstream dependency.

NIST’s AI RMF Playbook says risks and benefits from third-party resources should be regularly monitored, with controls applied and documented.

OWASP likewise recommends regular review of supplier security, access, model maintenance and terms rather than treating the original assessment as durable evidence.

This is not the same problem as continuous control assurance across the entire AI estate.

The narrower third-party question is whether the dependency supplied by someone else remains the dependency the enterprise originally assessed.

A model change, new subprocessor or newly write-capable connector can be material even when the application itself has not been redesigned.

Concentration can hide behind apparent vendor diversity

An organization may believe it has diversified suppliers because different departments use different SaaS products.

Several of those products may still rely on the same upstream foundation model or AI infrastructure.

NIST’s Generative AI Profile notes that the difficulty and cost of training foundation models encourages extensive reuse of a comparatively limited number of models, while generative AI is increasingly integrated into other services and devices. The result can make downstream attribution and accountability harder when something goes wrong.

That creates a form of concentration risk that a supplier count does not show.

Three applications from three vendors may all depend on one model provider. A disruption, contractual change or policy shift at that upstream provider can therefore affect several apparently separate business services at once.

The same issue applies to common APIs, marketplaces, identity services and connector ecosystems.

Diversification at the contract layer does not necessarily mean diversification at the dependency layer.

Third-party contingency starts with knowing what can be substituted

NIST’s Generative AI Profile recommends documenting value-chain dependencies, identifying fallbacks and planning for third-party incidents. NIST’s AI RMF also requires contingency processes for failures or incidents involving high-risk third-party AI systems.

Substitution is harder than pointing an application at another endpoint.

A replacement model may behave differently, support a different context window or apply different data-processing terms. Tool-calling behavior, latency, regional support and safety controls may also vary. The substitute can therefore preserve availability while changing some of the assumptions that made the original dependency acceptable.

Manual fallback has its own consequences. A process that has gradually come to depend on AI assistance or automation may remain technically operable without the supplier but lose the throughput, response time or control characteristics on which the business now relies.

Third-party AI resilience therefore depends on more than having a nominal alternative.

The enterprise needs to know whether the fallback preserves the controls and business assumptions attached to the original dependency.

FAQs

What is third-party AI risk?

Third-party AI risk is the risk introduced by external organizations, models, data, software, APIs, tools or services that contribute to an enterprise AI capability. It includes conventional supplier risk as well as dependencies that sit behind a primary platform or application.

Why is third-party AI risk different from normal vendor risk?

AI systems often combine components from several organizations. A company may contract with one platform while relying on another provider’s model, a partner connector and external data. The technical dependency chain can therefore be broader than the commercial supplier relationship.

Are third-party models a supply-chain risk?

Yes. NIST and OWASP both treat external models as part of the AI value or supply chain. Risks can include provenance, tampering, model retirement, changing terms, security weaknesses and differences between the context in which a model was evaluated and the context in which it is later used.

Why do AI tools and connectors matter to vendor risk?

Tools and connectors can give an AI system access to external data or the ability to change another system. A third-party component may therefore affect not only model output but also the authority available to the AI application.

How should enterprises track embedded AI from existing vendors?

Existing vendor records should be supplemented with information about the AI capability itself: underlying model provider, access mode, subprocessors where relevant, important data flows, external tools and material changes that could alter the assessed risk.

Third-party AI risk follows the dependency, not the logo

The vendor on the contract still matters.

It simply no longer tells the whole story.

An enterprise AI capability may depend on a model owned by one company, an API operated by another, a connector supplied by a partner and an AI feature embedded inside software that procurement approved years earlier.

Those dependencies can change the data path, the authority available to the system, the contractual relationship and the consequences of failure.

The governance response does not need to turn every AI application into an endless supplier diagram. It does need to make one architectural fact visible:

Third-party AI risk follows the components and relationships that actually make the system work—not only the company whose name appears on the purchase order.