Cloud-Based Internet Isolation (CBII) Explained

• Cloud-Based Internet Isolation (CBII) is an enterprise security model that uses containerized cloud environments to isolate and mediate web requests.
• It functions as a centralized decision layer that enforces varied policies like 'allow', 'isolate', and 'isolate, read-only' while generating telemetry for network monitoring.
• CBII supports risk-adaptive, hybrid edge-cloud mediation, enabling dynamic isolation adjustment and enhanced protection against commercial tracking and cyber threats.

Searching arXiv for the cited papers to ground the article in current literature. arXiv search query: (Master et al., 12 Feb 2026) Cloud-Based Internet Isolation (CBII) is an enterprise security model in which web requests are mediated by cloud infrastructure before content is presented to the user’s browser. In the Army/DoD deployment studied in "Tracking The Trackers: Commercial Surveillance Occurring on U.S. Army Networks" (Master et al., 12 Feb 2026), CBII is described as an Infrastructure as a Service capability, provided by Menlo Security, that creates a “containerized,” isolated environment in cloud infrastructure for web requests. Within that study, CBII appears simultaneously as a browser/web isolation platform, an enterprise web policy enforcement point, a security control, a privacy-relevant control, and a telemetry source. Adjacent work extends the CBII lens in two directions: hybrid edge-cloud mediation for browser-based AI agents, and risk-adaptive escalation from shared execution to stronger process isolation when suspicious behavior is detected (Lan et al., 24 Mar 2026, Schwarzl et al., 2021).

1. Definition and enterprise role

In the Army context, CBII is positioned as an enterprise security service on unclassified networks, specifically on the Army CONUS NIPR portion of DoDIN-A. The system is intended to isolate browsing associated with cybersecurity risk, prevent threats such as malware from reaching user devices, remove trackers and unwanted code from websites, deny access to prohibited content, and reduce throughput requirements on DoD networks (Master et al., 12 Feb 2026).

The deployment history is operationally significant. CBII was ordered for all NIPR DoDIN-A users by NETCOM and JFHQ-DoDIN in 2021, with implementation intended to complete by 2024, and with policy enforcement beginning in January 2024. Because the first measurement window covered February and March 2024, the observational record captures traffic shortly after enforcement began. This timing matters because it places the reported tracking exposure in the early period of policy enforcement rather than in a pre-deployment baseline.

CBII’s enterprise role in this setting is therefore broader than malware detonation or browser remoting alone. It functions as a centralized decision layer over web access, while also generating telemetry that can be used to characterize what users and systems on Army unclassified networks are connecting to most often. A common misconception is that deployment of CBII by itself implies comprehensive privacy protection; the Army study explicitly does not make that claim.

2. Policy model and architectural semantics

The policy model described for CBII has four actions: “allow”, “isolate”, “isolate, read-only”, and “blocked.” Under “allow,” there is no CBII isolation and traffic communicates directly with the website or resource through DoDIN infrastructure. Under “isolate,” a dynamic or interactive website is isolated in CBII cloud infrastructure. Under “isolate, read-only,” the website is rendered non-interactive and isolated; CBII strips unnecessary code and serves only rendered or static content. Under “blocked,” access is denied (Master et al., 12 Feb 2026).

This taxonomy is central to interpreting CBII effectiveness. The Army study emphasizes that the analyzed dataset consisted entirely of URLs labeled under “allow.” Those requests therefore bypassed the privacy and security benefits of CBII isolation even though they remained visible through the CBII ecosystem. The study consequently shows what Army users access when CBII governance permits direct access, rather than what isolated browsing would look like under stricter configuration.

The report also notes that CBII often excludes military or government-owned websites and commercial websites whitelisted by mission partners that govern their own network segments. This decentralization matters because different mission partners can make policy choices that leave tracker-containing destinations in the “allow” path. The paper is explicit that websites in “allow” are not isolated by CBII, and in those cases third-party trackers are handled by the end user’s browser, which allows tracking and collection of their data.

A second common misconception concerns the equivalence of isolation modes. The Army report states that “isolate” is not equivalent to “isolate, read-only.” If users are logged into authenticated accounts such as Google or Facebook, standard isolation still permits server-side correlation of activity across devices and sessions. By contrast, “isolate, read-only” strips the DOM of unnecessary code, including tracking code, and renders only static content to the user. In privacy terms, policy-action selection rather than mere platform presence determines the effective protection boundary.

