Breach Please

Jess Hebenstreit and Jake Williams break down a Los Angeles County Museum of Art data security incident that raises big questions about breach timelines, notification delays, and response ownership. They focus on what the disclosure says, what it leaves unsaid, and why the cleanup process may have taken far longer than it should have. In this episode, they examine the gap between initial detection, timeline validation, data review, and eventual notification. They also unpack why the kind of data exposed suggests employee and benefits records, and why that matters for both legal exposure and response logistics.

• Jess and Jake note that LACMA says it detected suspicious activity on July 11, 2025, but did not publish the disclosure until August 24, 2026.
• They question how it took weeks to confirm the intrusion window and then months more to complete the data review.

• Jake points out that the investigation later narrowed the third party’s access to July 7 through July 11.
• They discuss how incident teams can get stuck chasing false leads in logs, but still say this timeline feels slow.

• The disclosure says the initial data review results arrived in late February 2026.
• Jess and Jake interpret that as a sign of weak data governance, poor vendor management, or both.

• The potentially exposed data includes full names, dates of birth, Social Security numbers, government ID numbers, financial account numbers, payment card data, health insurance information, and limited medical details.
• Jess argues that this pattern looks like employee data, possibly tied to a self-funded health plan.

• Jake questions why the organization spent months trying to obtain “accurate contact information” before notifying impacted people.
• He notes that breach notification rules generally do not wait for perfect contact data before state reporting obligations begin.

• Jess says she expects litigation, and Jake agrees.
• They also suggest state attorney general investigations are likely.

• Jess thinks a change in leadership or responsibility may have disrupted the response.
• Jake agrees that handoffs, missing context, or people being removed mid-incident can create major problems.

• Jake explains why identifying impacted records is harder than it sounds, especially with inconsistent name formats, spellings, and duplicate records.
• Both agree this kind of work should be handled by a firm that does breach review every day.

• They debate whether the organization had cyber insurance and how that would have affected the handling of the case.
• Jake explains that cyber claims usually involve upfront costs and reimbursement later, which can slow response work.

• Jess closes by saying she feels bad for the responders who had to deal with the mess.
• Jake advises responders to keep notes, assume they may be deposed later, and remember that the organization will not protect them in enforcement actions.

00:00 - Breach Please intro and the show’s no-nonsense mission

01:33 - LACMA data security incident enters the conversation

01:50 - Why the disclosure timeline is so hard to believe

03:18 - What the timeline says about detection and scoping

06:01 - Late February 2026 data review results

07:57 - Why “accurate contact information” is a weak explanation

08:52 - Why a lawsuit and state investigations seem likely

09:27 - The exposed data and why it looks like employee records

10:54 - A Reddit post suggesting notifications were already going out

12:12 - Possible leadership change during the response

13:37 - When even counsel decides the incident is too messy

15:31 - Whether cyber insurance was involved at all

17:04 - How cyber claims actually get paid

18:38 - Procurement problems or failed in-house review?

20:21 - Why identifying impacted people is much harder than it sounds

22:36 - Why outsourcing the review was probably necessary

23:35 - Why state reporting obligations still matter even if mailing is slow

24:04 - Sympathy for the responders caught in the middle

25:02 - Why responders should document everything now

25:57 - Final reminder: organizations do not protect employees in enforcement actions

26:11 - Outro and closing sign-off

In today's episode of Breach Please, Jake and Jess talk through the OpenAI post-mortem on the Hugging Face hack. It's a doozy. There's little doubt in either of our minds that the facts as presented don't exonerate OpenAI - they make it look far worse. We cut through the hype and conclude that there's no way OpenAI was following even the most basic of security best practices, even accounting for hindsight bias. Jake closes by reading a passage from one of Sam Altman's tweets from December 2025, which made clear he knew the dangers of AI - the kind of thing that is likely to haunt him in the future.

https://openai.com/index/hugging-face-incident-and-the-road-ahead/

https://x.com/sama/status/2004939524216910323

Fifteen state attorneys general, led by Alabama, just subpoenaed OpenAI over the Hugging Face breach, demanding the company preserve all evidence related to the intrusion. Jess and Jake break down what that legal hold actually requires, why "mark it ACP" doesn't make a Slack channel privileged, and why the discovery list's question about internal safety concerns might be the part that burns OpenAI hardest.

Then: a perfect-10 WebLogic vulnerability, patched back in January, just landed on CISA's Known Exploited Vulnerabilities list, eight months after active exploitation began. Jess and Jake talk through why "patch applied" isn't the finish line and what a post-patch threat hunt should actually look like.

In this episode: Fifteen states subpoena OpenAI over the Hugging Face hack and order evidence preservation What a legal hold actually requires (and what evidence spoliation means) Why marking a channel "ACP" doesn't make it attorney-client privileged The discovery request digging into internal safety concerns and model testing A perfect-10 WebLogic CVE, patched in January, added to CISA's KEV eight months later Why "patch applied" doesn't mean "threat hunt done"

AI just became a cybersecurity governance problem in public. Jess Hebenstreit and Jake Williams break down Anthropic’s multi-agent research, where AI agents with conflicting goals start negotiating, forcing, or trucing their way through “collaboration.”What does it mean when one model settles by force and another settles by truce?

