AI Vendor Breach Response: When Your LLM Provider Is Hit

Your LLM provider, AI coding tool or AI-powered SaaS vendor has announced a breach, and you need to work out what of yours it held, what an attacker can now do with it and who you must tell. AI vendors concentrate three things that make their incidents different from an ordinary supplier breach: API keys and OAuth tokens that work directly against model providers and your other systems, prompts and conversation logs that often contain personal data, source code and pasted secrets, and integrations that let the vendor act inside your SaaS tenants. This guide covers the response from the moment a vendor notice or news report arrives: how the incident shows up, triage questions, containment by priority, data exposure assessment, contract levers, evidence and notification. It is for third-party risk, security operations, privacy and legal teams. The general supplier incident process is in the Third-Party Incident Response Playbook; this page covers what is specific to AI vendors. Where provider documentation is quoted, providers are listed alphabetically and the order is not a ranking.

Key takeaways

Revoke at the source, not at the middleman. When a tool that stores your provider keys is breached, deleting the key in that tool does nothing; only the model provider can disable it.
Assume what you sent is in the vendor's logs. Prompts, outputs and pasted secrets end up in logs and conversation stores; the 2025 DeepSeek exposure included plaintext chat history and API keys.
Integration tokens reach far beyond the vendor. In the Salesloft Drift breach, OAuth tokens held by a chatbot vendor were used to export data from hundreds of customers' Salesforce tenants.
Know the retention window before you need it. Anthropic and OpenAI both document deletion of API inputs and outputs within 30 days by default, with longer retention for stored objects and policy enforcement, which sets the exposure window you must assess.
Your contract is a response tool. Notification timelines, log access, deletion certificates and cost recovery are much easier to get when they are written in before the incident.

How the incident shows up

Signal	Source	First question
Vendor breach notice by email or status page	The AI vendor	Which of our accounts, workspaces and keys are in scope, and since when?
Unexpected model usage or billing spike	Model provider billing and usage dashboards	Is a key we stored with a third party being used from elsewhere?
Provider blocks or suspends keys or projects	Model provider abuse team	Which application broke, and where else is that key stored?
Bulk exports or unusual API calls from a connected app	SaaS audit logs, CASB, identity provider	Is a vendor's OAuth token being used by someone other than the vendor?
Researcher or press report	News, security blogs, social media	Has the vendor confirmed it, and does it match a service we use?
Downstream partner notice	A supplier that embeds the AI vendor	Did our data reach the AI vendor indirectly, through a fourth party?

The billing signal matters most for AI vendors. In the October 2026 OpenCode Console breach, users reported unauthorised usage billed to their own provider accounts, and the tool's own budget controls did not limit it because the stolen keys worked directly at the providers. See the OpenCode Console Breach 2026 analysis.

Triage questions

What role does the vendor play? Model provider (you call its API), AI application (your staff use it), AI middleman (it stores your provider keys and calls models for you), or AI feature inside a SaaS product (it holds OAuth access to your tenant). The role decides the containment path.
Which credentials does it hold for us? Model provider API keys, OAuth access and refresh tokens to SaaS platforms, cloud credentials, repository tokens, webhook secrets, SSO or SCIM tokens.
What data has it received? Prompts and outputs, uploaded files, retrieval indexes or vector stores built from your documents, fine-tuning data, conversation histories, telemetry.
What retention applies? Default API retention, zero data retention agreements, stored objects such as files and vector stores kept until deleted, and enterprise conversation history.
What can the vendor do inside our environment? Read, write or export through integrations; act through an agent with tools.
What is the confirmed exposure window? Take the vendor's earliest possible access time, not the discovery date, and add margin if the vendor is unsure.
Who in the business uses it? Sanctioned tenants, plus personal or team accounts found through expense data, SSO logs and proxy logs.

Vendor role	Main exposure	Primary containment
Model provider	Prompts, outputs, files, stored application state; your API keys if its key store is affected	Rotate keys at the provider, review usage logs, assess data in retention
AI application used by staff	Conversation history containing personal data, code and pasted secrets	Rotate any secrets ever pasted, assess personal data, suspend accounts
AI middleman storing provider keys	Your model provider keys, used directly against your billing	Revoke keys at each provider, set provider spend limits
AI feature with SaaS integration	OAuth tokens to CRM, email, ticketing or storage	Revoke the connected app and tokens in each SaaS platform, review exports

