Incident Response Obligations When an AI Vendor Has a Breach

A breach at a traditional software vendor exposes a data store. A breach at a computer-use AI vendor exposes PHI, credential vaults, session tokens, and an agent's full action history at the same moment, and that difference changes what a covered entity must do in the hours and weeks that follow. This piece maps what a practice owes patients and regulators when the failure originates inside a vendor's infrastructure, and why the AI context makes each obligation harder to execute than it would be in a conventional vendor incident.

Why an AI vendor breach lands differently

Picture a computer-use agent mid-shift: logged into a payer portal to check a claim status, holding an active session token to the EHR, carrying a vaulted set of credentials it uses every morning to run eligibility checks before staff arrive. That agent is an active operator, and everything it holds at the moment of compromise becomes exposed at once. A traditional vendor incident usually involves a discrete, bounded data store, like a billing file or a patient roster, so you can define the scope of exposure with some precision. An AI agent breach does not offer that boundary. Three layers go out the door simultaneously: the PHI the agent retrieved from the EHR, the session tokens and payer credentials it had stored to keep working without re-authenticating, and the audit trail recording every action it took on the practice's behalf. None of these layers is incidental to the others. They are the agent's entire operating footprint, and a breach at the vendor touches all of them in the same instant.

Risk concentrates across vendors, which compounds the exposure. A single AI vendor automates prior authorization for hundreds of practices, so risk concentrates the way it did when the Change Healthcare breach cascaded into exposure across hundreds of thousands of providers and tens of thousands of pharmacies. HIPAA compliance frameworks for AI agents establish a further point: the agent's actions are treated legally as though a workforce member performed them. That legal equivalence means the exposure footprint left behind by a breached agent mirrors what a trained human operator would accumulate over the same stretch of time, credentials, system access, and a record of everything touched.

The covered entity's obligations when the breach is at the vendor

The exposure picture above is complicated, but the regulatory allocation is not. The covered entity carries the breach-reporting burden regardless of where the technical failure occurred. The vendor, acting as a business associate, has its own obligation to notify the covered entity without unreasonable delay, and its duties run further still, including providing the specific content required under 45 CFR § 164.410(c) and complying with the Security Rule. But none of that substitutes for what falls to the covered entity directly: patient notification, HHS reporting, media notification where applicable, and the documentation trail proving each step was handled properly.

HIPAA was not written with an exception for autonomous systems, and HHS's 2024 position closes that door explicitly: an AI agent acting on behalf of a workforce member is held to the same access control and minimum necessary standards as that employee, and the same breach consequences follow from a failure at the agent level. The shared responsibility model holds the vendor accountable for securing its own infrastructure, while the covered entity remains accountable for how that service was configured, how it was used, and for demonstrating, if challenged, that oversight was genuinely exercised.

How a standard BAA fails to anticipate what AI vendors do

Most BAA templates in circulation were drafted for vendors that store data, not for systems that actively operate software on a practice's behalf, and that mismatch becomes acute the moment something goes wrong. This is a design problem built into templates that predate agentic AI, not a sign of bad faith on any vendor's part. A BAA signed with a primary AI vendor does not automatically extend to every subprocessor in that vendor's chain, inference APIs, cloud compute providers, logging pipelines, each of which may touch PHI without the covered entity's knowledge. Guidance on HIPAA compliance for AI agents is direct about where that responsibility sits: the primary vendor is responsible for obtaining BAAs from every downstream subcontractor, but a covered entity that assumes this happens automatically is carrying undocumented risk.

Several specific gaps recur across standard BAA language:

• Whether the vendor may use PHI to train or fine-tune models, a use that goes well beyond helping the covered entity and requires explicit authorization.
• Retention and deletion terms for agent memory, covering the action history, the PHI retrieved during sessions, and the conversation logs the agent accumulated before any breach occurred.
• Whether an AI hallucination that inadvertently exposes PHI to an unauthorized party counts as a reportable incident, a question that current AI vendor compliance guidance identifies as unresolved in most contracts.
• Breach notification timelines that use language like "without unreasonable delay" without defining what that phrase means in practice, leaving the covered entity unable to enforce a schedule it needs in order to meet its own 60-day deadline.
• No defined requirement for what the vendor must hand over during a breach, whether a formal written incident report is owed rather than a verbal summary, what forensic documentation the vendor must provide, and who the single point of contact will be.

When the 60-day notification clock starts

The 60-day deadline itself is fixed and well understood: under the Breach Notification Rule, written notice to affected individuals must go out without unreasonable delay and no later than 60 calendar days from discovery of the breach. What is far less fixed, in the AI vendor context, is when discovery actually occurs. Discovery is the practice's discovery, not the vendor's, and if a breach happens inside infrastructure the practice cannot directly observe, pinning down that moment gets genuinely difficult.

The notification cascade that follows discovery has two main tracks. Individual notification must be written, in plain language, and delivered within 60 days, with content covering a description of the incident, the types of PHI involved, the steps patients should take, and contact information for follow-up questions. If a breach affects more than 500 residents of a single state or jurisdiction, you must also notify prominent media outlets in that state within the same 60-day window.

