/checking-member-access

name: checking-member-access
description: >
  Explains what a member or a role can do in a PostHog project, using the access control MCP tools.
  Use when the user asks what someone can see or edit, who can edit dashboards or feature flags, why a
  member can or cannot open a dashboard, notebook or table, what a role grants, which properties are hidden
  from someone, or how the project's default access is set. Covers what each level means, how the stored
  rule, the enforced level and the inherited access relate, what the null values mean, which tool answers
  which question, and when the answer needs the role tools too.

Checking member access

Use this skill to answer "what can this person do here?" from the access control tools. The tools return the enforced level and where it comes from. This skill is for reading them correctly.

When to use this skill

• "What can this member do in this project?" / "Can this member edit feature flags?"
• "Who can edit dashboards?" / "Who has no access to experiments?"
• "Why can't this member open this dashboard?" / "Which tables is this role restricted from?"
• "Which properties are hidden from the support role?"
• "What does the `analyst` role grant?" / "What is the default access in this project?"

Not for changing rules. The read tools cannot write, and the settings page is where rules are edited.

Plan availability

• Free and pay-as-you-go plans have no access control, and the access control tools are not offered to

them. If the tools are missing from the catalog, say that the plan does not include access control and suggest upgrading to the Boost plan. Link the plan comparison: https://posthog.com/platform-packages.

• Boost and Scale include the default levels and rules for single members on the project, on tools, on

objects and on properties.

• Roles exist on every plan, but role rules are an Enterprise feature: they can be set and are enforced

only there, and the three role access tools are offered only there. If the tools are missing, say that role-based access control needs the Enterprise plan, with the same link. On other plans a member's roles never change the enforced level.

• The tools do not say which plan the organization is on. A `source_subject` of `role` anywhere in a

`members-list` result proves that role rules are enforced. Without that, ask the user whether the organization is on Enterprise before walking roles in step 4 of the workflow.

How access resolves

• **Scopes.** The project itself, then each tool (`dashboard`, `insight`, `feature_flag`, `notebook`,

`experiment`, `warehouse_objects`, and so on), then single objects inside a tool, then person and event properties. The tool names are the keys of `resources` in a members-list entry.

• **Project levels.** `member` can view and edit the resources their other rules permit. `admin` can also

edit project settings, manage the project's access rules, and delete the project.

• **Tool and object levels.** `none` cannot view. `viewer` can view but not change. `editor` can view and

change. `manager` can also manage the access rules of the tool or object. Order: `none` < `viewer` < `editor` < `manager`.

• **Property levels.** `none` hides the property. `read` shows it. `read_write` also allows edits. Every

property is `read_write` unless a rule exists.

• **Bounds.** `minimum` and `maximum` per tool, on `defaults-get`, are the levels a rule can set. A tool

with `minimum` `viewer` can never be set to `none`.

• **Subjects.** A rule belongs to one member, one role, or everyone in the project (the default).
• **Organization admins and owners** have full access to everything in every project. No rule applies to

them. `organization_level` is a number: 1 member, 8 admin, 15 owner.

• **Creators** have full access to the objects they created, and only those. A member with `viewer` on

dashboards can still edit the dashboard they created, and cannot edit the others.

• **Two resolution modes.** Organizations resolve rules either most-specific-first (member rule, then

role rules, then default, and object rule before tool rule) or legacy (the highest of the member's own rule and role rules wins). The tools do not say which mode applies. The server already applied it. So **trust `effective_access_level` and never recompute it from the stored rules.** If the user asks why, explain from `inherited_access`, not from your own precedence.

Available tools

| Tool | Returns | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | `posthog:access-control-members-list` | Every member's enforced access to the project and to each tool. `member_id` narrows to a member. | | `posthog:access-control-roles-list` | The same per role. `role_id` narrows to a role. | | `posthog:access-control-defaults-get` | The project baseline, and which tools accept rules on single objects. | | `posthog:access-control-member-objects-list` | The object rules set for a member: every object with a rule for that member. | | `posthog:access-control-member-properties-list` | The property rules set for a member. | | `posthog:access-control-role-objects-list` | The object rules set for a role. | | `posthog:access-control-role-properties-list` | The property rules set for a role. | | `posthog:access-control-default-objects-list` | The object rules that apply to everyone in the project.