Containment priorities

Revoke integration tokens in your own platforms. Remove or disable the vendor's connected app and revoke its access and refresh tokens in each SaaS tenant. In the Drift case, Google advised treating any and all authentication tokens stored in or connected to the platform as potentially compromised.
Rotate model provider keys at the provider. Create a replacement key, update every application that uses it, then revoke the old one in the provider's console. Do this for every key the vendor stored, including keys in staging projects. Provider-specific steps are in the AI model provider API keys leak response guide.
Set hard spend limits and alerts at the provider. A middleman's budget does not cap direct use of a stolen key.
Rotate secrets found in data the vendor held. Search your copies of prompts, tickets and CRM records for credentials. After Drift, Cloudflare rotated 104 API tokens found in support case data the attacker could read.
Suspend or restrict use. Pause new data flows to the vendor and block its domains for unsanctioned use until it confirms containment.
Open a formal channel. Request a named incident contact, the indicators of compromise, the exposure window and the list of your affected objects, in writing.

Eradication

You cannot eradicate inside the vendor. Your part is to remove everything the attacker could still use and to get evidence the vendor has closed its side.

Confirm old credentials are dead: test that revoked keys and tokens fail, and watch provider and SaaS logs for attempted use of them, which confirms theft.
Remove residual access: delete stale keys, unused connected apps and service accounts the vendor created; reduce scopes on any you keep.
Delete data you no longer need at the vendor: files, vector stores, conversation history and fine-tuning datasets. OpenAI documents that files and vector stores are retained until deleted, so they stay exposed until someone removes them.
Get the vendor's root cause: how the attacker got in, what was stored and how, whether keys were encrypted, and what has changed. The OpenCode intrusion was in a legacy system being decommissioned, a reminder to ask about retired components.
Check fourth parties: if the vendor used another AI provider or hosting service, confirm whether that party was involved.

Data exposure assessment

This step decides notification, so document it carefully. Start from what the provider documents about retention, then narrow to what your organisation actually sent.

Provider (alphabetical)	Documented default for API data	Exceptions to note
Anthropic	API inputs and outputs deleted from the back end within 30 days of receipt or generation	Longer retention under your control (for example Files API), zero data retention agreements, Usage Policy enforcement (inputs and outputs up to 2 years, classification scores up to 7 years), legal requirements
OpenAI	Abuse monitoring logs retained for up to 30 days; API data not used for training by default	Responses API application state kept 30 days by default; files and vector stores kept until deleted; Zero Data Retention for approved customers on eligible endpoints; longer retention where required by law

Then work through the data classes:

Personal data: which data subjects, how many, which categories (special category, health, financial, children).
Secrets: any credential that was ever in a prompt, file, log or ticket the vendor stored. Treat it as exposed and rotate it.
Source code and intellectual property: repositories indexed by coding tools, documents in retrieval stores.
Derived data: embeddings and vector indexes built from your documents carry their content and should be assessed like the source.
Regulated data: payment card data, health records and government data trigger their own rules.

The DeepSeek exposure illustrates why logs matter: a publicly reachable database held more than a million log entries including plaintext chat history and API keys. See the DeepSeek Database Exposure 2025 analysis and, for vendor due diligence, the DeepSeek and High-Risk AI Vendor Assessment Guide.

Recovery

Decide whether to continue with the vendor. Base it on the vendor's root cause report, the controls it has added and how it communicated. If you exit, follow the Vendor Offboarding and Termination Guide and request deletion certificates.
Reconnect with less access. Narrower OAuth scopes, IP restrictions or connected-app policies, separate keys per tool and environment, and short-lived tokens where supported.
Put a gateway in front. Route model calls through your own gateway so third-party tools never hold raw provider keys and you keep one place to revoke and log.
Recover costs. Request refunds for fraudulent usage from the provider and the vendor; after OpenCode, OpenAI said it was refunding affected API customers.
Update the risk record. Re-tier the vendor and record the incident against its assessment.