The detection lag is structural: healthcare organizations take an average of 279 days to identify and report vendor-related breaches, a timeline that on its own already blows past the 60-day requirement, because monitoring systems are built to watch internal networks, not to detect incidents occurring inside a third party's infrastructure. A pending update to the HIPAA Security Rule would tighten one piece of this: the proposed rule requires business associates to notify covered entities without unreasonable delay and no later than 24 hours after activating contingency plans, with system restoration expected within 72 hours. The practical consequence for a practice that waits on its vendor to confirm scope before starting its own investigation is straightforward: if the vendor takes weeks to confirm what happened, the 60-day clock keeps running regardless, and a meaningful share of it may already be gone before the practice's own work even begins.

The four-step investigation the practice must run in parallel with the vendor

A practice cannot hand its investigation to the vendor that was just breached and wait for results. It has to run its own process alongside the vendor's, because the vendor's interest in containing the incident quickly does not always line up with the practice's obligation to meet its notification deadline with an accurate account of what happened.

The first step is demanding written documentation immediately. Verbal summaries are not sufficient. For AI agent vendors specifically, this step also requires establishing which payer portals the agent had active sessions in at the time of the breach, which EHR connections were live, and what the agent's action history actually covers, since these three facts set the outer boundary of how much PHI could have been exposed.

The second step is to oversee the forensic investigation itself, not to try to control it. For AI-specific deployments, you also need to confirm whether agent memory logs and action histories were accessed, whether vaulted credentials should be treated as compromised, and whether OAuth tokens need to be revoked across every connected system the agent touched.

The third step is conducting the formal risk assessment independently, using the four-factor test the Breach Notification Rule sets out: the nature and extent of the PHI involved, the identity of whoever received it without authorization, whether the PHI was actually acquired or viewed rather than simply exposed to potential access, and the extent of mitigation already completed. Compliance counsel should be consulted before the assessment is finalized, and where real uncertainty remains, the safer course is disclosure.

The fourth step is drafting and executing notification independently. Plain language in the notification is a regulatory requirement, not a stylistic preference, so stand up a dedicated team to handle patient inquiries before notifications go out, because call volume tends to arrive right after disclosure.

What the BAA and vendor contract should have established

Each of the four steps above is harder to execute when the contract governing the relationship never specified what the vendor owes the practice, on what timeline, and at what level of detail.

Breach notification timelines deserve specific contract language rather than the statutory phrase "without unreasonable delay."

Subcontractor coverage needs explicit treatment as well. If a covered entity signs one BAA and assumes the coverage extends automatically to every downstream service, it is carrying risk it has never documented.

A model training prohibition is non-negotiable.

Retention and deletion terms need the same specificity: how long the vendor keeps agent memory, retrieved PHI, and audit logs, and whether the covered entity has the right to trigger deletion on demand with written confirmation from the vendor that it occurred. Forensic cooperation obligations belong in the contract too, spelling out that a written incident report is required rather than a verbal one, that a forensic firm meeting defined criteria will be engaged, that preliminary findings will be shared on an agreed schedule, and that a single named contact will handle the relationship during an incident.

The pending Security Rule update also points toward a broader obligation: covered entities will need to maintain a current inventory of every AI tool accessing PHI and map ePHI data flows to and from business associates, along with obtaining annual written verification that those business associates have implemented required technical safeguards. Contracts that require vendors to proactively disclose new subprocessors and new data flows make that inventory achievable. HIPAA-compliant AI frameworks draw a useful distinction here: a vendor that is "HIPAA eligible" has the underlying security features and a willingness to sign a BAA, but whether the deployment is actually compliant depends on how the covered entity configures the service and how specific the contract language is. The BAA sets the contractual foundation. But you still have to verify, on an ongoing basis, that the vendor actually does what it agreed to.

Closing contract gaps with an AI vendor

Practices already running AI vendor relationships do not have to wait for a renewal cycle to close the most dangerous gaps. The current BAA should be audited against each item described above: the training prohibition, subcontractor coverage, retention and deletion terms, notification timelines, and forensic cooperation requirements. Where gaps appear in the audit, the right move is opening an amendment conversation with the vendor immediately.

Building a technology asset inventory now also pays off regardless of how the pending Security Rule update is finalized. That inventory should document every AI tool touching PHI, which subprocessors each one uses, what data flows it creates, and what credentials or tokens it holds, and it doubles as the starting point for scoping the patient population at risk if any single vendor is ever breached.

Internal incident response runbooks need entries written specifically for AI vendor breach scenarios, answering who owns vendor communication and forensic oversight during an incident, who owns the risk assessment and the notification drafting, what the escalation path looks like if the vendor is slow to produce written documentation, and at what point legal and compliance counsel get engaged.

Credentials should be revoked and rotated proactively the moment a vendor breach is suspected, even before forensic confirmation arrives. Agent deployments holding vaulted payer credentials and live EHR tokens cannot wait weeks for a forensic report before basic credential hygiene begins.

You need audit logs covering the agent's action history and PHI access to be available from the vendor on demand. Without them, a practice has no way to scope a breach accurately or defend a risk assessment to a regulator asking hard questions. Logging access for audit purposes is one of four enforceable HIPAA compliance mechanisms for AI agents, so if you skip it, the deployment is a live violation from the moment the agent starts running, breach or no breach.

The same agent-based architecture that creates this breach-exposure complexity also allows deployments to operate across the EHR, payer portals, and other systems a practice already uses without requiring new API integrations or a workflow overhaul. That means the vendor's infrastructure footprint, and the breach surface that comes with it, can be scoped and monitored without ripping out and replacing existing systems. The conversation worth having with any AI vendor is about what the vendor holds, how it logs what it holds, and what it owes the practice in writing the day something goes wrong.