Three layers: account, membership, person
Access in Meandr rests on a simple chain. A tenant is the account — the billing boundary that owns your projects 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 projects.
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 project 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 projects and manages members (everyone except owners), and reaches every project automatically. Admins do not touch billing.
- Member — reaches only the projects they’ve been explicitly added to, with the per-project role granted there. No account-wide project access, no member management, no billing.
- Billing — sees and manages billing and payment, and nothing else. No project 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 projects
Projects 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 project depends on the account role:
- Owners and admins reach every project in the account automatically. There is nothing to grant; their account role already covers it.
- Members get access one project at a time. Each grant is its own record with a per-project role.
The per-project roles, which apply only to members:
- Admin — manage the project, including deleting it, and manage who else is on it.
- Write — read the project and change its content (servers, agents, policies).
- Read — look, but don’t change.
Because project access is anchored on the account membership, it can’t outlive it: remove someone from the account and every project grant they held goes with it. And a member who tries to open a project they were never added to gets a clean “forbidden,” not a pretend “not found.”
Projects keep teams apart
The reason this model is worth the structure is isolation. A project 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 projects, 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 project and they see exactly that project; 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.