Browser security is shifting execution away from endpoints

The browser-security question is shifting from detection to execution

Enterprise security teams increasingly need to decide where web code may execute. Gartner projects that more than 85% of enterprise workloads will be accessed through the browser by 2027, while industry reports say browser-based attacks have surged over the past two years. Those trends make the execution boundary consequential because the browser processes remote content while maintaining authenticated enterprise sessions.

Those authenticated sessions now carry SaaS platforms, CRM and ERP systems, collaboration tools, and LLM-powered workflows. Enterprise applications increasingly use the browser as both their access point and workspace, while autonomous AI agents are beginning to operate through the same sessions. As more valuable work moves into this environment, security teams have to consider what code may run there and which machine runs it.

Shioupyn Shen, founder and CEO of CloudMosa, the company behind Puffin Cloud Security, argues that this shift changes the browser’s role: “The browser is no longer just another application running on the endpoint.” CloudMosa benefits commercially when enterprises adopt its cloud-browser approach, so Shen’s interpretation also supports the company’s product strategy. His technical argument is that conventional browsers interpret remote code locally, while enterprise use increasingly demands stronger isolation and policy enforcement around that execution.

The distinction creates a concrete design question. A conventional browser allows active remote code to reach an endpoint and execute there, after which security layers can identify, restrict, or respond to what happens. As enterprise work and AI agents concentrate in authenticated browser sessions, security teams can ask whether original active content needs to execute on the endpoint at all.

AI makes local browser execution harder to defend with detection alone

Execution location matters because of the browser’s normal operating model. A tab can receive JavaScript, WebAssembly, and other web content from remote systems, interpret it locally, and operate while the browser holds authenticated sessions for enterprise applications. Malicious scripts, credential theft, supply-chain compromise, and other browser exploits can consequently enter an execution environment that already has access to valuable accounts and data.

Once remote content executes locally, detection-first controls face a timing constraint because inspection and response may follow the start of execution. Dynamic or obfuscated JavaScript and WebAssembly can run before endpoint defenses respond, so a short-lived or fileless attack may have time to steal credentials or exfiltrate data. The sequence matters even when detection ultimately finds the attack because the browser has already given the content an opportunity to act.

AI puts more pressure on that interval because attackers can automate malware generation, mutation, and deployment. One reported figure puts the increase in attacks by AI-enabled adversaries at 89% over the past year. At that pace, defenders can encounter new variants faster than signature-based systems can analyze earlier samples and refresh detection rules.

Those variants matter because polymorphic malware changes its code or behavior between instances, making a signature learned from an earlier sample less useful. Fileless and malware-free techniques can use legitimate tools, compromised sessions, or malicious web content, leaving conventional file scanners with no malicious file signature to inspect. Attack volume consequently combines with variation and execution speed to increase the time pressure on classification.

That pressure is central to Shen’s case for changing the browser boundary. “Defenders are no longer just chasing more threats, they are chasing a machine that can keep creating new ones,” Shen says. He describes the expected pace of change even more strongly: “What was good enough in the past 10 years will not be sufficient in the next six months.”

Detection still provides information and response capabilities that enterprises need, but a later alert cannot reverse completed execution. If an attack can steal an authenticated session or exfiltrate information before a defensive decision arrives, lower detection latency still leaves an interval when untrusted remote code runs locally. The design question is whether the endpoint can avoid that exposure while preserving usable access to the application.

Shen argues that moving execution provides an alternative. “It is no longer sufficient to ask only whether a threat can be detected,” he says. He follows that claim with the design principle behind CloudMosa’s commercial approach: “The stronger approach is to prevent risky or malicious code from ever reaching the device in the first place.” For an enterprise evaluating the proposition, the technical question is whether users can interact with a web application without putting its original active content on their endpoints.

Puffin changes where active web code executes

Puffin Cloud Security implements that idea, so CloudMosa’s commercial interest is directly tied to the claim that remote execution improves security. “In a conventional browser, the risk comes to the device,” Shen says. “In an isolated cloud model, the risk is kept away from it.” The practical difference is which machine receives and processes executable web content before the user sees and interacts with the resulting page.

With Puffin, the original browser session runs inside an isolated, disposable cloud environment. JavaScript, WebAssembly, and other executable payloads are processed there along with the HTML rendering required to construct the page. The endpoint receives a rendered pixel stream, while clicking, typing, and scrolling send the user’s interactions back to the remote session.

Because that processing happens remotely, the endpoint does not parse, execute, or store the original active web code under Puffin’s design. Display rasterization, meaning the work that produces the pixels shown to the user, is the endpoint-facing part of the system. HTML rendering and active execution remain in the cloud, creating the separation behind CloudMosa’s security claims.

