Agentic AI Supply Risk: When the Supplier Does Not Own the Model
Background
Companies negotiating with agentic AI providers will often hear that a provider cannot accept a requested commitment because it does not own the underlying models. That may fairly describe the agentic AI provider’s contract with its model providers, but it does not settle how to address the risk under the contract with the company. This issue matters, particularly when a model shapes what AI agents do inside the business.
Companies will start with the familiar principle that a provider remains responsible for the subcontractors it selects. The model provider is a subcontractor, much as cloud providers were when the providers that depended on them argued that an upstream cloud outage was not their problem. If the provider cannot obtain matching protection from upstream providers, it may price the exposure or seek a narrow exception. Blanket disclaimers, however, shift the entirety of the risk to the company.
Companies have long been willing to share some of the risks of a provider’s delivery model, so the question is not whether the provider controls the model but which commitments it can reasonably make. A company’s request that the provider guarantee model behavior may fairly be met with a narrower promise, backed by testing, oversight, and remedies. Other requested commitments, by contrast, concern areas the provider does control: how company data is protected, what the AI agents are permitted to do, and what record the AI agents leave behind. Where risk is left with the company, the contract should say so and pair that allocation with agreed safeguards and exit rights.
How This Was Addressed With Cloud
Traditional outsourcing agreements required both visibility and accountability for subcontracting. A company might contract for a list of material subcontractors, advance notice of changes, and consent rights. Those rights supported diligence but did not relieve the provider of responsibility when a subcontractor failed. The provider selected its delivery model, managed the underlying relationships, and charged for the combined service. The company did not have to pursue an unfamiliar party without privity of contract.
The migration to the cloud introduced a new angle to this discussion. Providers sometimes argued that a failure at a major cloud provider was closer to a utility outage than a subcontractor breach. Their proposed terms might exclude cloud downtime from service levels, place it within force majeure, or cap the company’s remedy at whatever the provider recovered upstream.
Companies pushed back because the provider had privity with the cloud provider, had chosen the cloud platform, and had built its offering around it. Providers addressed the exposure through redundancy, recovery planning, insurance, or price, and eventually settled on a shared responsibility model, but that adjustment took time. Early adoption was often limited to workloads suited to the available controls. As cloud architecture, security, monitoring, and contractual commitments matured, broader use became possible and companies moved more critical functions into the cloud. Contracts remained focused on the service sold to the company, even without a matching upstream remedy for the provider.
Why Agentic AI Reopens the Debate
Agentic AI providers that depend on upstream models are now making a version of the same argument. They point out that they buy model access on the model provider’s standard enterprise terms and have no realistic ability to negotiate them. They argue that they cannot say when a model will be retuned, restricted, or retired, and often learn of a change on the same notice everyone else receives. They claim they had no part in how the model was built, cannot see what it was trained on, and cannot test every result it may produce or explain why it reached a particular one. The central issue is that a promise to the company can create exposure with no matching upstream remedy for the provider.
The difference with AI agreements, however, is in the nature of the exposure. Cloud dependency was largely about availability and security, and both of those problems were engineered around. That helped providers become comfortable standing behind uptime and security commitments, even without controlling the cloud infrastructure. Core product functionality generally remained with the provider. This is not the case with model dependency in agentic AI, where the third-party model affects not just the availability of the product but also the core functionality the company is buying.
Consider an AI agent that reviews a customer complaint, checks the account, chooses a response, issues a credit, and updates the record. If the model behind it is retuned, the service stays up but the judgment behind those steps may change, potentially in ways that harm the company’s business. This risk cuts in both directions. It explains why a provider is reluctant to make commitments around a model’s behavior the way it ultimately got comfortable making commitments around uptime and data security. It is also why a blanket disclaimer for the model provider is unacceptable to the company, leaving an accountability gap the company has to fill.
Engineering and Contracting Around Model Dependency Risk
The cloud experience suggests that model dependency risk will not be mitigated through contractual risk allocation alone. Companies and providers first need to determine which risks can be reduced through architecture, access controls, monitoring, human review, and alternative processes. They can then define the data, systems, decisions, and transactions the AI agent may handle within that control environment. The contract should assign responsibility for building, maintaining, testing, and changing the protections, establish what happens when they fail, and allocate the residual risk.
For a material deployment, the company may try to address that residual risk by obtaining direct rights from the model provider, particularly where only the model provider can supply needed information, protection, or support, such as around data-related commitments, output restrictions and indemnities, and audit access. Those rights may be negotiated directly with the model provider and expressly cover the company’s deployment. However, those rights would be intended to supplement rather than replace the agentic AI provider’s responsibility, and bespoke negotiation with a model provider may not always be feasible.
Against that background, the following four risk areas illustrate how engineering and contracting can be used together to mitigate risk when an agentic AI service depends on an upstream model.
1. Performance and Continuity
Risk: An AI agent may send messages, change records, or move money, and could produce inaccurate, biased, unsafe, or otherwise unsuitable results. The consequences may become more serious when the AI agent can act without another control before the resulting business action. In addition, the model provider may retune, restrict, or retire the model or change its safety controls at any time, with limited notice.
Engineering: The agentic AI provider can build appropriate guardrails into its solution and the company can build them into its systems and processes. Guardrails may include dedicated credentials, system and transaction limits, approvals above defined thresholds, concurrence by another agent for sensitive actions, rate limits, monitoring, sampling, a kill switch, and a manual fallback. The appropriate guardrails reflect the consequences of error. An AI agent that recommends a refund may require different controls from one that issues the refund. For model changes, testing could be engineered to assess pre- and post-change and otherwise qualify a substitute model in advance.
Contracting: The contract can identify (or allow the company to designate from time to time) the systems the AI agent may access, the transactions it may complete, the points at which a person must approve or take over, and who is responsible for implementing and maintaining those guardrails. If the AI agent acts outside agreed guardrails, including through autonomous conduct, the company would have contractual remedies, subject to exceptions for conduct caused by the company’s own instructions or configurations.
For decisions within those guardrails, the contract issue then becomes how to obtain commitments on agentic action without an exclusion for model variability, which may cause providers to resist guaranteeing that every agentic decision will be optimal. What the provider is more likely to contract for is that its AI agent will follow the agreed workflow and be measured against defined criteria, including how often it achieves the desired outcome and what happens when it hits an exception or needs a person to step in.
For model changes, the contract could require the provider to give prompt notice, explain the likely effect, and, to the extent agreed under the contract, test and otherwise qualify substitute models and propose solutions. Pending approval, the company may have the right to reduce the AI agent’s authority or suspend the affected function. If agreed criteria cannot be met, the contract could provide for termination, a refund, and assistance in moving the work elsewhere.
2. Data and Intellectual Property Protection
Risk: Prompts, uploaded data and documents, outputs, and logs may pass to, or be held by, an upstream model provider. That provider may retain or use them for training, benchmarking, or product improvement under terms with the agentic AI provider that the company did not negotiate. In addition, those terms may restrict how outputs can be used and may offer incomplete protection against claims that a model or its output infringes a third party’s rights.
Engineering: The parties can minimize data before submission to the model provider, redact or mask sensitive fields, and otherwise keep particularly sensitive information out of the model path. Where appropriate and available, they can use a private deployment in a company-controlled environment. Where the model provider will not accept desired restrictions on its use of company data and outputs, the agentic AI provider may need to avoid building certain business functions into its solution, which may limit use cases.
Contracting: If engineering measures are insufficient, the company could require the provider to stand behind—and secure from the model provider—data use, retention, deletion, and training restrictions. The contract can limit the right to use data and IP to the contracted purpose, include that limit in the “flow down” provision, and reference it in the “no conflict” warranties. Also, any conflicting terms in the model provider’s terms should surface early in the sourcing process through due diligence, and certainly before signing. Indemnities for output infringement claims, by contrast, are use-case dependent—important where agent output is used as business content, and far less so where outputs are internal, transient, or merely operational.
3. Compliance and Explainability
Risk: The company may need information about testing, data provenance, model limitations, bias, or decision processes that the agentic AI provider cannot produce because it does not provide the model. The provider’s inability to explain the model or produce such documents does not eliminate the company’s regulatory or downstream-contractual obligations for the resulting process.
Engineering: The company could limit the AI agent’s role, using it for recommendations rather than final determinations. Human review could be maintained and records preserved on the company side to show how decisions were made by humans. The company or the AI provider could implement ongoing monitoring to verify compliance with obligations despite the lack of data from the model provider.
Contracting: The contract could make the provider responsible for complying with the laws governing its own service and for giving the company what it needs to meet its compliance obligations, either as a general obligation or through specific steps. Depending on the use case, the provider may be required to capture the task assigned, relevant data or instructions used, the approvals obtained, the action taken, the outcome, and any exception that changed the normal workflow, so the company can operate, evaluate, and improve the process.
4. Lock-in and Portability
Risk: The workflow may be coupled to one model and its model-specific APIs, prompts, and configurations. Replacing it may require redesign and may change business results even if the replacement appears technically compatible.
Engineering: Adding a model-abstraction or orchestration layer may keep the AI agent and workflow model-agnostic. Similarly, the parties can maintain workflow rules and configurations separate from the model, test alternative models periodically, and preserve a tested alternative model or other fallback for critical functions.
Contracting: While the engineered mitigations may alleviate reliance on any particular model, the company would still be dependent on the provider. The contract could require notice of a model change or withdrawal that could disrupt the service and, on any exit or migration, require transition assistance that may include continued access for a reasonable transition period, export of the workflow rules, records, operating materials, and other information needed to move the work.
Takeaways
A provider’s lack of ownership over an upstream model does not itself determine who should carry the resulting risk. Nor does it mean that companies must choose between accepting the risk as presented and declining to use agentic AI. The cloud market expanded after companies and providers engineered architectures, security practices, operating controls, recovery procedures, and commercial arrangements that made particular workloads acceptable. Contracts then assigned responsibility for those measures and allocated the risk that remained after engineering.
Agentic AI may develop in much the same way. Companies and providers can determine what model dependency risks can be addressed through engineering and contracting. The near-term result may be narrower commitments and use cases, less authority for AI agents, additional provider pricing or insurance, contractual remedies for failure, or exit rights. As the engineering and contracting solutions prove effective, companies will move from recommendations to actions, raise transaction thresholds, and bring more consequential processes into the service.
As a result, it will be technical and legal teams, working together, that will allow companies and providers to maximize value over the agentic AI supply chain.
