Admin

Decide who may do what inside a workspace, and run the instance that workspace lives on.

Administering Dots covers two jobs: deciding who may do what inside a workspace, and running the instance that workspace lives on. The pages in this section cover both.

There is no separate administrator product to learn. One authorization model governs a person clicking through the app, an AI agent connected over MCP, and a script calling the API, so a decision you make in one place holds in all three.

In the app, workspace administration lives under Settings → Workspace → Access. Every surface there also exists as a dots access command, and the command line is the wider of the two.

Key Features

  • One-Company Tenancy — every operation runs inside exactly one company, named by an explicit selector (--company on the CLI, x-dots-company on the API) and checked against your memberships.
  • Principals Cover People And Agents — a person and an agent are the same kind of actor, so an agent's actions stay attributable to the agent rather than to whoever created it.
  • Four Immutable System Roles — Owner, Admin, Editor, and Viewer are seeded into every company, each a strict superset of the one below.
  • Custom Roles From Permission Atoms — when none of the four fits, build a role from the closed catalog that dots access catalog prints.
  • Additive-Only Authority — there is no deny rule anywhere in the model, so restricting a principal means granting it less.
  • Per-Dotabase Grants — narrow a principal to specific Dotabases instead of the whole workspace.
  • Scoped Credentials — a token carries a subset of what its principal already holds, is stored as a hash and a prefix, and is shown exactly once at issue.
  • Append-Only Audit Ledger — authority changes and denials alike are recorded, and read back with dots access audit.

Get Started

Resources

  • Access Control — the whole authorization plane: atoms, grants, credential scoping, approvals, and the audit ledger.
  • Access And Tenancy — the full company-resolution order, including what a browser session does instead.
  • Self-host Dots — the deployment reference, covering bring-your-own Postgres, S3-compatible storage, and connector keys.
  • CLI Overview — installing dots and how each invocation resolves its instance, its identity, and its company.

Get Started