Team & permissions

An MSP account’s own people, roles, and invitations live on Team (/access), the same Access management surface every workspace uses. What is specific to an MSP account is the msp.clients.* permission group, the msp.billing.view permission, and the fixed role an account member runs under once they open a client.

​

The permissions

| msp.billing.view | Read Billing and its CSV, and nothing else in the account. | These are granted through custom roles exactly like any other permission: see Access management.

​

The billing-only role

msp-billing is a built-in role that holds msp.billing.view and nothing else. It exists only in an MSP account: in an organization workspace it is not listed and cannot be assigned, invited or mapped from a directory group. Give it to someone, such as a finance contact, who needs the numbers but not the clients. A member with only this role signs in to Billing. It is the only item in their menu, every other page is hidden, Settings sends them to Billing, and the API refuses everything else. Anyone who holds msp.clients.view can read Billing too.

​

Limiting an operator to some clients

By default every member of the account sees every client. To limit an operator:

1. Put tags on your clients.
2. Open Client access (Operations → Client access, /msp/operators). It lists the account’s people with their roles and what each can open.
3. Choose a person, turn off See every client, and enter the tags in Limit to tags, separated by commas.

A scoped operator sees and opens only clients that carry at least one of their tags. This applies to Overview, Clients, Billing and its CSV, Activity, and opening a client. A client outside the scope behaves as if it does not exist.

• Admins are never scoped. An admin or owner always sees every client, so an account cannot lock itself out of its own clients.
• A scoped member cannot change scopes, their own included. Otherwise the way out of a scope would be open to the person it limits.
• A scope fails closed. If no client carries any of a person’s tags any more, for example after the last one was released, they see no clients.
• Seeing the page needs users.view. Changing a scope needs users.assign_roles. A scope needs at least one tag, or See every client. Each change is recorded.

​

Two-factor is required to open a client

msp.clients.access is not enough on its own. Opening any client also needs two-factor authentication turned on for your own account, checked fresh every time. Without it, the open dialog sends you to your profile to turn it on.

​

Inside a client: a fixed operator role

Once a session is open, you run inside that client as a fixed role, not your usual role in the account and not a role either side configures. It is every permission an admin holds, minus what would outlive the session or take the workspace away from the people who own it:

• Inviting, creating, editing or removing people, assigning roles, resetting anyone’s password, two-factor, or approving an email change.
• Revoking or sending invitations.
• Managing roles, API keys, or directory and SSO.
• Changing the security policy or licence settings.
• billing.checkout.
• Anything under msp.clients.* itself: an operator working inside a client cannot use that session to reach into the MSP account, or into another client.

This set is fixed on purpose: neither the account nor the client edits it, and no role configuration is read for it.

​

Seeing the client’s people

Seeing who the client’s people are is gated separately, by msp.clients.people on your account. Without it, an operator session holds none of users.view, users.view_activity, or invitations.view inside the client: the roster is simply not there. With it, the roster is read-only. A client the MSP created shows its people to holders of msp.clients.people. A workspace that linked chose at approval, and if it chose to hide them, nobody at the account sees them. Without people access an operator does not see names. The client’s people and devices appear as coded identities: Person or Device followed by a six-character code, so the work can go on without naming anyone. A few surfaces cannot be coded and are refused: people search, the member list, the roles page (which names who holds each role), and rollout actions that take an email address. The audit trail can be read, but not searched by text or filtered by person, and its signed export is refused.

​

What never runs inside a client, for anyone

• API keys. A key authenticates without the person behind the cookie being present, so a key’s request always runs in the key’s own workspace, never a client’s.
• Your own account. Changing your password, two-factor, email or profile is refused while a client is open: that belongs to the MSP account. Leave the client first.
• Minting the client’s audit webhook token, a credential that would outlive the session and write into the very trail that is supposed to be recording you.
• Creating a Runtime Security App token. Like an API key, a token works without anyone present in the client, so only the client’s own admins can create one. Enrollment tokens for devices are not affected.
• The client’s own decision about its MSP. Only the client’s admins can switch access on or off, or change the code and duration settings, never an operator working inside it.

​

Next