3. CBII as telemetry and measurement vantage point

The primary empirical study built a dataset from CBII-related data available through GABRIEL NIMBUS, Army Cyber Command’s big data platform. The authors obtained the top 1,000 URLs requested on the Army CONUS NIPR portion of DoDIN-A over February and March 2024, representing the most common web browsing activities of Soldiers and Army Civilians stationed in the U.S. who had DoDIN-A access while on duty. Classification was performed at the domain/subdomain level by comparing each URL’s domain or subdomain against Ghostery’s WhoTracks.Me database (Master et al., 12 Feb 2026).

The paper distinguishes two positive Ghostery classes. “Trackers” are tracker domains or endpoints designed to receive user data from AdTech, such as tracking pixels. “Websites” are front-facing websites that include tracking code. The study treats tracker domains as the main estimate of tracking prevalence because they are explicit data-collection endpoints, and therefore a conservative estimate.

For the first dataset, the implicit set structure is: $D = \{d_1, d_2, \dots, d_{1000}\},$ with $D$ reduced to domain/subdomain level for classification. The paper reports: $$|D| = 1000,\quad |T| = 212,\quad |W| = 104,\quad |N| = 684,$$ where $T$ denotes tracker domains, $W$ denotes websites with tracking ability, and $N$ denotes domains without tracking classification or unlisted in Ghostery. The corresponding proportions are 21.2\% tracker domains, 10.4\% websites with tracking ability, and 68.4\% without tracking classification. In aggregate, 316 of the top 1,000 domains or resources, or 31.6\%, were associated with tracking in some way.

The category breakdown of the 212 tracker domains in the first dataset was: Site Analytics at 46.70\%, Advertising at 26.89\%, Hosting at 13.21\%, Audio/Visual Player at 7.55\%, Unknown at 3.77\%, Customer Interaction at 0.94\%, and Miscellaneous at 0.94\%. The study highlights that 57 of the top Internet resources were advertising-related trackers. At the entity level, Adobe Experience Cloud and Marketo (owned by Adobe Inc.) together account for over 36\% of the total tracker domains in the sample. Other prominent entities included Akamai Technologies, Quantum Metric, Contentsquare, Datadog, Microsoft Clarity, Doubleclick, Criteo, TikTok Analytics, New Relic, Pendo.io, OpenX, Pubmatic, Trade Desk, and TripleLift.

A second pull for November–December 2024 largely reinforced the first round. It found 192 tracker-only domains (19.2\%), 98 websites with tracking ability (9.8\%), and 710 domains without tracking classification (71.0\%). The second dataset also included connection counts. Let $c(d)$ be the number of connection requests for domain $d$. Then the top-1,000 total was 2,285,724,454 requests, while tracker-domain traffic was 957,499,496 requests, yielding a tracker-domain request share of approximately 41.89\%. This indicates that tracker domains were not only common by unique-domain count, but also highly prominent in aggregate request volume.

4. Privacy, commercially available information, and operational security

The Army report frames CBII’s privacy relevance in terms of commercial surveillance on military networks. It connects web tracking to privacy harms, microtargeting of military-affiliated populations, force protection risk, OPSEC degradation, exposure of patterns of life, possible linkage between government-device activity and personal-device identity, bandwidth and infrastructure burden, and cyber risk from AdTech and malvertising (Master et al., 12 Feb 2026).

The study emphasizes that AdTech can collect or help derive PII, geolocation, email, phone number, home address, preferences, browsing habits, clicks, time on page, browser characteristics, and session/device identifiers. The report’s concern is not that each telemetry field is always sensitive in isolation, but that aggregation and correlation, especially when combined with browser fingerprinting and cross-device advertising technologies, can identify users and reveal mission-relevant behavioral patterns. The discussion of Criteo is particularly direct: its cross-device tracking capabilities are presented as potentially linking government-device behavior with personal-device behavior and revealing patterns of life detrimental to force protection.

