OpenAI's Breach Record Undercuts Law Firm Safe Harbor Claims

The useful question after the latest OpenAI security response is not whether a law firm can point to a vendor assurance and say the file is closed. It is whether, after the TanStack and Redis-py incidents, a firm using consumer ChatGPT for client material can still describe that posture as a reasonable effort to prevent disclosure. That is a narrower question than most commentary around an OpenAI security incident tends to ask, and it needs the narrower treatment.

The record does not support saying that OpenAI suffered a direct user-data breach in May 2026. It does not support treating enterprise API deployments with contractual controls as equivalent to a lawyer pasting client documents into a consumer interface. It also does not make a UK privilege ruling binding on a US ethics committee. The problem is more practical: a law firm that has notice of these incident mechanics and still relies only on OpenAI's own security statements has a thin procurement file when Model Rule 1.6(c) asks what reasonable efforts were made.

The May 2026 incident was not a simple user-data breach

The TanStack incident matters precisely because it is easy to mislabel. The reported vector was an npm supply-chain attack affecting the TanStack open-source project, not a cinematic intrusion in which attackers broke straight into OpenAI's production systems and carried away customer prompts. In the reported sequence, attackers published 84 malicious npm package versions in a six-minute window; the activity was detected within 20 minutes, but not before two OpenAI employee devices were compromised and credential material was exfiltrated from a limited subset of internal source-code repositories.[1]

OpenAI said no user data was breached, and Reuters reported that statement on May 14, 2026.[2] That assurance may be accurate on its own terms. But for a law-firm risk review, "no user data was breached" is not the end of the inquiry when the same incident record includes employee-device compromise, credential material leaving limited repositories, and later certificate rotation for macOS users.[1][2]

Those are not interchangeable facts. Raw client prompts sitting in an exposed database would create one risk profile. Credential material exfiltrated from internal repositories creates another. A law firm does not need to pretend they are the same to recognize that both belong in a vendor-risk memo. The procurement question is whether the firm tested the boundary of OpenAI's public statement: what data was outside the affected subset, what credentials could have accessed, what rotation occurred, what logs were reviewed, and what contractual remedies would exist if the statement later proved incomplete.

A SOC report or security FAQ may answer some of that. It rarely answers all of it. The gap is not solved by calling the incident a "hack" more loudly; it is solved by asking what actually happened, which controls limited the blast radius, and which controls apply to the product tier the firm is using.

Redis-py shows why dependency failures are not theoretical

The older Redis-py incident is a useful corroborating fact, not merely a historical footnote. In March 2023, OpenAI confirmed that a bug in the Redis-py open-source library contributed to a ChatGPT outage and exposed payment-related information for some ChatGPT Plus subscribers during a nine-hour window.[3][4]

OpenAI's own disclosure said the exposed payment-related information affected 1.2% of ChatGPT Plus subscribers active during a specific nine-hour period.[4] The point is not that this earlier incident proves later insecurity across all OpenAI products. It proves something narrower and more relevant to procurement: open-source dependency failures have already produced externally visible data exposure in the ChatGPT environment.

For a consumer-facing technology company, those distinctions are public-relations details. For a law firm, they are the difference between a defensible AI-use policy and a file that says, in substance, "the vendor told us it was fine."

Notice changes the Model Rule 1.6(c) analysis

ABA Model Rule 1.6(c) requires a lawyer to make reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client.[5] That standard is not strict liability. It also is not satisfied by deciding, once and for all, that a famous vendor must be safe because many other organizations use it.

Reasonableness is contextual. Once the incident record includes a documented payment-data exposure tied to an open-source library and a later supply-chain compromise involving credential material from internal repositories, the context changes. The firm has notice of a class of risks: not simply "AI may hallucinate" or "vendors can have outages," but that dependency-layer failures can create confidentiality-adjacent exposure in tools lawyers may be tempted to treat as ordinary office utilities.

ABA Formal Opinion 512 addresses lawyers' use of generative AI and confidentiality obligations, including the need to understand how a tool handles information relating to a representation before using it with client data.[6] In practical terms, that pushes the inquiry beyond whether the model is useful. The firm needs to know whether prompts are retained, whether they are used for training, whether administrators can review them, whether contractual confidentiality obligations attach, whether incident notice is promised, and whether the answer differs between consumer, team, enterprise, and API products.

The answer may be acceptable. It may even be strong. But under a reasonable-efforts standard, the answer has to be obtained and preserved somewhere more durable than a partner's recollection from a product demo.

What a defensible file should contain

A law firm does not need to build an incident-response laboratory before allowing any AI use. It does need a record proportionate to the sensitivity of the information being entered into the tool. For consumer ChatGPT use involving client information, the missing document is often not a grand AI governance charter. It is a short, concrete diligence memo.

