Why I Joined Edera as Field CTO

A handful of people have already asked me why I left Zscaler, so I figured I'd write it down properly instead of giving the short version at every dinner and DM for the next six months.

I've always had an itch to find a better way to do things when faced with a hard task. Part of that is a love of solving problems and part of that is maybe laziness. I don’t want to do something that I perceive is of little value. Give me a manual process and I'll spend twice as long trying to figure out a way not to do it than it would have taken to just push through. It has frustrated the hell out of people over the years. It's the same instinct that pulled me toward tech in the first place: finding an easier way to do things.

Security turned out to be the field where that instinct gets to be combined with the opportunity to benefit the modern world. It's an industry built almost entirely on working around flaws instead of fixing them. Patch the vulnerability, add the control, buy the tool that watches for the thing you couldn't prevent. Rinse repeat as many times as you can and the question underneath all of it has always been the same: how do you establish trust at scale, in systems too big and too fast for any one person to fully see?

That's what attracted me to Edera. Kubernetes gave the industry a genuinely better way to ship software, but it inherited a shared kernel underneath it, and the industry's answer to that has mostly been to patch the holes as they surface, one CVE at a time, forever. Secure-by-design means something different: build the foundation so the hole can't exist in the first place, instead of getting faster at finding and patching it after it does. That's the smarter way to work, and it's what Edera is actually building.

Why Edera: Type-1 Hypervisor Isolation, Secure-by-Design

Edera was founded by Emily Long, Alex Zenla, and Ariadne Conill, and I don't think the pedigree of these powerhouse women gets talked about enough or is acknowledged. Ariadne created Wolfi and maintains Alpine Linux. Emily ran operations at Chainguard and Anchore before becoming CEO here. Alex is co-founder and CTO, and her path to this problem started earlier than most careers do at all: contributing to Ubuntu at 13, and more recently rewriting portions of the Xen hypervisor in Rust, the kind of technical curiosity that doesn't wait for permission. Edera is, in large part, the team that made secure-by-default the expectation for the software supply chain. That isn’t a coincidence—the people who rebuilt the industry's assumptions about supply chain security are now rebuilding its assumptions about compute isolation. That's not a coincidence I wanted to watch from the outside.

Then there's the technical depth. Edera isn't a sandbox, a policy engine, or a scanner bolted on top of Kubernetes. It sure as hell isn’t another SaaS security tool waiting to be replaced in a day of vibecoding. It's a Type-1 hypervisor with a memory-safe Rust control plane, built to isolate every container as if it were its own virtual machine, without the operational tax that's made real VM-level isolation impractical at container speed and scale. In independent benchmarking, that isolation runs roughly 3% faster on CPU and adds about 1.6% memory overhead compared to a standard container. That's worth sitting with: it's rare for a product to cut cost and improve performance while also making agent deployment at scale safe enough to actually adopt in the first place. Security, performance, and adoption get treated as three things you trade against each other. Here, they move together.

I have spent years, first as a CISO, then as an analyst, and then in product evangelism, watching competitors demo beautifully and then fall apart the moment you tried to implement them at scale. A demo often tells you a product can work for a singular use case. It doesn't tell you it works at scale, under load, in someone else's messy environment. Edera is the first isolation architecture I've looked at that I actually believe clears that bar, and not because the pitch was good, but because it is built to scale.

And underneath both of those is the thing I care about most personally: a bet on first principles over incrementalism. Most security innovation right now is incremental. Better telemetry, faster response, more AI, more context for the SOC. All useful, none of it questioning whether the underlying architecture is the actual problem. Edera is one of the few companies I've seen willing to ask the harder question: what if the kernel itself is the flaw, and no amount of detection tooling on top of it will ever close that gap? That's a first-principles bet. It's also, historically, the kind of bet that's hard to make inside a large company and much easier to make at the company willing to build its foundation on it.

The Problem I'm Most Excited to Help Solve: Running Agents Securely with Models You Can't Fully Trust

Early in my security career, I read a paper many years before that never really left me: Ken Thompson's "Reflections on Trusting Trust," his 1984 Turing Award lecture. Thompson proved that a compiler could be taught to insert a backdoor into everything it compiled, including itself, in a way no amount of reading the source code would ever catch. It's a short paper and worth fifteen minutes. I'll come back to why it matters more now than it did in 1984.

That's the part that security teams conveniently avoid acknowledging in claiming security has been solved. There is no zero trust, when you’re asking people to trust identity controls, trust permissions, trust a network, while the execution environment underneath it is vulnerable to untrusted code run on top of it. You can verify identity perfectly, least privilege the hell out of your data, and segment your network beautifully and still leave the kernel underneath wide open the moment code executes. When that code is probabilistic and built on trillions of parameters that no human can understand, you have no way of trusting it. An AI model isn't documented, deterministic software. Nobody can hand you a spec for what it will output, and nobody, including the people who trained it, can fully read the weights and tell you what a given prompt will produce before it produces it. That makes every inference call a bet: you're running undefined code, generated live, on infrastructure you're responsible for securing. And that's before the model starts acting as an agent, writing and executing its own code on top of its own undefined output, constantly, in production, faster than any human can review it.

That's Thompson's problem, playing out in a different form. He proved you can't establish trust by inspecting a layer you don't fully control. With a compiler, at least the source was theoretically readable and the behavior was deterministic once compiled. A model is neither. You can't read your way to trusting it, and you can't audit your way to trusting what it decides to run next. Verifying identity doesn't help when the thing you need to trust is undefined code the model just generated. Data governance doesn't help when the risk is execution, not access. If you can't verify the code, the only thing left to control is what it's allowed to touch when it runs. The only architecture that holds up is one where that code can execute at scale without ever being trusted enough to reach anything it shouldn't. Containment as a property of the system, not a promise from the vendor running inside it.

This is the frontier I want to spend my time on with this community. Not because Edera has fully solved the end-to-end problem today, but because it's the first place I've seen the right architectural instinct applied to it early enough to matter. 

Why Field CTO, Not Evangelist

We're already living the consequence of skipping this. In July 2026, Hugging Face disclosed a production intrusion carried out, apparently for the first well-documented time, end to end by an autonomous AI agent, with no human at the wheel. Days later, OpenAI confirmed the agent was one of its own models, running an internal capability evaluation with safety refusals deliberately turned off. That model broke out of its own "highly isolated" research sandbox first, then used the access it gained there to chain into Hugging Face's production infrastructure. Two companies, two escalation chains, the same underlying flaw: a shared kernel that let a compromised process become a compromised node, and a compromised node become a compromised cluster. Nobody had to trick the model into doing this. It was given a narrow benchmark to solve and treated "get the answer key" as an optimization problem, chaining a zero-day, privilege escalation, and stolen credentials because those were simply the moves available to it. That's the more unsettling version of this story: you don't need malicious intent for this chain to run. You need capability plus a soft boundary, and capability is only going up from here.

That's why I took this job as Field CTO and not a pure evangelist seat. I'm not interested in spending my time trying to grow a market or win an argument on a stage. I want to sit with security and engineering teams and work through how you actually implement containment in a real environment, with real constraints, not just make the case that you should. If you're wrestling with that problem right now, that's the conversation I want to have.