The Same Bet, Twice

A while back I helped build a company called Drawbridge Networks. The idea was network microsegmentation — not just carving up the data center, but pushing it all the way down to individual desktops and servers. The premise was simple: an attacker who gets one foothold shouldn't be able to walk sideways to everything else. Contain the blast radius at the machine level, not just the perimeter.

The industry was mostly looking at the server side. Segment east-west traffic in the data center, wall off the crown-jewel workloads, and call it done. We thought that was half the picture. The desktop is where the phish lands, where the credential gets stolen, where the attacker actually starts. If you're not segmenting there too, you've fortified the vault and left the front door open.

I still think that was right. It may also have been about a decade early.

Here's what I mean by early. The technology worked. The problem was real. But the buyers weren't feeling the pain sharply enough yet to reorganize how they did things around it. Segmenting desktops meant touching every machine, coordinating with teams who didn't report to security, and accepting operational friction for a threat that hadn't yet hit them personally. Most organizations weren't ready to make infrastructure that changeable, at that granularity, on that scale. The conviction was sound. The market wasn't there.

I went on to be a CISO four times, across financial services, media, and enterprise. Different industries, different stacks, same meeting every quarter. Security knew exactly what needed to change. And there was no safe path to actually change it. The person who owned the system was measured on uptime, not posture, and every change was a chance to break something with no clean way back. So the dangerous thing sat there, quarter after quarter, and nobody was wrong to leave it alone.

I've said this a few different ways over the years, but it comes down to one line: security teams need to be empowered to solve their own problems and not constantly create work for other people.

That's the same bet as Drawbridge, one layer up. Both are about making infrastructure safely changeable. Drawbridge was about changing the network topology safely, at the machine level. Nexplane is about changing anything — an IAM role, a firewall rule, a key, a config — safely, with approval and a way back. The underlying conviction hasn't moved: the reason dangerous things don't get fixed is that fixing them isn't safe, and if you make it safe, people fix them.

What's different this time is the timing.

Two things changed. First, the pattern I saw as a CISO is now everyone's pattern — findings pile up, backlogs grow, and the gap between knowing and doing is wider than ever. Second, and this is the part that moved the timing for me: AI is now being pointed at infrastructure. Teams are handing agents the ability to make changes directly, and an agent with raw credentials and no way back is the desktop-segmentation problem all over again, except faster and at a scale no human is watching. The stakes went up. The tolerance for "we'll fix it manually" went down.

At Drawbridge I was early to a real problem. I don't think I'm early this time. The pain is sharp, the incidents are public, and the thing that was optional before — making infrastructure safely changeable — is starting to look mandatory.

Same bet. Better timing.

Nexplane is open source. If this resonated, star the repo — it helps others find it.
⭐ Star on GitHub