Access Control

A full authorization engine — define who can do what, enforce it everywhere, and prove it.

The model

Everything lives inside a Scope. Scopes isolate tenants — what happens in the Marketing workspace stays in the Marketing workspace.

Inside a scope, you create Permissions — the smallest unit of access. documents:read → allow. billing:delete → deny. Permissions support wildcards and ABAC conditions.

Permissions are bundled into Roles. Instead of assigning 20 permissions per user, create a "Viewer" role once and assign it everywhere. Roles inherit from parent roles — "Content Editor" extends "Viewer" with write access.

An Access Policy connects a subject to a role in a scope. Alice is a Viewer in workspace-eng. A subject can have multiple policies across different scopes.

At runtime, an Access Check resolves policies, walks role hierarchies, applies deny-over-allow, and returns true or false. Single-digit milliseconds.

Every check is logged to the Audit Log — an append-only, HMAC-chained trail that an auditor verifies independently. No trust required.

Core concepts

Page	What it covers
Scopes	Tenant isolation, workspace hierarchy, inheritance
Permissions	Resource:action pairs, wildcards, conditions
Roles	Bundling permissions, role inheritance, templates
Access Policies	Subject-to-role binding, time-bounded grants
Access Check	Runtime evaluation, bulk checks, performance
API Keys	Machine-to-machine auth, management vs application
Audit Log	Immutable trail, verification, compliance export