Description
Workspace Role-Based Access Control gives every human and agent principal an explicit authority baseline instead of relying on scattered role checks. A platform permission catalog names the actions Dots recognizes, immutable system-role baselines bundle those permissions, and the additive evaluator resolves a principal’s effective access. Services consult the same asynchronous can() seam before protected work, so local development, API credentials, and hosted sessions share one authorization decision model.
The model is deliberately deny-free: narrower access is expressed by granting less, while per-Dotabase grants can add resource-specific authority. Denied actions fail closed and produce a typed response rather than silently falling through. This makes security behavior predictable for administrators and gives product surfaces a server-resolved permission set for hiding unavailable actions without reimplementing policy in the browser.
Selling Points
- Replaces inconsistent module-specific role mirrors with one platform-wide permission vocabulary, reducing surprising authorization differences between workflows.
- Applies equally to human users and agents, so automated work does not inherit an undefined or overly broad authority posture.
- Keeps enforcement active in every runtime mode, including local dogfood environments where database RLS may not be the operative boundary.
- Gives the UI authoritative effective permissions, allowing navigation and controls to fail closed while a session is unresolved.
- Preserves understandable administration through familiar system roles without introducing a conditional policy language.
User Story
A workspace owner assigns a teammate the Editor system role and an automation agent a narrower authority set. The teammate can create and update content but cannot administer access, while the agent is stopped at the same service boundary when it attempts an ungranted operation. The owner walks away with one comprehensible policy model governing both interactive and automated activity.
Extension Surface
This capability is fixed_core. The canonical atoms in packages/access/src/catalog.ts, baselines in packages/access/src/baselines.ts, and evaluation algebra in packages/access/src/evaluate.ts are platform security contracts rather than a plugin interface. Consumers may call the injected AccessLike seam in packages/access/src/contracts/access-like.ts, but they cannot replace the authority model through a supported external registration point.
Capabilities & Limits
- Resolves workspace permissions from assigned system and custom roles and exposes allow, deny, or approval-required decisions.
- Filters resource reads and protected mutations through a shared, fail-closed service gate.
- Provides additive permissions only; there are no explicit deny rules or arbitrary conditions.
- Does not provide row- or view-level ACLs. Those resources inherit their Dotabase access boundary.
Implementation Map
packages/access/src/catalog.tspackages/access/src/evaluate.tspackages/access/src/contracts/access-like.tspackages/api/src/routes/access.ts