Quick answerA security breach at your model provider, while the provider keeps operating, needs a different incident response than either an internal breach or a vendor going out of business. Establish exactly what data your provider can see and log about your conversations before an incident happens, not during one, so you can determine your actual exposure fast, then run customer communication on a track that is honest about the shared responsibility without either overstating your own fault or hiding behind the vendor's breach disclosure.
A different incident category than the vendor disappearing
What happens if your AI agent vendor gets acquired or shuts down covers business continuity risk: the vendor stops being available to you. A provider security breach is the opposite shape of problem, the vendor is still fully operational, your integration still works, but their systems have been compromised in a way that may expose data that passed through their infrastructure. You have no continuity gap to manage, you have an exposure and disclosure problem, and conflating the two response playbooks means reaching for the wrong first move, like starting a vendor migration when the actual priority is exposure assessment.
Knowing your exposure requires knowing this before the breach happens
The single biggest determinant of how fast you can respond is whether you already know, in writing, exactly what your model provider retains, logs, and can access from your conversation traffic: prompt content, model outputs, metadata, retention windows, whether data is used to improve their models. If that mapping does not exist before an incident, the first 48 hours get spent reconstructing it instead of acting on it. This is the same discipline as architecting multi-tenant data isolation so one customer's data never leaks into another's, applied to the vendor relationship itself rather than your own database.
Deciding what triggers your own incident response, not just theirs
A provider's breach disclosure will describe their exposure on their terms and their timeline, which may not match what your customers need to know or when they need to know it. Define in advance the trigger for standing up your own incident response separately from waiting on the provider's official notice, based on the categories of data your mapping shows could have been exposed, not on the provider's own severity rating. The threshold logic here overlaps with what should trigger a company to build a dedicated AI incident response runbook in the first place, extended specifically to a third-party-originated event.
Communicating honestly about shared responsibility
Customers generally do not distinguish between "our systems were breached" and "our AI vendor's systems were breached" in terms of how much they care, they trusted the company with their data regardless of which system held it. Do not lead customer communication with "this wasn't our fault," even when it is technically accurate; lead with what data may have been exposed and what the company is doing about it, and address the vendor relationship as context, not as a defense. This mirrors the tone guidance in what a company should communicate to customers after an AI agent has a production incident.
FAQ
Should the contract with the model provider specify breach notification timelines? Yes, and this should be negotiated before signing, not discovered during an actual incident. A vendor contract silent on breach notification timing leaves you dependent entirely on their own disclosure schedule.
Do we need to notify customers if the provider says no customer-identifying data was exposed? Verify that claim against your own exposure mapping rather than taking the provider's assessment at face value, since their definition of customer-identifying data may not match what you promised customers you would protect.
How is this different from a prompt injection or jailbreak incident? A jailbreak is a misuse of the agent's intended function through crafted input. A provider breach is a compromise of the infrastructure behind the model itself, independent of anything a customer or attacker did through the conversation interface.