Seven angles this week

A security researcher recently found a critical flaw in PHP — software that runs roughly 70% of the world's websites — in a single week. A world-class human team would once have needed months.

That's the story everyone in technology should be sitting with right now.

We keep framing AI in security as something that helps defenders. The more honest read is that the advantage sits with the attackers at the moment. You can scale AI agents like any other software — dozens, hundreds, thousands running in parallel. Microsoft reported one group making 2,900 login attempts a minute across 2,250 organizations. These agents don't get tired, don't get bored, and they look in places a human analyst never would.

For anyone running core platforms built years ago, this reframes the problem. Those systems were secured against human-paced threats. The assumption that an obscure internal system is safe because nobody would bother looking — that assumption is now wrong.

Two practical shifts worth making. First, treat your software bill of materials as a live risk register, not a compliance checkbox. Second, prioritize patching by how exploitable something actually is, not just its severity score.

Cloudflare's CEO put it bluntly: we're going to have a couple of years where every week feels like the sky is falling. He's probably right. The internet that comes out the other side will be safer — and less open — than the one we built.

What's your team doing differently this quarter because of agentic threats?

Here's a number that should reshape how you think about AI costs.

On the open marketplaces where developers can switch models with a single line of code, 94 of every 100 tokens last month went to the cheaper, second-tier models — the ones that are about two-thirds as smart as the frontier at a sliver of the price.

First class is lit, staffed, and nearly empty.

The labs are still selling the smartest-model story to investors. But the people actually building things have already voted, and they voted for good-enough-and-cheap.

This tracks with what I see. Most real production work doesn't need the most powerful model available. Extracting data from a document, drafting a first-pass summary, triaging a routine request — these are workhorse tasks, not frontier problems.

The practical move is a tiered model strategy. Route the bulk of your volume to cheaper models. Reserve the expensive, frontier capability for the narrow slice of work that genuinely needs it. The difference shows up at scale — it's often the gap between a pilot that demos well and a system that stays affordable across millions of transactions.

There's a strategic benefit too. If most of your workload runs on commodity models, you keep your optionality and your negotiating leverage. You're not locked into one vendor's pricing roadmap.

The smartest architecture decision in AI right now might be choosing to not use the smartest model.

Where are you over-paying for intelligence you don't need?

Earlier this year, Demis Hassabis put AGI at five to ten years away. Then three to five. Now he's telling the Wall Street Journal two to three.

I'm less interested in the debate about whether "AGI" is even a useful term — it's contested, and arguing the definition is a way to avoid the harder question. What strikes me is the direction and the speed of the revision, coming from one of the field's more measured voices, calibrated against what he sees inside his own lab.

Here's the mistake I see executives making: waiting for a settled definition before they plan. That's optimizing for the wrong question.

You don't need to believe in AGI to act on the trend line. The signal is simple — capability is arriving faster than most enterprise roadmaps assume.

For anyone responsible for technology architecture, this has a concrete implication. Don't hard-wire today's model limitations into your platforms. Put an abstraction layer between your business logic and whichever model sits underneath it. Make the model swappable.

The organizations that get caught out over the next few years won't be the ones who guessed the timeline wrong. Everyone's guessing. They'll be the ones who built their systems around the capabilities models had in 2026, and then couldn't absorb the step-change when it came.

Build for capability you don't have yet. Keep the model layer loose.

How are you designing your systems to absorb capability you can't yet see?

Social inflation has been pushing commercial auto liability claims costs above economic inflation for several years now. AM Best just confirmed the trend is still running, with no real sign of relief.

In every AI conversation I have with insurance leaders, the attention goes straight to underwriting and pricing. Those matter. But I think we're pointing the tools at the wrong end of the problem.

The bigger opportunity is in claims and litigation severity.

Here's why. Social inflation is fundamentally a data and pattern problem — rising litigation costs, venue effects, attorney involvement, settlement dynamics. That is exactly the kind of problem machine learning is good at. And yet most carriers still treat it as an actuarial afterthought, something you discover in the reserving review rather than something you manage on the front line.

The practical application isn't glamorous. It's using models to flag claims with litigation-escalation signatures early, before severity compounds. It's surfacing venue and representation patterns. It's informing reserves with better signal, sooner.

