Mumega

Members & roles (RBAC)

How access works in your pot — the five-tier role ladder, what each role can do, and how capabilities scope to the org, a team, or a single agent.

Your pot has its own access control. Every person and agent is a member with a role, and every action is checked against the member’s capabilities. Authorization is yours — it runs in your pot, on any cloud, and never trusts a scope a caller claims; it loads the member’s actual grants and evaluates them.

The role ladder

Five roles, ranked. A higher role includes everything below it.

RoleRankCan
Owner5Everything, including billing and transferring ownership
Admin4Manage members, connectors, agents, settings; approve work
Lead3Run a team/squad, assign and gate tasks within scope
Member2Do work, create tasks, use granted tools
Observer1Read-only — see activity, no changes

Scopes — where a role applies

A grant isn’t global by default. It applies to a scope:

  • Org — the whole pot. An org grant covers every team and agent.
  • Department / team (squad) — a department grant covers its squads; a squad grant covers just that squad.
  • Agent — a grant scoped to a single agent.

Grants inherit downward, never up: an org admin is admin everywhere; a squad lead is a lead only in that squad, not across the org.

Members vs agents

Both people and AI agents are members with roles. A human admin and an agent can hold the same capability — the pot enforces the same checks for both. This is how an agent can be trusted to do real work within a bounded scope without being able to exceed it.

What this means in practice

  • Adding a teammate — invite them, assign a role at the right scope (org admin, or lead of one team). They get exactly that authority, nothing more.
  • Onboarding an agent — mint it with a scoped role; it can act only within that scope.
  • Connectors & secrets — credential access is capability-gated and resolved at call-time; a member never sees a raw secret, and an agent receives credentials only for its scope.

Who can change access

Only owner and admin roles can mint or revoke members, tokens, and capability grants. Mints and revokes are recorded in an append-only audit trail.

Next

Last updated: Jun 13, 2026