• Identify the product tier actually used, including whether it is consumer ChatGPT, a business workspace, an enterprise agreement, or an API deployment.
• Record the vendor's data-use terms for prompts, files, logs, training, retention, support review, and administrative access.
• Ask how the TanStack and Redis-py incidents affect the vendor's current controls, especially dependency management, credential rotation, incident notice, and customer-data segregation.
• Map permitted use to data sensitivity, so public research, anonymized drafting, confidential client documents, privileged materials, and regulated data are not treated as one category.
• Preserve the approval path: who reviewed the terms, who accepted residual risk, and what conditions were placed on lawyers and staff.

That kind of memo is unglamorous. It is also the document the general counsel or risk committee will want when the question arrives after the fact: why did the firm believe client confidences could be placed there?

Hamid is not US law, but it draws a useful boundary

The UK Upper Tribunal's 2026 Hamid decision should not be oversold in a US ethics analysis. It is not a US Model Rule opinion, and its direct legal effect is confined to its jurisdiction. Still, its treatment of confidential uploads to open-source AI tools is worth reading because the tribunal treated the use of open-source AI with confidential documents as placing material into the public domain and waiving legal professional privilege, while drawing a contrast with closed enterprise systems such as Microsoft Copilot.[7]

That distinction maps closely to the procurement boundary US firms should already be drawing. A lawyer using consumer ChatGPT from a personal or unmanaged account is not in the same position as a firm using a closed enterprise deployment with negotiated data-handling terms, administrative controls, retention commitments, and incident-notice obligations. Treating both as "using OpenAI" is too crude to help anyone make a defensible decision.

The same distinction appears in other AI procurement questions. A firm's analysis of consumer-tier AI privacy settings should not be collapsed into its analysis of enterprise contracting. Nor should API pricing be evaluated without the risk controls that make one deployment materially different from another; that is where total cost and confidentiality posture meet in a procurement decision about OpenAI API use for legal professionals.

Consumer ChatGPT is the difficult safe-harbor claim

The hardest position to defend is not "we evaluated an enterprise AI tool, negotiated data protections, limited use by matter type, and trained users." The harder position is "lawyers used consumer ChatGPT with client information, and our diligence consisted of OpenAI's public assurance that no user data was breached."

After TanStack, the firm has to account for credential compromise even where the vendor says user data was not breached. After Redis-py, the firm has to account for the fact that an open-source library issue previously produced a payment-data exposure window in ChatGPT. After Formal Opinion 512, the firm has to account for how the tool handles client information before use, not after a confidentiality dispute begins.

That does not mean every lawyer who experimented with AI has committed an ethics violation. It does not mean OpenAI is uniquely unsuitable for legal work. It means the safe-harbor argument becomes weak when the firm cannot show independent diligence, tier-specific restrictions, and a reasoned decision about what information may enter the tool.

Enterprise and API deployments belong in a different column. Their risk depends on actual controls: the contract, data-retention settings, training exclusions, access management, logging, encryption, support access, breach notice, subprocessor terms, and the firm's own configuration. A closed system can still be misconfigured. A strong contract can still be ignored by users. But those are different failures from placing confidential material into a consumer-grade interface with no documented review.

The concentration issue should also be recorded. If a firm moves drafting, research, summarization, translation, document review, and intake support into one AI provider, outages and service dependency become part of the risk model, not just IT inconvenience. That parallel problem is separate from breach analysis, but it belongs in the same risk committee conversation about law firm AI tool concentration risk.

The procurement file is the real test

A reasonable-efforts analysis is not won by insisting that OpenAI is safe, and it is not won by insisting that no AI tool can ever receive client information. It is won, if at all, by showing the work: the incidents reviewed, the questions asked, the product tier selected, the controls verified, the use cases allowed, and the client-data categories excluded.

For consumer ChatGPT use with client data and no independent due diligence, the TanStack and Redis-py records make the safe-harbor claim difficult to square with Model Rule 1.6(c). For enterprise API or closed-system deployments with contractual data-handling protections, the analysis remains materially different and should turn on the controls actually in place.

The person holding the procurement file will not be asked whether OpenAI promised safety in general. They will be asked whether the law firm tested the promise before trusting client confidences to the tool.

References

1. OpenAI says hackers stole some data after latest code security issue, TechCrunch, May 14, 2026.
2. OpenAI says no user data breached, Reuters, May 14, 2026.
3. ChatGPT Data Breach Confirmed, SecurityWeek, March 2023.
4. March 20 ChatGPT outage: Here's what happened, OpenAI, March 2023.
5. Rule 1.6: Confidentiality of Information, American Bar Association.
6. Formal Opinion 512, American Bar Association.
7. Court guidance that use of open-source AI waives confidentiality and legal professional privilege, Norton Rose Fulbright, April 2026.