The study also names concrete domains present in Army traffic, including analytics.tiktok.com, www.google.cn, and www.grlvelxstuff.com. The presence of the TikTok analytics endpoint is especially important in the report’s narrative because it ties a CBII-observed domain to larger federal restrictions and foreign-risk concerns.

From a mitigation perspective, the paper’s most explicit CBII recommendation is that tracker domains should not remain assigned to “allow.” It also recommends that commonly used websites containing tracking code be moved to “isolate, read-only,” and that mission partners could designate all uncategorized websites as “isolate, read-only.” These are presented as “relatively minor configuration changes” because they involve policy reassignment within existing CBII capabilities rather than acquisition of a new platform.

The report complements those direct CBII changes with defense-in-depth measures. It recommends reviewing Intune defaults and GPOs for NIPR workstations and Azure Virtual Desktop to ensure browsers are configured to block tracking content, cross-site cookies, and unnecessary scripts or code; transmitting Global Privacy Control (GPC) and Do Not Track (DNT) by default; using DNS blocklisting of tracker domains; adding “Advertising” and “Tracking” as formal content categories in DoDI 8025.AA and related policies; revising contracting language to require minimization of data collection, government control over telemetry or user data, and restrictions on third-party transfer; and educating service members and civilian employees about commercial tracking, commercially available information, and brokers.

5. Hybrid edge-cloud mediation and browser-based AI agents

"The Cognitive Firewall: Securing Browser Based AI Agents Against Indirect Prompt Injection Via Hybrid Edge Cloud Defense" is not classical CBII in the RBI sense, because it does not remote-render the browser and does not isolate all webpage code execution in the cloud. Instead, it proposes a three-stage split-compute architecture for browser-based AI agents: a local visual Sentinel, a cloud-based Deep Planner, and a deterministic Guard at the execution boundary. The paper therefore aligns with CBII most strongly at the architectural-pattern level: cloud mediation, split compute, defense-in-depth, centralized inspection, and execution control (Lan et al., 24 Mar 2026).

The paper’s core threat model is Indirect Prompt Injection (IPI), in which trusted instructions and untrusted web content are processed together inside the model’s context window. The authors describe this as a collapse of the control plane and the data plane. In this setting, classical browser safety properties are insufficient because the attack is not only about code execution; it is also about the semantic compromise of the agent’s reasoning and action planning.

The local Sentinel enforces perceptual integrity by screening the DOM and computed style information for hidden or obfuscated content. Its decision function is given as

$f_{sentinel}(DOM) \to \{Safe, Blocked\},$

with a blocking condition

$$Condition_{block} = (opacity < 0.1) \lor (font-size \approx 0) \lor (pos \notin Viewport).$$

If Layer 1 returns Safe, only sanitized, text-based context is sent to the cloud Deep Planner for semantic reasoning. The final deterministic Guard validates the returned plan $D$0 against a local policy $D$1 and a trusted domain set $D$2, enforcing an origin constraint and a verb-policy constraint before the browser executes the action.

The experimental results are relevant to CBII-style design tradeoffs. Across 1,000 adversarial samples, Edge Only (Layer 1) had an ASR = 86.9\% on semantic attacks, while the full hybrid architecture reduced overall attack success rate to 0.88\% under static evaluation and 0.67\% under adaptive evaluation. The paper also reports an approximately 17,000x latency advantage for local presentation-layer filtering over cloud-only baselines, with Edge Sentinel mean latency at $D$3 ms and Cloud Planner mean latency at $D$4 ms. The paper’s three explicit security invariants—Visual Consistency, Goal Integrity, and Execution Safety—suggest an extension of the CBII idea from runtime isolation toward cognitive mediation and action-safe browsing for autonomous agents.

The work also states a limit that matters for CBII interpretation: RBI does not automatically solve IPI, because the danger is not just code execution on the endpoint but the cognitive manipulation of an autonomous model by page content. In that sense, the paper complements CBII rather than replacing it.

6. Risk-adaptive isolation and shared execution environments

