# Workspaces and roles

> The workspace is the boundary for data, members, machines and keys; roles and group scope decide who may do what.

A **workspace** holds profiles, proxies, machines, automation, API keys and the audit log of one team. Nothing is shared between workspaces, and an API key always belongs to exactly one.

## Roles

| Role | Typical use |
|---|---|
| Owner | Full control, including ownership transfer and billing |
| Admin | Members, security, machines and every resource |
| Operator | Create, edit and run profiles within their scope |
| Viewer | Read-only access within their scope |

Each operation needs one capability (for example `session.start` or `profile.edit`); the [reference](https://browlix.com/en/docs/reference) shows it per operation. The web app, the API, MCP, the CLI and the worker all ask the same database decision, so they can never disagree about who may do something.

## Group scope

Members can see **all** profiles or only some **profile groups**. A group-scoped member — and every key they create — reads, opens and edits only the profiles in their groups. Tags are labels for filtering; they never grant access.

## Security settings

Owners can require two-factor authentication for the whole workspace. API keys keep working for automation, but only within what their member is allowed to do.

## Audit

Every command — from the app, a key, MCP or a machine — is recorded in an append-only audit log with the actor, the interface and the result (`accepted`, `denied` or `failed`). Read it with `audit.list`.