Metrics that show readiness: time from vendor notice to all keys and tokens rotated, number of AI vendors holding raw provider keys (target zero), share of AI vendors with a documented notification clause, AI integrations with an inventoried owner and scope, and provider projects with hard spend limits.

Contract levers

Lever	What to ask for	Why it matters for AI vendors
Breach notification	A fixed notice period, named contacts, minimum content (scope, window, data, indicators)	Key abuse costs money by the hour; vague "without undue delay" clauses are slow
Processor assistance	Help with your regulatory notifications and data subject requests	You remain the controller for personal data in prompts
Log and evidence access	Access to logs of your tenant's activity during the window	Only the vendor can show which of your keys and data were touched
Data retention and deletion	Retention limits, zero data retention where available, deletion on request with certification	Shrinks the exposure window before and after an incident
Credential handling	Encryption of stored keys and tokens, rotation and revocation support	Middlemen storing provider keys are high-value targets
Subprocessors	A list of model providers and hosts, notice of changes	Your data may reach a fourth-party AI provider
Cost recovery and termination	Liability for fraudulent usage, termination for cause	Gives you leverage for refunds and exit

Clause wording is covered in the Third-Party Incident Notification Clauses Guide and Vendor contract clauses for credential revocation and breach notice. Map supplier notification to NIST SP 800-53 SR-8 Notification Agreements and SR-6 Supplier Assessments and Reviews, and to NIST CSF 2.0 GV.SC-08.

Evidence to preserve

Vendor communications: every notice, status page update and email, with timestamps.
Provider usage and billing logs: per key and project, from before the earliest possible access time to after rotation.
SaaS audit logs: connected app activity, exports and API calls by the vendor's integration identity.
Your inventory at the time: which keys, tokens and scopes the vendor held, and who approved them.
Rotation records: when each credential was revoked and replaced, and by whom.
Exposure assessment: the data classes, volumes and reasoning behind each notification decision.

Notification triggers

Trigger	Rule	Note
Personal data you control was in the breached vendor's systems	GDPR Article 33: notify the supervisory authority within 72 hours of becoming aware, unless unlikely to result in risk; Article 34: inform individuals where risk is high	The clock starts when you are aware, usually on the vendor's notice; document why you did or did not notify
US residents' personal information	State breach notification laws	See the Breach Notification Laws by Country Guide
Your customers' data passed to the AI vendor	Your customer contracts and DPAs	You may be the processor who must tell your controller
Health, payment or sector-regulated data	Sector rules such as HIPAA or PCI DSS	Separate timelines and recipients
Material impact on a listed company	Securities disclosure rules where they apply	Legal decides materiality

Lessons from incidents

OpenCode Console, October 2026: an intruder in a legacy system exposed stored OpenAI, Anthropic and Google keys for 1.4% of Console users, by OpenCode's account; abuse was billed to customers' own provider accounts. Revoke at the provider and set provider-level limits.
Salesloft Drift, August 2025: tokens stored in a chatbot vendor's cloud environment were used to export data from hundreds of Salesforce tenants, and the attacker searched the data for secrets. Integration tokens are high-value non-human identities. See the Salesloft Drift Breach 2025.
DeepSeek, January 2025: an unauthenticated database exposed chat logs and API keys. Assume prompts and keys reach vendor logs and scope keys accordingly.

Practitioner checklist

Keep an inventory of AI vendors with their role, the keys and tokens they hold, scopes, data sent and owner.
Never give third-party tools raw provider keys where a gateway or per-tool key is possible.
Set hard spend limits and usage alerts on every model provider project.
Document each provider's retention defaults and any zero data retention agreement.
Pre-write rotation runbooks for each AI integration so revocation takes minutes.
Put notification periods, log access, deletion certification and cost recovery into AI vendor contracts.
Keep secrets out of prompts, tickets and CRM records with automated scanning and redaction.
Run a tabletop exercise on an AI vendor breach at least once a year.

AI Vendor Breach Response: What to Do When Your LLM Provider or AI Tool Is Compromised