Three layers: account, membership, person
Access in Meandr rests on a simple chain. A tenant is the account — the billing boundary that owns your workspaces and holds the subscription. A user is a person with a login. Between them sits a membership: the row that ties one person to one account and carries their role there. A person can belong to more than one account, and each membership is scored independently — the role you hold in one tenant says nothing about another.
That membership decides two things: what you can do across the account, and how you reach individual workspaces.
Account roles
Every membership carries exactly one account-level role.
- Owner — full control of the account, billing included. Owners can manage every member (other owners too) and reach every workspace automatically. Cancelling or restoring the subscription is owner-only, even among people who can otherwise touch billing.
- Admin — runs the account day to day: manages workspaces and manages members (everyone except owners), and reaches every workspace automatically. Admins do not touch billing.
- Member — reaches only the workspaces they’ve been explicitly added to, with the per-workspace role granted there. No account-wide workspace access, no member management, no billing.
- Billing — sees and manages billing and payment, and nothing else. No workspace access at all.
One guard rail sits under all of this: an account can never be left with zero owners. A role change that would remove the last owner is refused.
Reaching workspaces
Workspaces are where the work lives — each one is an isolated scope for its own agents, servers, tools, policies, rate limits, and cost. Who can open a workspace depends on the account role:
- Owners and admins reach every workspace in the account automatically. There is nothing to grant; their account role already covers it.
- Members get access one workspace at a time. Each grant is its own record with a per-workspace role.
The per-workspace roles, which apply only to members:
- Admin — manage the workspace, including deleting it, and manage who else is on it.
- Write — read the workspace and change its content (servers, agents, policies).
- Read — look, but don’t change.
Because workspace access is anchored on the account membership, it can’t outlive it: remove someone from the account and every workspace grant they held goes with it. And a member who tries to open a workspace they were never added to gets a clean “forbidden,” not a pretend “not found.”
Workspaces keep teams apart
The reason this model is worth the structure is isolation. A workspace draws a hard boundary around its agents, its connected servers and imported tools, its policies, its rate-limit windows, and its cost roll-up. One registered upstream — say a single Stripe MCP registered once at the account — can be used from several workspaces, each with its own agents, its own rules, its own limits, and its own bill, without leaking into the others. Give a contractor read on one workspace and they see exactly that workspace; they never gain a view of the rest of the account.
Inviting people, and what billing counts
You add teammates by inviting them by email, up to your plan’s seats cap — a hard ceiling on how many members an account may have. The cap is a limit on people, not a purchase: you don’t buy seats ahead of time, you simply invite, and billing tracks the actual number of members against the plan’s included band. Members within the included band cost nothing; past it, billing reflects the real head-count. The seats cap and the included band are two different numbers — one blocks a new invite, the other is where billing begins — and both are read live from your plan.