Jess and Jake unpack what that means for real-world agent deployments, human-in-the-loop approvals, and the danger of letting “AI says so” become the final word. You’ll learn why multi-agent systems can spiral into turf wars, why governance gets harder once agents are involved, and how to build controls that still let humans say no.

In this episode, Jake and Jess talk about vulnerabilities in cloud platforms and how vulnerabilities should be disclosed. We discussed this in the context of recent Microsoft vulnerabilities in Entra, Azure Arc, Exchange Online, and Managed Apache Casandra. All of these had vulnerabilities with minimal details from Microsoft. We generally agree that this isn't what transparency looks like. We also discuss a patch from April that is now actively exploited in the wild.

In this episode of Breach Please, we talk about the details that emerged about the Anthropic agent that tried to social engineer a college student into committing a supply chain attack. The whole thing feels very xz-utils 'esque, only with an agent - and a malfunctioning one at that.

Then we cover some interesting reporting by Dan Goodin showing how Grok's guardrails can be bypassed through passing it encrypted data along with the instructios to decrypt it. We reinforce that prompt injection is a feature of LLMs, not a bug.

We then talk about informed consent of the risks and applicable guardrails based on a viewer note. We even tee up the question of what cyber insurance is likely to cover costs of AI agent activity. Finally, we opine on whether orgs should consider including the inevitable costs of incidents in AI deployment budgets.

Show links:

https://www.reuters.com/world/how-texas-student-blew-whistle-rogue-ai-hacking-attempt-2026-08-20/

https://arstechnica.com/security/2026/08/grok-exfiltrates-user-data-when-malicious-instructions-are-encrypted/

AI agents are about to test the limits of who gets blamed when they act on your behalf. A new Ninth Circuit ruling in the Amazon vs. Perplexity fight could reshape how enterprises think about autonomous tools, non-human identities, and legal exposure - and the takeaway is more unsettling than most vendors will admit.

Jake Williams and Jess Hebenstreit break down what happened when Amazon pushed back against Perplexity’s AI browser, why the CFAA and California’s CDFAA matter here, and how the court’s reasoning could shift responsibility from the agent publisher to the organization that deploys it. They also dig into what this means for legal teams, risk registers, and why every AI agent needs its own identity instead of borrowing a human user’s.

You’ll also hear how this ruling fits into the bigger enterprise governance problem: who owns AI risk, who should be accountable when an agent crosses a line, and why security teams can’t be expected to carry every line-of-business risk themselves. Jake and Jess make the case for splitting cybersecurity risk from business risk, naming a real owner, and making legal counsel aware before your agent does something expensive.

Then the conversation pivots to another cautionary tale: a 3M expert witness who allegedly used ChatGPT to generate a report aimed at proving the company was 0% at fault in a gas detector explosion case.

That story opens up a bigger discussion about leading prompts, hallucinated conclusions, discoverability, and why AI-generated work product can become evidence against you. Perfect for security leaders, legal teams, incident responders, and anyone deploying AI agents in the enterprise.

In this episode of Breach Please, Jake and Jess talk through OpenAI's recent blog on "pacing model development." The blog reads pretty poorly and really just covers security best practices, apparently hoping readers won't notice that OpenAI is just recommending basics it should have been doing all along (monitoring, sandboxing, etc.). One significant takeaway is that OpenAI has probably raised the bar for agentic logging, owing to the apparent requirement to analyze reasoning traces. We talk about why this is difficult, at least in part because these will contain sensitive data not appropriate for most SIEMs.

Show links:

https://openai.com/index/pacing-model-development-cyber-capabilities/

https://www.custody-framework.org/

In this episode of Breach Please Jake and Jess talk about Famous Chollima getting faked out and tricked into revealing TTPs. We discuss our own experience with DPRK workers and share actionable tips for not hiring them or discovering them after they've been hired. Jake may or may not have gone on a rant about cryptocurrency more generally and how it facilitates lots of crime (inspired by talking about DPRK using it for sanctions evasion).

Then we talk about in-car advertising on infotainment systems. These won't be patched reliably. Do we need regulation here? Jake thinks it's a right to repair issue.

Jake's class Friday August 21, 2026: https://learning.antisyphontraining.com/courses/assessing-ai-security-model-context-protocol

Jake's class at Wild West Hackin' Fest in October: https://www.antisyphontraining.com/product/hands-on-ai-security-risk-assessment-with-jake-williams/

Show notes: https://any.run/cybersecurity-blog/lazarus-group-it-workers-investigation-part-two/

https://disconnect.blog/bmws-in-car-spider-man-ad-is-a-warning-sign/

In this episode of Breach Please, we talk about whether CTI analysts can use changes in dwell times, cyber targeting, etc. as a leading indicator of impending geopolitical events. We generally think there's to much noise to be generally effective (especially for Taiwan).

Then we talk about a Mac vuln that's being exploited in the wild, with a CVSS score of 9.8. Somehow it isn't in CISA's KEV, but hey, what's a little vulnerability enrichment delay between friends...

Show links:

https://www.tomshardware.com/tech-industry/cyber-security/macos-screen-sharing-flaw-exploited-to-root-macs-and-plant-monero-miners