Tier 3 — Browser agent

Tier 3 gives the agent a real browser — a full rendering engine, a JavaScript runtime, a cookie jar, a network stack — inside a microVM whose every outbound byte goes through a filtering proxy.

Capability

Runtime: microVM plus egress proxy

Structurally a tier 2 microVM with a browser supervisor and a mandatory network chokepoint.

The proxy is not optional and not bypassable. The guest has no default route other than the tap device into the proxy namespace, and DNS resolves only through the proxy's resolver. An agent that is prompt-injected into exfiltrating data has to do it through a logged, filtered, metered chokepoint.

That chokepoint already exists on a plain Tier 2 session today — confirmed live, the same generic per-session egress allowlist every tier uses. What this diagram describes beyond that (browser-specific, per-request/per-origin filtering; TLS inspection; a dedicated recorder) is real, useful, and unbuilt — but it's additional granularity on the same mechanism, not a different security property a plain Tier 2 session lacks. The honest reason a dedicated tier would eventually make sense is operational (a profile-warm pool, built-in recording), not a gap in isolation or egress control.

Why not run the browser at tier 2 or tier 4

The "Tier 2 with Chromium" column above is, concretely, what's actually built and confirmed live today — and it's perfectly usable for a straightforward case (our own test: boot, launch, navigate, read the page, done, in under 7 seconds end to end). The "Tier 3" column's advantages are the managed, Chromium-specific tooling on top — per-origin egress policy, built-in recording, a profile-warm pool — none of which exist yet. Reach for plain Tier 2 today; this comparison is the case for building that extra tooling later, not a reason to avoid Tier 2 now.

Latency

Warm means a pre-started browser with a blank profile loaded, claimed from the pool. First navigation is additional and site-dependent.

Browser profiles

A profile is the browser's persistent identity: cookies, local storage, IndexedDB, saved credentials state. Profiles turn "log in every run" into "log in once".

# create a profile and authenticate into it once, interactively
curl -sS "$WB_BASE_URL/browser/profiles" -H "Authorization: Bearer $WB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "acme-portal", "end_user_id": "eu_customer_4821" }'

# subsequent sessions start already logged in
curl -sS "$WB_BASE_URL/sessions" -H "Authorization: Bearer $WB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "tier": 3, "browser": { "profile": "bprof_9Lm2Kd" } }'

Automation surface

Three levels, choose by how much control the agent needs.

High-level actions

Model-friendly, retry-safe, and the recommended default.

curl -sS "$WB_BASE_URL/sessions/$SESSION/browser/act" \
  -H "Authorization: Bearer $WB_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "actions": [
      { "type": "navigate", "url": "https://example.com/invoices" },
      { "type": "wait_for", "selector": "table.invoices" },
      { "type": "click", "ref": "a11y:button[name=\"Export\"]" },
      { "type": "wait_for_download", "timeout_ms": 20000 }
    ],
    "observe": ["a11y_tree", "screenshot"]
  }'

Elements are addressed by accessibility reference (a11y:…) in preference to CSS selectors, because the accessibility tree is what the model can actually see in the observation payload and is far more stable across redesigns.

Playwright-compatible

Drive the session from existing Playwright code by connecting over CDP:

const browser = await chromium.connectOverCDP(session.browser.cdp_url)

Raw CDP

wss://connect.workspaces.build/v1/sessions/{id}/cdp?token=wb_st_…

Full Chrome DevTools Protocol. The platform proxies, authenticates and records; it does not restrict CDP domains beyond what the egress policy already enforces.

Observation payloads

a11y_tree is deliberately the default. A full DOM snapshot of a modern page can exceed a hundred thousand tokens; the pruned accessibility tree for the same page is usually under three thousand.

Metering

browser_page_s is the meter teams overlook. An agent that opens tabs and never closes them bills for all of them concurrently.

Operational notes

• Bot defences are a real failure mode. Sessions egress from platform address space. For sites that block datacentre ranges, attach a customer-supplied upstream proxy on the egress policy.
• Downloads are quarantined. Files land in /downloads, are scanned, and are only readable through the filesystem API. They are never auto-executed.
• Recording defaults to off for cost and privacy. Enable it per session, and set a retention period — recordings of a logged-in session contain whatever was on screen.

When to move up to tier 4

The target is not a web page: a native desktop application, an installer, a thick client, an OS dialog. If it renders in a browser, tier 3 is both cheaper and faster.