---
title: Cloud-Based Internet Isolation (CBII) Explained
url: https://www.emergentmind.com/topics/cloud-based-internet-isolation-cbii
type: topic
---

# Cloud-Based Internet Isolation (CBII) Explained

Searching arXiv for the cited papers to ground the article in current literature.
arXiv search query: 2602.12388
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" [2602.12388], 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 [2603.23791] [2110.04751].

## 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 [2602.12388].

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 [2602.12388].

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 [2602.12388].

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 [2602.12388].

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 [2603.23791].

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 \(P\) against a local policy \(\pi\) and a trusted domain set \(W\), 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 \(\mu \approx 0.06\) ms and **Cloud Planner mean latency** at \(\mu \approx 288\) 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 [2110.04751].

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
\[
\frac{\text{retired branch instructions}}{\text{iTLB accesses}} > 4096.
\]
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 [2602.12388].

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 [2603.23791].

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** [2110.04751].

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.

Source: https://www.emergentmind.com/topics/cloud-based-internet-isolation-cbii