CloudMosa says display rasterization accounts for roughly 5% of a browser’s total workload. That estimate supports the company’s design argument because it divides browser processing into a relatively small endpoint display workload and a much larger cloud-side workload. On that model, the endpoint can provide an interactive browsing experience while the cloud handles the active code that creates the page.

From the same separation, CloudMosa claims that zero-day exploits and AI-generated polymorphic code have no executable payload running on the endpoint. The company also says fileless attacks, compromised SaaS content, and supply-chain threats remain inside the disposable cloud environment. CloudMosa sells the system that provides this containment, so enterprises evaluating those security outcomes should distinguish the observable execution boundary from the broader protection claims the company draws from it.

A compromised SaaS application shows how the boundary works. With conventional local browser execution, malicious active content delivered through that trusted service can execute where the enterprise session is already open. In Puffin’s model, the compromised content executes within the isolated remote browser session while the endpoint receives its rendered result, changing the boundary that web code would have to cross to execute locally.

CloudMosa describes the principle behind that choice as “paranoid by design.” In practice, the principle assumes a worst-case threat environment where hostile content can evade detection and endpoint defenses can fail, so isolation constrains where that content executes. Shen connects the principle directly to the implementation: “This is not just a philosophy, but something that is reflected directly in the architecture itself.”

That security use grew from an earlier reason to move browser processing into the cloud. CloudMosa originally built its cloud-browser approach to improve browser performance and accessibility because it expected enterprise work to move increasingly into the browser. As more processing moved to the cloud, the same separation between endpoint display and remote execution also became useful for containing hostile browser code.

Shen connects that history to the current threat environment: “CloudMosa originally built its cloud architecture to improve browser performance and accessibility, with the expectation that enterprise work would increasingly move into the browser. Today’s AI-assisted hacking has validated that architecture, demonstrating that what was designed for performance also provides a strong foundation for modern enterprise security.” The product’s emphasis has changed, but its underlying mechanism still moves substantial browser processing off the device.

CloudMosa characterizes the resulting shift as moving from “good-enough security on the device to airtight security in the cloud.” Because CloudMosa sells Puffin Cloud Security, “airtight” is a vendor characterization of the protection delivered by its design. Isolation specifically addresses exposure created by local web execution, while credentials, authorization, traffic policy, application access, and related security decisions remain separate control problems.

That narrower execution claim gives a security team a practical way to evaluate the design. The team can examine what happens when detection misses an obfuscated script, a previously unknown exploit, or malicious content delivered through a compromised SaaS supply chain. Under Puffin’s design, CloudMosa’s answer is that the code still executes, but its execution stays within a disposable cloud environment instead of the user’s endpoint.

Shen says CloudMosa adopted this harsher threat model earlier than most organizations and argues that today’s AI-assisted attacks make the posture increasingly relevant. His argument supports a market in which CloudMosa benefits from wider use of remote browser isolation, so the implementation can be assessed separately from the company’s broader characterization of its protection. The directly inspectable design choice is where active web code runs and what reaches the endpoint.

AI agents turn the browser into both a tool and a target

The execution boundary matters more when software itself operates the browser with a person’s authority. Autonomous AI agents can act through browser sessions with user-level privileges, giving malicious web content an active decision-making process to target alongside the browser software. Shen identifies prompt injection, session hijacking, and indirect compromise through compromised web content as particular risks for these agents.

Recent 2026 surveys found that 92% of security professionals are concerned about AI agents’ impact and 48% name agentic AI as the year’s top attack vector. Those concern figures align with a technical change in the browser session because an agent can exercise authority once it enters an authenticated workflow. The resulting risk depends on both what reaches the session and what actions the agent may take.

For a human user, malicious browser content can attempt to exploit software or steal a session. An autonomous agent adds another target because instructions and web content may influence what it decides to do while holding user-level permissions. Session integrity becomes especially important under that model because the agent can continue taking actions through the authority attached to a compromised or manipulated session.

CloudMosa proposes running an AI agent’s browser activity inside isolated cloud sandboxes, extending the same Puffin execution boundary to agent workflows. The endpoint receives the rendered pixel stream, and CloudMosa says this arrangement prevents malicious content from interacting directly with the device, its credentials, or connected systems. Because CloudMosa benefits commercially from applying Puffin to these workloads, that claim should be evaluated as a vendor security claim, while prompt injection and access decisions remain controls that isolation must work alongside.

Isolation fills a gap in the security stack

The agent case also shows where execution isolation fits with existing enterprise controls. Secure web gateways (SWGs), cloud access security brokers (CASBs), and zero trust network access (ZTNA) systems route traffic, enforce policy, and govern access, while detection systems identify threats and support response. CloudMosa argues that local browser execution leaves another control point: where active content runs after access and routing decisions are made.

