Clear profile isolation
Each profile keeps its own browser state, settings, and process ownership.
Security
Security starts with a smaller trust boundary
Isoline is being designed so browser execution and sensitive profile contents stay local by default. Every cloud, team, update, and automation boundary must earn narrowly scoped access.
Release gates
Evidence before availability
The private alpha will open only after the core browser, profile lifecycle, update, and recovery paths meet their quality gates.
Local-first by default
Browser execution and sensitive profile contents remain on your device unless you enable encrypted sync.
Controlled team access
Ownership, locks, roles, and audit history keep handoffs explicit and accountable.
Scoped automation
API and MCP access follows the same permissions and never exposes secrets in normal output.
Security
Sensitive profile data stays local by default
Each profile uses its own browser state and local encrypted storage, with keys protected by the operating-system credential store. Isoline does not send profile contents to the cloud unless you explicitly enable a supported encrypted-sync workflow.
Team sync is optional and encrypted before upload
Planned team sync encrypts sensitive profile contents on the client before they leave the device. Roles, ownership, profile locks, version history, and audit events limit who can act and make approved handoffs traceable.
Updates and automation stay inside narrow permissions
Application and browser updates must be signed, verified, and recoverable. Local APIs and MCP operations use scoped authorization, while normal logs and automation output exclude raw cookies, passwords, proxy secrets, two-factor secrets, and encryption keys.