Teams

Roles and permissions

The workspace roles in Pathrule, how per-node overrides cascade to child paths, and how the database enforces every read and write the same way across Web, Desktop, CLI, and MCP.

Ask ChatGPT Ask Claude View as Markdown

Pathrule starts as a solo tool and grows into a team product. When you invite colleagues, the question becomes who can see and change what. This page covers the roles you assign, how access narrows from organization to workspace to a single path, and where the check actually runs.

The short version: roles are assigned at the organization level, access can be narrowed per workspace and per path, and every read and write is checked by the database against your signed-in user. The same check applies whether the request comes from Pathrule Web, Pathrule Desktop, Pathrule CLI, or the MCP server an AI client speaks.

The four roles

Roles are assigned per person at the organization level. An admin invites a colleague by email and picks their role; the colleague accepts the invite to join.

Role	Can do
Owner	Everything an admin can, plus transfer ownership. There is always exactly one owner, and the owner cannot be removed.
Admin	Invite and remove members, change member and viewer roles, switch workspaces between organization-wide and private, and set per-node permission overrides.
Member	Read and write content (memories, rules, skills) wherever they have access. The everyday contributor role.
Viewer	Read content wherever they have access. No writes.

A few guardrails follow from this:

An admin can change member and viewer roles, but cannot promote anyone to admin or change another admin. Only the owner does that.
An organization always keeps at least one admin. The last admin cannot be removed or demoted.
Transferring ownership is a deliberate, two-step action, and the previous owner becomes an admin.

Role changes and ownership transfer require a fresh re-authentication, so an old, ambient session cannot quietly escalate access.

Workspace access: organization-wide or private

A role sets what a person can do. A workspace's access mode sets who can reach it at all. Each workspace is one of two modes.

Organization-wide. Every member of the organization has access, at their org role.
Private. Only people explicitly added to the workspace have access. Org membership alone is not enough.

When you switch a workspace to private, Pathrule auto-adds the current org members first, then lets the admin remove whoever should not be there. The default is no accidental lockout: you take access away on purpose rather than risk cutting someone off by surprise. Inside a private workspace, a person's workspace role overrides their org role, so you can give someone a different level of access there than they have elsewhere.

Per-node overrides that cascade

Inside a workspace, knowledge attaches to repository paths. Permissions can attach to those same paths. A workspace admin can pin an override on any node that grants or removes access for a specific member, more narrowly than their workspace role would imply.

An override controls, per member:

Read access to the node.
Write access, split by content type: memories, rules, and skills.

Overrides cascade. An override set on /src/core applies to that node and to everything beneath it (/src/core/utils, /src/core/models, and so on) unless a descendant node carries its own override that says otherwise. The closest override down the tree wins, the same way the most specific memory wins. This lets you keep a workspace open by default and lock down one sensitive subtree, or do the reverse.

Because overrides resolve top-down with inheritance, the effect on any single path is predictable: start from the workspace role, apply the nearest override on the way down, and that is the access.

Losing access is non-destructive

Permission changes never destroy work and rarely hide it.

Lose write access to a path and the editor opens read-only with a banner that says so. Nothing disappears. You can still read everything you could before.
Lose read access to a path and only then does its content drop out of view. Removing read access is the one way to hide a node from a member.

The same boundary reaches the assistant. When an AI client tries to write to a node a member cannot write, the MCP tool call comes back with a clear permission-denied result the assistant can relay to you in plain language, rather than failing silently or appearing to succeed. The path-scoped context an assistant receives, and the CLAUDE.md it reads, reflect only the nodes that member can actually read.

Where the check runs

None of this is enforced in the application you happen to be using. Every read and write runs through a database access check resolved against your signed-in user, your organization membership, and any node-level overrides. The application layer cannot bypass it.

One check for every surface. Pathrule Web, Pathrule Desktop, Pathrule CLI, and the MCP server all go through the same database-enforced access control. A change in the browser and a write from an AI client are gated by the same rules.
No shared admin key. Each surface carries a short-lived, per-user token, never a shared service key that could unlock another team's data. A leaked client can only ever reach what that user already can.
Server-side resolution. Membership and per-node overrides are resolved on the server, not trusted from the client, so an edited request cannot grant itself access it was not given.

For the full picture of how the cloud is gated, see the security overview.

On self-hosted

Enterprise self-hosted runs the same role and permission model on your own infrastructure. The roles, the workspace access modes, and the cascading per-node overrides behave the same way; the difference is that the data and the database live on your side. Sign-in goes through your own identity provider over SSO, and those identities map onto the same organization roles described here. See Enterprise self-hosted for how that deployment works.