The failure of third party trust and offline detection

# The failure of third party trust and offline detection The most interesting story on the wire this week doesn't involve a massive data dump or a flashy zero-day. Instead, it involves a small Israeli startup that apparently found a way into the inner sanctums of OpenAI, Anthropic, and Meta. When people talk about AI security, they usually obsess over "alignment" or the theoretical risk of a model deciding to rewrite its own source code. They treat these labs like digital bunkers. But the reality is that these companies are essentially massive aggregators of third-party services and boutique partnerships. The link between this startup and the breaches suggests that the perimeter isn't a wall; it's a series of loosely managed handshakes. The claim here is that we're seeing a shift in how high-value targets are accessed. Attackers aren't necessarily breaking the front door; they're compromising the people who have already been invited inside to "help" the AI evolve. The evidence is simple: three of the world's most scrutinized AI labs were hit via the same vector of external associations. The implication is that these labs are so focused on the existential risk of their models that they've neglected the mundane risk of identity and access management for their partners. One might argue that these partnerships are strictly governed by NDAs and rigorous vetting. That's a comforting thought, but an NDA isn't a firewall. If a boutique firm has API access or integration privileges to a model's training environment, they become the most efficient path into the system. The second-order effect here is worrying for any enterprise currently integrating these models into their own proprietary stacks. If the labs themselves can't secure the partner chain, then every company piping their corporate data into an AI via a third-party "wrapper" or "optimization tool" is essentially adding another link to a very fragile chain. We aren't just trusting the AI provider; we're trusting everyone that provider trusts. Then there is the matter of Suisun. The city declared a local emergency after a cyberattack took down their 911 dispatch system. This isn't surprising if you look at the numbers. Government has been the second most targeted sector this week, with roughly 235 stories recorded. It sits just behind Technology, which remains #1 of 17 sectors with just over 360 stories. The spine of this incident is the human cost. When a dispatch system goes dark, it's not a "data breach"; it's a public safety failure. The technical details usually emerge later, but the pattern is always the same: a lack of redundancy and a reliance on legacy systems that were never meant to be exposed to the open web. The real danger here isn't just for Suisun. When one municipality's emergency infrastructure fails, it triggers a cascade of second-order pressures. Mutual aid agreements mean that neighboring jurisdictions have to pick up the slack. If those neighbors are running the same outdated software or utilizing the same vulnerable managed service providers, you aren't looking at an isolated incident; you're looking at a regional systemic failure waiting for a trigger. On the technical side of the wire, LockBit 5.0 has arrived. For those who don't spend their weekends reading ransomware changelogs, the headline is that it can now encrypt Linux systems offline without requiring a server connection. I find the "LockBit 5.0" branding tedious, but the shift in functionality is significant. Most ransomware relies on a handshake with a Command and Control (C2) server to exchange keys before starting the encryption process. This creates a massive signature for network detection tools. If your EDR or NDR sees an unusual outbound connection followed by a spike in file modifications, it's a relatively easy win for the defender. By moving the encryption process offline, LockBit is effectively silencing its own alarm. They've moved the logic to the endpoint. This means that any defense strategy relying heavily on network-based anomaly detection during the encryption phase is now obsolete against this version. Some will say that offline encryption isn't new and that other variants have done it before. That's true, but LockBit's scale makes the difference. When a group with this much distribution updates its toolkit to bypass C2-dependency, it doesn't just affect one or two victims; it raises the floor for every Linux admin in the Fortune 500. It's worth looking at the broader numbers for the week to see where the noise is coming from. Data breaches are still dominating the volume with 383 stories, and AI security is close behind at 378. Vulnerabilities, surprisingly, only clocked in at 158 stories. The discrepancy between "vulnerability" counts and "data breach" counts tells a story of its own. We're getting better at finding holes, but we're remarkably bad at plugging them before someone else finds them first. The gap is where the attackers live. We are also seeing a persistent trend in the healthcare sector, which ranks #3 of 17 for targeting this week with 116 stories. A retrospective on Unlimited Technology Systems shows that 3.8 million patient records were exposed in an incident from last year. This is a classic example of why "critical" needs to be earned. The breach happened in 2025, but the analysis and the full scope are only becoming clear now. The delay between exploitation and disclosure is where the real damage happens. If it takes a year to realize that nearly 4 million people have had their data leaked, then your incident response plan isn't a plan; it's a historical archive. If I'm looking for something to chew on, it's the current obsession with "agentic AI." The external headlines are already starting to hype this up as the next frontier for attackers. They talk about agents doing the "heavy lifting" for criminals. I suspect most of this is just fancy terminology for automated scripting and better prompt engineering. But there is one scenario that people aren't pricing in: the automation of the "partner" attack. If an attacker can use an AI agent to identify and compromise the smallest, least-secure boutique firm that has a contract with a major lab or government agency, they don't need to find a zero-day in the target's software. They just need to find a zero-day in the partner's password hygiene. We spend so much time worrying about the AI becoming "rogue" that we've forgotten that humans are already rogue and have very poor password habits. I'll be watching to see if LockBit 5.0 starts appearing in the wild on Linux environments before the first major patches for those specific targets are deployed. If it does, it's a sign that our detection windows are closing faster than we can move the goalposts.