Owner → Workspace → Transactions → Items → Files
Map every new tool or report to this chain and you retain least-privilege access without additional policy engines.
Mental model
Atlas hierarchy mirrors how brokers work: Owners operate Workspaces, each Workspace contains Transactions, each Transaction contains Items (tasks, docs, tools), and Items link to Files. Every object carries workspace_id, so queries can filter before touching tool logic.
Effective access rules
Roles decide reach. Owners and Admins see every transaction in their workspace. Clients only see files tied to transactions they are explicitly invited to. MCP clients inherit the same rules, so a Slack bot used by a client cannot leak another workspace’s data.
- Owner/Admin: all Transactions, Items, Files in Workspace
- Client: only invited Transactions and their Items/Files
Permission evaluation order
Atlas denies by default. It then evaluates Owner/Admin relationship, followed by transaction membership, and finally falls back to deny. This keeps multi-tenant brokers safe even when they share the same MCP server URL.
- Deny by default
- Allow if Owner/Admin of the Workspace
- Allow if member of Transaction per permission
- Else deny
Multi-tenant guardrails
Because every query filters by workspace_id, there is no way for a client to enumerate another workspace. Even analytics exports keep workspace_id as the primary partition key so warehouses respect the boundary.
- All objects carry workspace_id
- Every query filters by workspace_id first
- Never let a Client select across workspaces
Schema notes
Atlas references these tables across the MCP stack. Use them when you extend the server via Prisma or SQL migrations.
| Surface | Tables |
|---|---|
| Core | users, workspaces, workspace_members, transactions, transaction_members, items, files, audit_logs, sessions, subscriptions |
| Auth & SSO | oauth_* tables, sso_providers, sso_domains, mfa_*, identities |
| Content & reports | files, item_files, reports, rapid_redfin_data_property_details |