Concepts
Roles, grants, and tenant isolation
Access is computed as role baseline plus explicit grants minus denials. Domain visibility and response scopes are first-class permissions. Tenants are isolated in Postgres, graph, and API queries. Browsers never hold the API bearer token or self-assert roles.
The four canonical roles
The platform uses four roles: user, power_user, admin, and super_admin. Legacy names (executive, viewer, analyst, responder) still normalize into this set for older sessions and memberships.
user is read-oriented Operate and Investigate access. power_user adds incident management and response:request. admin adds assign, approve, integrations, detections, workspace, members, automation authoring/publish/approve, and response scopes. super_admin is not a tenant SOC role: it receives only access_reviews:manage and platform:admin, and middleware confines it to Access Review.
| Role | Typical landing | What they generally receive |
|---|---|---|
| user | Command Center | Operate + Investigate reads; automation:read; domain reads; escalate |
| power_user | Incidents | Analyst work plus response:request and automation:run |
| admin | Workspace / Admin | Full Configure authority including detections, integrations, automation authoring, response scopes |
| super_admin | Access Review | Platform onboarding review only — no tenant telemetry or incident surfaces |
Effective permission formula
Workspace membership rows can add grants or denials on top of the role baseline. Effective permission is (baseline ∪ grants) − denials. Domain reads such as domains:edr:read gate Investigate destinations in the shell. detections:manage gates Detection Engineering edits and Hunt Ledger’s Run hunt now. workspace:manage gates /workspace and /admin. access_reviews:manage gates /admin/applications.
The Next.js middleware enforces several of these path gates server-side. Even if a link were somehow visible, a principal without the permission is redirected to /access-denied (or receives 403 on API routes).
Workspace versus Admin versus Access Review
Workspace (/workspace) is the customer-facing tenant control plane: organization profile, people, groups, access matrix, security posture drafts, apps & services toggles, devices, connector pause/resume, data routing inspectors, notifications, billing scaffold, reporting schedules, and audit export.
Admin (/admin) is the technical administration surface: company settings, authentication posture readout, RBAC matrix editing, and endpoint inventory import used by Infrastructure Map correlation.
Access Review (/admin/applications) is Super Admin only. It decides private onboarding applications. Approving provisions tenant workspace membership and attempts credential email when mail is configured. This role intentionally cannot open tenant Incidents, Hunt Ledger, or telemetry surfaces.
Tenant isolation and identity proxying
API principals carry tenant identity from the signed web session via the Next.js /api/beacons proxy. The browser does not hold the API bearer token and does not choose its own role headers. The proxy derives x-beacons-subject, x-beacons-roles, and a signed user identity token from the verified session.
Queries on incidents, telemetry, hunt runs, automation, assets, and related tables filter by tenant_id. Cross-tenant access returns empty or 404 . not another organization’s rows. In local development without an organization membership row, the API may fall back to DEFAULT_TENANT_ID when ENVIRONMENT=local; production requires active membership.