Puffin is consequently positioned as a complementary layer to those investments, which also serves CloudMosa’s commercial interest in adding its product to existing security stacks. A security team can route selected high-risk sessions through an isolated cloud environment while its SWG, CASB, ZTNA, and other controls continue doing their existing jobs. “The goal is not to undo existing investments, but to make them more complete,” Shen says.

The same execution boundary changes how endpoint ownership affects browser policy. CloudMosa says browser-level policy can apply when a user connects over a VPN or a home network and when the device is enterprise-managed or an unmanaged bring-your-own-device (BYOD) system. These cases matter because enterprise browser sessions can extend across endpoints and networks where security teams have different levels of management authority.

On a managed device, isolation can cover a selected session even when endpoint controls are already present. An unmanaged BYOD device can route the corresponding browser workload through the cloud, reducing dependence on local execution controls. VPN and home-network cases preserve the same execution boundary because the active browser workload remains in the isolated environment regardless of the user’s immediate network.

That flexibility also allows selective adoption. Shen says organizations can begin with narrow cases such as high-risk SaaS access or AI-agent workflows and expand without disrupting tools already deployed. CloudMosa benefits if those trials expand into broader Puffin deployments, while the staged approach gives security teams a bounded way to assess execution isolation around sessions where malicious content could have serious consequences.

The resulting stack gives each class of control a distinct job. Access products decide who or what may reach a resource; gateways and brokers handle routing and policy; detection systems look for malicious activity; and browser isolation determines where the active web workload executes. Execution location is therefore a specific control boundary that teams can assess alongside those existing functions.

Architecture and implementation require separate evaluation

That division of responsibilities also helps separate Puffin’s mechanism from CloudMosa’s claims about the protection it provides. Gartner projects that more than 85% of enterprise workloads will be accessed through the browser by 2027, industry reports describe a surge in browser-based attacks over the past two years, and the 89% AI-enabled-adversary figure points to faster attack generation. The 2026 survey figures of 92% and 48% add a measure of professional concern about AI-agent risk.

Those contextual figures establish why browser execution is receiving more attention, while CloudMosa makes the specific security case for Puffin. The company also supplies the roughly 5% rasterization estimate that supports its endpoint-workload argument. Because CloudMosa sells the product and benefits when enterprises accept the case for remote browser isolation, its containment, zero-day-resistance, and related security claims should be evaluated with that commercial incentive visible.

The evaluation can separate two questions. The first is architectural: keeping original active web code in an isolated cloud browser changes where the code executes and what active content reaches the endpoint. The second is about implementation: a security team can test whether Puffin delivers the containment and zero-day resistance CloudMosa claims under the team’s own applications, policies, agent workflows, and threat assumptions.

Shen frames the underlying threat change as large enough to require companies to rethink the browser “from the ground up.” He puts the choice for security leaders more starkly: “redesign for foresight, or wait until hindsight makes the lesson unavoidable.” For teams evaluating that proposition, the concrete decision is where browser code and AI-agent browser workloads may execute, and which controls govern the sessions around them.

Key executive takeaways

• Make execution location a security decision: As enterprise workloads concentrate in authenticated browser sessions, security teams need to govern where active web code runs. Remote execution can reduce endpoint exposure before detection and response begin.
• Account for AI-driven attack speed: AI-generated, polymorphic, and fileless attacks increase the pressure on detection systems by creating rapidly changing threats. Security architects can evaluate controls that contain execution even when classification is late or misses a new variant.
• Test remote browser isolation against high-risk workloads: Puffin processes JavaScript, WebAssembly, and other active content in disposable cloud environments while sending rendered output to endpoints. Security teams evaluating this model should independently test CloudMosa’s containment and zero-day-resistance claims.
• Isolate AI-agent browser sessions: Autonomous agents combine authenticated access with the ability to act on web content, increasing exposure to prompt injection, session hijacking, and compromised content. Organizations deploying browser-based agents can place their sessions in isolated environments and tightly govern credentials and permissions.
• Add execution isolation to existing security controls: SWGs, CASBs, ZTNA, and detection systems address access, traffic, policy, and response, while browser isolation controls where active content executes. Enterprises can start with high-risk SaaS, BYOD, or agent workflows and assess whether isolation strengthens the existing stack.
• Separate architecture from vendor claims: Remote browser isolation creates an observable boundary by keeping original active web code away from the endpoint, while broader protection claims depend on implementation. Security teams can validate Puffin against their own applications, policies, workflows, and threat models before expanding deployment.