Overview

AI vulnerability ownership follows control over the affected state and the ability to reduce risk, not a single organizational label. A model provider may control shared behavior, an application vendor may control prompts, permissions, retrieval, or customer data, and a deployer may control configuration and adoption. Finders, reporters, and coordinators add distinct disclosure roles. The chapter explains why receiving vendors must validate, contain, forward, or route credible reports even when they cannot repair the underlying model, and why vertical and horizontal supply chains require preserved evidence, synchronized timing, safe testing boundaries, and clear communication to deployers.

Learning outcomes

The party that can contain immediate exposure may differ from the party that controls the underlying AI behavior.
A receiving vendor should not force a researcher to solve ownership before reporting; it should validate, relay evidence, or identify a workable route.
Supply-chain disclosure succeeds only when context, testing limits, ownership, timing, and deployment actions survive handoffs.

Keywords

AIownershipmodel providerdeployersupply chaincoordinator

Who Owns an AI Vulnerability?

This chapter examines ownership when an AI vulnerability crosses the boundaries of a model provider, an application vendor, a deployer, and the people who report or coordinate the issue. The practical question is not who deserves blame. It is who controls the relevant state, who can reduce the risk, and how a disclosure policy keeps the report moving when those roles belong to different organizations. That map is necessary for deciding whether an AI scope is genuinely usable.

An AI product is often presented as one service even when its behavior depends on several layers. A model provider may control weights, training, or safety behavior. An application vendor may control prompts, retrieval, tool permissions, and customer data. A deployer may configure the service and decide which users or records it can reach. A finder may identify the condition, while a coordinator relays information among parties. The organization receiving a report may therefore be able to contain the effect without being able to repair its underlying cause.

Roles follow control, not organizational labels

The CERT guide distinguishes five central CVD roles: finder, reporter, vendor, deployer, and coordinator. The finder identifies a potential vulnerability. The reporter originates the message that informs a vendor or coordinator; often the finder and reporter are the same person, but an internal security team, employer, or coordinator may communicate on the finder’s behalf. The vendor created or maintains the vulnerable product. The deployer operates systems that depend on the product and must apply a fix or mitigation. The coordinator facilitates communication and response when the case is complicated or involves several parties.

These roles can overlap. A researcher may be both finder and reporter. A cloud provider may develop and operate its own service, combining vendor and deployer responsibilities. A vendor may coordinate downstream updates through its product-security team. Keeping the roles distinct is still useful because the decisions are different. The finder needs to establish the behavior. The reporter needs a safe and intelligible channel. The vendor needs to validate and change the product. The deployer needs to identify affected instances and apply the response. The coordinator needs to preserve information while helping parties synchronize.

The distinction matters for AI application vendors. Suppose an application sends user requests to a foundation model and then uses the response to retrieve documents or call tools. The application vendor may control the permissions and the way output is handled, while the model provider controls part of the model behavior or service interface. A report about prompt injection might therefore reveal an application authorization problem, a model limitation, or an interaction between the two. The application vendor cannot assume that routing every concern upstream is sufficient. It may be the only party able to prevent the model from reaching private data or taking an external action.

The reverse is also possible. A model provider may need to change a model or shared safeguard to address a behavior that appears in many downstream applications.

Published by DeepMox

FAQ

What is the difference between a finder, vendor, deployer, and coordinator?

The finder discovers the condition, the vendor maintains the product, the deployer applies the response, and the coordinator synchronizes communication; a reporter may communicate on the finder's behalf.

Why can an application vendor need to act on a model-provider issue?

Because it may control the permissions, data, interface, or deployment that creates immediate exposure even when the provider controls shared model behavior.

What should happen when an AI report crosses a supply chain?

The receiving party should preserve evidence and testing limits, identify who owns each layer, inform relevant deployers, and coordinate timing rather than treating the case as a single local bug.

Previous9 minFrom AI Vulnerability Report to Remediation

Next8 minRedefining AI Vulnerability Scope