Browser security’s buying spree rests on one engine, without a clear Plan B

Presented by CloudMosa

The browser security buying spree of 2026 largely funded controls layered on top of Google Chrome, says Shioupyn Shen, founder and CEO of CloudMosa. But those controls still leave Chrome’s rendering engine executing untrusted web code on employee devices.

"Most enterprise browser security products run on the same Chromium code, and AI-assisted vulnerability discovery is exposing Chrome bugs at a steeply accelerating rate," Shen says. "And no vendor has funded an alternative execution architecture that enterprises could switch to if that code fails."

In the first half of 2026, CrowdStrike acquired Seraphic, Zscaler acquired SquareX, and Akamai acquired LayerX, following Palo Alto Networks’ $625 million purchase of Talon, and Island’s $4.85 billion valuation. The products they've acquired work through extensions, policy overlays, runtime instrumentation, and hardened Chromium builds, and each still runs web content on the endpoint.

This is a governance problem as well as a technical one. According to Shen, buying from several vendors hides a dependency on a single engine that no enterprise controls.

“When the giant falls, you fall with the giant,” he explains. “Chrome is a strong foundation. The problem is that the entire industry is building on essentially the same foundation without a meaningful Plan B.”

What Chrome’s surge to 1,072 security bugs signals about browser risk

Google’s Chrome security team reported in late July that it had fixed 1,072 security bugs across milestones 149 and 150, more than it fixed across the previous 23 milestones combined. Google credits AI-assisted discovery and machine-generated patches for the jump, along with a pilot that ships two security releases per week. It presents the increase in fixes as evidence that Chrome gets safer with every update.

Sharper tools do find more bugs, but the concern is how many flaws those tools keep uncovering as well. A browser’s rendering engine has to parse and execute content from effectively the entire internet, most of it untrusted, so when a new generation of scanners suddenly surfaces bugs at many times the old rate, it also raises a question about how much vulnerable code those tools are uncovering — and whether attackers equipped with similar capabilities could find some of it first.

“If those metrics tracked CO₂ concentration instead of software bugs, people would not look at the curve and say everything is fine,” Shen says. “They would ask what the curve is warning us about.”

Attackers get the same AI tools, which slashes the amount of expertise and time it used to take to search a very large codebase for an exploitable flaw. And a security model that works only when defenders find each flaw first gets harder to sustain as both sides accelerate. Every product built on Chrome inherits the exposure if flaw discovery outpaces Google’s patch cycle.

Enterprise browser security spending sits one layer too high

Enterprise browser security investment largely falls into two buckets: controls that govern what the browser does, and architecture that determines where potentially vulnerable code runs. Detection, URL filtering, data-loss prevention and policy enforcement strengthen the first. But they generally leave the browser’s rendering environment executing on the endpoint.

"Some of that money should be spent on reducing how much potentially vulnerable execution reaches the device at all, with detection, patching, and policy running on top of an architecture designed to limit the damage when prevention fails," Shen says. “The choice is whether to outspend competitors with the old architecture, or outsmart them with a new architecture.”

Browser isolation limits zero-day exploits before a patch exists

During the window before defenders write a signature or ship a fix, an architecture that keeps vulnerable code off the device limits what an attacker gains from a bug that nobody yet knows exists. CloudMosa takes that approach with Puffin Cloud Security, which executes web content remotely rather than on the endpoint.

“Think of vulnerable code as a dangerous prisoner,” Shen says. “The first question people ask is how strong the jail is. The more fundamental question is where you build the jail. Puffin Cloud Security puts the prison somewhere the prisoner cannot reach the user’s device, data, or applications.”

How Puffin Cloud Security’s split-browser architecture works

Puffin’s split-browser architecture dates back to 2010 and has been used across more than 200 million downloads. It was originally designed to solve a performance problem on resource-constrained devices, rather than a browser security problem.

“We built Puffin 15 years ago because devices were too slow,” Shen says. “What we learned over 15 years is that the same architecture that solved performance also gives us a fundamentally different security boundary that is critical in the age of AI.”

Puffin Cloud Security splits the browser across two machines. A display-rasterization component on the device handles about 5% of the browser’s workload. HTML rendering, script execution and the remaining 95% run on CloudMosa’s cloud servers. When a user opens a site, the cloud side loads and renders the page and sends the result to the device, which draws it on screen. A standard Chrome browser, or a hardened Chromium build with added controls, runs the rendering engine and the page’s code on the endpoint.

CloudMosa engineered the client component as a small, hardened bastion host with little code and few features for an attacker to target. The cloud renderer contains the large, feature-rich code where browser vulnerabilities concentrate. The server sends rendered output to the client in a PostScript-based format, and CloudMosa designed that exchange so malicious code running in the cloud renderer has no direct path to execute on the device.

AI browser agents raise the stakes for browser isolation

AI agents change the browser’s security model because they don’t just view web content — they act on it. A browser agent may read email, work inside SaaS applications, submit forms and use stored credentials, often moving through several steps without asking the user to approve each one. If an attacker compromises that environment, the prize is no longer just the browser session. It can include the authority the enterprise has delegated to the agent.

That makes isolation between users, agents and individual tasks increasingly important. Credentials needed for one task shouldn’t remain available to the next, and compromising one agent session shouldn’t give an attacker persistent access to everything the user has authorized. Disposable execution environments can limit how far a compromise travels.

Much of the enterprise discussion around agent security has focused on permissions: what an agent should and shouldn’t be allowed to do. But those controls depend on the environment enforcing them remaining trustworthy. As agents gain more authority, Shen argues, enterprises also need to consider where their browsers process the untrusted web content those agents encounter.

“Policy can define what an agent should be allowed to do, but policy assumes that the environment interpreting and enforcing those rules is still trustworthy,” he says. “If the browser execution environment itself is compromised, the attacker is no longer just another user who has to obey the enterprise’s rules.”

As AI agents gain more authority in the browser, enterprises have more at stake than winning the race to find and patch vulnerabilities. They also need to decide how much untrusted code should be running on employee devices at all. Shen argues that this puts a question largely missing from browser security investment back on the table: whether enterprises need an alternative to the dominant execution model.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.