Tenant browser profile
Browser profile paths are represented in the tenant runtime environment and artifacts.
Browser Sidecar
Browser Sidecar is the implemented server-side browser isolation layer for Wize Browser and managed web agents. It keeps browser runtime state and artifacts tied to a tenant boundary while the public employee assistant and process-mining workflows remain directional.

Browser Sidecar gives Wize Browser and managed agents a concrete server-side browser runtime instead of a shared, unmanaged browser profile. Hermes Hub tenant runtime evidence includes browser-enabled state, Camofox URL and configuration, browser profile paths, browser auth artifacts, and storage/workspace links scoped to the tenant runtime boundary.

Browser profile paths are represented in the tenant runtime environment and artifacts.
The proofed runtime metadata includes browser-enabled state and Camofox configuration.
Browser auth artifacts, storage, workspace links, and runtime files are represented under tenant boundaries.
The sidecar provides an implemented boundary for browser work operated through Hermes Hub.
Wize Browser is the web-work surface, Browser Sidecar is the server-side browser boundary, and Hermes Hub is the managed runtime and control plane. Together they connect browser work to the same tenant-aware agent system without treating directional UX as shipped functionality.
Browser work stays connected to a tenant-scoped runtime boundary.
The Wize Browser page describes the Chrome MV3 extension and managed web-work surface.
Hermes Hub hosts and governs the tenant runtime that carries browser state and policy.
Evaluate browser boundaries alongside tenant identity, managed credentials, policies, storage, and evidence.
The implementation evidence supports a tenant runtime boundary; it does not by itself claim universal privacy, security, or compliance guarantees.
The public user-facing Chrome extension assistant and process-mining workflow remain product direction until separately approved implementation evidence exists. Browser Sidecar is the implemented layer; assistance and automation promotion are the target experience around it.
Visible help and review remain the intended workflow.
Target UX: page-aware help while an employee works in their own browser.
The intended flow keeps browser actions visible to the employee before any repeatable automation.
Workflow discovery and automation suggestions stay directional until source-backed implementation evidence exists.
Do not read the sidecar's runtime proof as evidence that the public assistant or process-mining experience is fully launched.
Use these pages to move from the implemented browser boundary to adjacent product, platform, and governance context.
The web-work surface: Chrome extension, page context, and reviewed browser actions.
ExploreTenant boundaries, credentials, policies, browser controls, and operational evidence.
ExploreDirectional employee-facing browser assistance, with the shipped boundary stated separately.
ExploreMap tenant browser isolation, runtime browser state, and future browser-assistance workflows with the Bewize team.
Architecture conversation
Share your deployment boundary, number of agents, work surfaces, and governance requirements. We will reply by email to arrange a focused technical discussion.
Email the Bewize teamThis opens your email application. Read our Privacy Policy.