"Dynamic Process Isolation" addresses a different but structurally related problem: providers want to multiplex many untrusted tenants cheaply in a shared runtime, yet microarchitectural leakage breaks the assumption that language or runtime sandboxing alone is sufficient. The paper demonstrates a remote Spectre attack against Cloudflare Workers and reports a practical leakage rate of 120 bit/h, motivating Dynamic Process Isolation (DPI) as a selective escalation mechanism: keep the efficient shared-process model for the common case, but dynamically move suspicious code into separate processes when its execution profile resembles a Spectre attack (Schwarzl et al., 2021).

The paper’s environment is a single-process, multi-threaded edge-worker platform in which there can be multiple thousand workers from up to 2000 tenants inside one process. The authors show why this matters for CBII-like systems: if unrelated untrusted workloads share an address space, microarchitectural attacks can bypass language/runtime sandboxing. The paper therefore supports a concrete design principle for CBII: shared-process execution is attractive for performance and density, but it weakens the security baseline when co-tenancy is adversarial.

DPI monitors workers using hardware performance counters and isolates suspicious workers into separate processes. The production detector normalizes retired branch instructions by iTLB accesses and uses a threshold of

$D$5

At that threshold, the paper reports an average false-positive rate of 0.61\% across 5 Intel Xeon server CPUs, 1 AMD EPYC Rome CPU, and production workloads. The paper also reports that, in the worst case of only false positives, Dynamic Process Isolation simply degrades to process isolation, with the conceptual result that worst-case DPI approximates strict process isolation plus a small detection overhead.

For CBII, the significance is architectural rather than literal. The paper is highly informative because it provides a concrete strategy for moving from “always shared” versus “always dedicated” toward risk-adaptive isolation. A plausible implication is that similar escalation logic could be applied to browser sessions, tabs, renderers, or web-content workloads, although the paper also emphasizes a major difference: Cloudflare Workers are stateless, whereas browser sessions are not. As a result, dynamic isolation is better understood as an optimization layered on top of a strong isolation architecture than as a universal replacement for strict process isolation.

7. Scope, limitations, and unresolved questions

The Army tracking study is careful not to overclaim about CBII. Its primary window covers only February–March 2024, with replication in November–December 2024; it analyzes only the top 1,000 most requested resources; and its scope is limited to Army CONUS unclassified networks. The authors also state that the vantage point is only from the perspective of CBII and is not end-to-end. Some tracker domains visible in CBII “allow” data may still be blocked later by IP blocking, DNS sinkholing, or controls near Internet Access Points. The report therefore measures exposure and requested connectivity visible from CBII’s position rather than guaranteed successful end-to-end tracker communication (Master et al., 12 Feb 2026).

A further limitation is that Ghostery classification is conservative and time-sensitive. Domains not classified as trackers may still host tracking functionality, and the first dataset did not retain per-domain request counts long enough for later analysis. The report also states that CBII cannot prevent all commercial tracking activity on its own because telemetry collection embedded into desktop software contacts tracker endpoints outside the context of a web browser. Finally, the paper recommends configuration changes but does not experimentally implement them within CBII and measure before/after reductions.

The AI-agent security work introduces a different set of limits. The Sentinel performs no pixel-level or full multimodal analysis; prompts hidden in images or QR-style visual channels bypass Layer 1. End-to-end latency can reach around 950 ms when cloud reasoning is required, and the system reports a 1.7\% false positive rate on benign tasks due to rigid allowlist-based blocking at Layer 3. The paper also notes that static allowlists are not enough and that human confirmation is not yet integrated (Lan et al., 24 Mar 2026).

The dynamic isolation work carries its own caveats. DPI depends on detection quality, threshold calibration, and hardware-counter availability. It does not eliminate all residual side channels, and attackers can attempt to reduce their branch-intensity signature at the cost of lower leakage rate. The paper itself notes that different Spectre variants may require different signals, as shown by the need for an additional counter for Spectre-STL (Schwarzl et al., 2021).

Taken together, these studies delimit CBII in a precise way. CBII is already valuable as a visibility and enforcement point, but its effective protection depends on policy configuration, trust boundaries, and the specific threat model. It can expose enterprise-scale tracking, mediate risky browser-agent cognition, and motivate adaptive escalation in shared cloud execution. It is not, on the evidence summarized here, a complete solution to commercial surveillance, server-side identity correlation, non-browser telemetry, indirect prompt injection, or all forms of microarchitectural cross-tenant leakage.