Privilege Matrix

Every gated action in Leed names a privilege. Before the action runs, Leed compares the privilege’s minimum role against your base role, and — if that fails — against any access override you hold on the resource in play. This page is the complete list of those privileges, plus the role-by-role summary most people actually come here for. If you have not met the six roles themselves yet, start with Roles and Permissions; this page assumes them.

Privileges are plan-independent. Nothing on this page changes when you change tier.

How to read this table

Roles are cumulative, so minimum role means that role and every stronger one. A privilege whose minimum is Content Writer is satisfied by Content Writer, Content Approver, Content Publisher and Administrator alike.

An override on a page type, a label or a page satisfies these same checks — see Resource-Level Access Overrides for the stronger-of rule, which is the only place the two systems meet.

And when a check fails, the 403 body names the privilege verbatim:

Unauthorized: missing page:publish

So the fastest route through this page is to search it for the string in the error you are holding.

All 58 privileges

Groups are the product’s own; the order below is the order they are declared in.

✓ enforced — this privilege is checked somewhere in the product. † defined but never checked; see the next section. ‡ checked in the interface only; the server gates the same actions on user:write.

Privileges that exist but are never checked

Ten of the fifty-eight are declared with a minimum role and then never consulted. They are not secretly enforcing anything, and a member who “lacks” one of them will never see a 403 naming it.

There is an eleventh case, of a different kind. rbac:write is a front-end gate only. It disables five controls across three screens: the role dropdown and the Billing and Developer checkboxes on Settings → Team Members, and the access-override editors on Settings → Labels and Settings → Page Types. The server does not check it at all: changing a role or writing an override is gated on user:write, and creating a page-type or label override is additionally entitlement-gated on contentRbac — removing one is not. rbac:write and user:write share a minimum role of Content Publisher, so a reader gets the same answer either way, but an integrator reading the API will never find rbac:write in a response, an error or a route. It is also the first thing to check when the Content Manager, Approver and Contributor pickers described in Resource-Level Access Overrides are visible but inert: that is this gate, not an expired plan.

What each role can do

The table below is built from routes that are actually enforced. Read a row as: this role can do this if its column says so.

※ The endpoint that lists members carries no permission check at all, so any signed-in member of the workspace can retrieve the list. The Team members card in Settings is gated on user:read, so a Restricted member has no way to reach the screen through navigation — but the data is not protected by a role.

“override only” means the base role does not satisfy the check, and an access override on the resource in play can. On the two settings rows it names the specific override: the Billing checkbox for billing, the Developer checkbox for developer. Billing and Developer Access covers those two, which are the only privileges you can grant with a checkbox.

Content Approver has no column entry that Content Writer lacks. That is not an omission in the table — it is the state of the product, and Roles and Permissions explains what the role is genuinely for.

Where the checks happen

A privilege is checked in two places, and they are not the same check.

On the server, a route declares rbacValidator("<privilege>") and the request is refused with a 403 if it fails. That is the enforcement, and nothing gets past it. In the interface, a control asks checkAuth({ privilege, resourceFilters }) and disables or hides itself. That is a courtesy, and it can be wrong in both directions.

It can be wrong by showing you a control you cannot use: the Delete item in a team member’s ⋮ menu is drawn for every viewer and fails server-side for anyone who is not an Administrator. And it can be wrong the other way, by hiding a screen from someone whose data is not actually protected — the member list is readable by any signed-in member even though the card that links to it is gated. Whether a screen appears at all is a separate question from whether its data is protected, and it is answered in Who Can See What.

An AI client can ask for a machine-readable version of exactly this table, resolved for the signed-in user — role, every privilege with its minimum role and whether it is granted, and the overrides that apply. See MCP Tools: Analytics and Introspection for how to call it. Note what it cannot do: those tools read permissions and never grant them.