Containment over detection
The security industry has spent two decades getting better at recognizing attacks. It is a race the defender structurally cannot win. There is a different bet, and it changes what you build.
The security industry has spent two decades getting better at recognizing attacks. Antivirus matched signatures, then endpoint detection learned to watch behavior, then the secure-browser category began instrumenting a managed Chromium to inspect what happened inside it. Each generation recognizes the bad thing a little faster than the last.
It is a race the defender keeps losing, and the reason is structural rather than a matter of effort or budget.
The asymmetry that never closes
Detection has to identify an attack before it can stop it. The attacker only has to find one technique the detector does not recognize yet. That is the whole game, and it does not improve as detection improves, because the attacker adapts to whatever the detector has learned. A novel exploit, a living-off-the-land technique, an insider authorized to do exactly what they are doing: each defeats recognition not by being more sophisticated, but by being unfamiliar.
So the defender runs to keep up, and the gap never closes. Most breach post-mortems read the same way. The signal was there. It was not recognized in time, or it was recognized and lost in the noise of ten thousand other alerts. The problem is not that detection is bad. The problem is that detection is a bet that you will recognize the attack, and that bet is structurally unfavorable.
What containment changes
Containment makes a different bet. Instead of trying to recognize the attack, assume it will happen and remove its consequences. Run the risky activity inside a boundary strong enough that a compromise inside the boundary cannot reach anything outside it. You no longer need to recognize the attack, because the attack has nowhere to go.
This is not a new idea, and that is the point. It is why cloud providers run untrusted tenant code in hardware-isolated virtual machines rather than trying to detect malicious workloads. The principle is well understood: where you cannot trust the input, you contain the execution. What has been missing is applying that principle to the place where enterprise work actually happens now, which is the browser and the desktop applications around it.
Why the boundary has to be hardware
A boundary is only as good as the thing that enforces it, and this is where most isolation claims quietly fall apart.
A software sandbox is enforced by the same operating system it runs on. Browsers do separate work into sandboxed processes, but that wall is drawn and policed by the OS kernel. A kernel vulnerability, or a chain that escapes the sandbox into the privileged broker, crosses it, and these escapes are not hypothetical. They are a known, recurring class. The controls a managed browser bolts on run in the same trust domain as the browser they are watching, so a compromise that takes the browser takes them with it. That is a control layer, not a containment boundary, and the distinction matters the moment something goes wrong.
A hardware-isolated virtual machine moves the boundary below the operating system, where the hypervisor enforces it. That enforcer is a far smaller, more scrutinized surface than the OS, the browser, and every application on the machine combined. A compromise inside the guest cannot reach the host, because the separation is not a software check that clever code can bypass. It is the same property that lets a cloud provider run your workload next to a stranger's on the same physical hardware without either being able to touch the other. Bring that property to the endpoint and the browser stops being the soft path into the network.
Containment is a primitive
Once the boundary is the unit of security, something useful follows. The controls stop being tied to any specific application.
If governance lives at the boundary, in the inspection of what leaves and the record of what happened, then it applies to whatever runs inside. A browser is one such payload. So is a different browser, which matters for the enterprise whose internal applications assume Chromium. So is an untrusted email attachment, or a legacy desktop application you would rather not run directly on a managed machine. The containment is the product. The browser is simply the first and most common thing to put inside it.
This is what makes the model durable. A detection product is only ever as good as its newest signature. A containment boundary holds against things no one has named yet, including the next category of payload you decide to run inside it.
The evidence it produces
Detection produces alerts, which are guesses that something might be wrong. Containment produces a different and more useful artifact: a complete record of what was actually mediated at the boundary. Because that record is written at the chokepoint every action has to pass through, it does not depend on having recognized anything. It is simply what happened.
The discipline worth keeping is to make that record value-free. Capture the finding type, the classifier, the count, the action, the identity, and the time, and never the matched content itself. A compliance record should not become a second copy of the sensitive data it was meant to protect.
The shift
Containment over detection is not a feature you add to a detection product. It is a different answer to what security is for. Detection asks how quickly you can recognize the attack. Containment asks why recognizing it should be the thing your safety depends on.
For the enterprises that have run the detection race for twenty years, watched the tooling improve, and still read the same breach post-mortems, that is the more honest place to begin. Assume the compromise. Make it irrelevant. Build the boundary so that being wrong about any individual threat is survivable by construction.
That is the bet Vespertil is built on.