This is the real bridge between AI and core insurance operations — not a customer-facing chatbot, but disciplined pattern recognition aimed at the single biggest driver of commercial-lines deterioration.

The carriers who connect their claims data to this problem will reserve more accurately and settle more intelligently. The ones who don't will keep repricing after the damage is already on the books.

If litigation trends are outrunning your rate actions, that's where AI should be working hardest.

Are you aiming your AI at pricing, or at severity?

Meta just released an open-weight model and did something that surprised a lot of people: partnered with Apple to run it locally, on the device.

Most of us default to an assumption that serious AI lives in the cloud, behind someone else's API. That assumption deserves a second look — especially in regulated industries.

When a capable model can run on-device or inside your own perimeter, something important changes. It's not mainly about speed. It's about data governance.

If sensitive data never leaves your control plane, a whole category of projects that legal and compliance previously blocked becomes possible again. Claims documents full of personal information. Medical records in disability and health lines. Fraud signals you'd never want traveling to a third-party endpoint.

For those who've spent the last two years hearing "we can't send that data to an external model" — edge-capable open models are a real answer, not a workaround.

There's an honest tradeoff. You take on the infrastructure, and you accept a model that's somewhat less capable than the frontier cloud offering. But for the workloads where data residency is the binding constraint, that's a trade worth making every time.

The lesson I'd take from the Meta-Apple move: open weights plus local inference is becoming a serious architectural pattern, not a niche experiment. For anyone sitting at the intersection of AI and sensitive data, it's worth building a point of view on now.

Where is data residency quietly blocking your AI roadmap?

Quantum computing sits in the "someday" folder for most executives. I'd argue one part of it belongs in the "now" folder.

McKinsey's latest lays out three horizons for quantum — trillions in potential value, and a warning that it could break today's encryption within the decade. The value is genuinely a future story. The encryption risk is not.

Here's the uncomfortable mechanism: adversaries can harvest encrypted data today and simply store it, waiting to decrypt it once quantum capability matures. It's called "harvest now, decrypt later." Which means the clock on your most sensitive data has already started, regardless of when quantum actually arrives.

Insurance is unusually exposed here. We hold data that stays sensitive for decades — life policies, medical histories, long-tail liability records. Data exfiltrated and encrypted today is a time bomb if its secrets still matter in fifteen years.

The response isn't to go buy a quantum computer. It's far less exciting than that. Start inventorying where your long-lived sensitive data lives, and begin planning a migration to post-quantum cryptography.

This is unglamorous, multi-year infrastructure work that produces nothing visible this quarter. Which is precisely why it keeps getting deferred.

The organizations that start their cryptographic migration early will do it calmly and deliberately. The ones that wait will do it in a panic, under regulatory pressure, after an incident.

For data that has to stay secret for decades, early is the only sensible setting.

Has anyone started a post-quantum readiness inventory yet? I'd be curious what you're finding.

Someone recently handed Meta's AI agent a simple task: sell a computer keyboard on Facebook Marketplace. The agent got to work — listing, messaging, negotiating.

It's a small experiment with a large implication. Agents are no longer just helping people think. They're becoming parties to transactions, with access to personal data and the ability to act on someone's behalf.

Most of the agent conversation is still framed around productivity. The part we're under-examining: for anyone running customer-facing systems, an agent isn't a user interface change. It's a new category of counterparty.

Think about what this breaks for a digital insurance channel. We've quietly assumed that a human reads the disclosures. That friction deters fraud. That a verified identity means an actual person is present. Soon a customer's agent may quote, bind, file a claim, or negotiate a settlement — and none of those assumptions hold.

This cuts both ways. Agent-to-agent servicing could be genuinely efficient, resolving routine interactions without a call center. But agents can also be manipulated, and they scale fraud the way they scale everything else.

The architectural question to settle now, before agents show up uninvited: how do your systems authenticate and authorize non-human actors? How do you tell a legitimate customer agent from a hostile one acting at machine speed?

Agent identity and authorization belong in your channel architecture today, not after the first incident.

Is your digital front door ready for customers who send a bot instead of showing up themselves?