Team access and security

Workspaces and members#

A workspace owns sites, members, billing, API tokens and webhooks. Everyone in it is a member with one role and access to all sites or selected sites.

• Invite from Workspace settings → Members: enter up to 50 email addresses, then choose a role and site access. Invitations are emailed and expire after 14 days. You can revoke pending ones. Inviting an address again replaces its pending invitation. Only an account with the invited email address can accept it.
• Change role or site access at any time. "All sites" includes sites added later. A member limited to selected sites keeps those sites only, and a site added later is not theirs until you tick it for them (over the API, send include_future_sites as true to give them new sites too). You can't change your own access, give someone a role or sites beyond your own, or change or remove a member who holds a permission or a site that you don't.
• Remove a member: their API tokens for this workspace stop working immediately. Members can also leave on their own.
• Transfer ownership to another member with Make owner (the owner only). The new owner gets all sites, and the previous owner becomes an admin. The owner can't be changed, removed or leave before that.

Every member can see the Members list. Inviting, changing and removing members need the members.manage permission (see Roles & permissions). Per-site access can also be managed from a site's Access tab. The list shows each member's role, sites, whether they have two-factor authentication, and when they were last active.

The Free plan is for one person, the owner, so inviting anyone needs a paid plan or the Pro trial. Paid plans are unlimited.

Members and invitations are REST resources under /workspaces/<workspace id>/members and /workspaces/<workspace id>/invitations, and MCP tools named members_* and invitations_*. The API reference lists every input.

In this section#

• Roles & permissions, including custom roles.
• Single sign-on with guides for Okta, Microsoft Entra ID, Google Workspace and JumpCloud.
• SCIM provisioning.
• Two-factor authentication.
• Audit log.

Workspace security settings#

Workspace settings → Security holds the sign-in rules for everyone in the workspace. Changing them needs the workspace.manage permission, which the Owner and Admin roles have.

• Require two-factor authentication. Members without an authenticator app or a passkey are sent to set one up before they can open the workspace. Only a member whom the workspace's login rules leave single sign-on alone is let in without it, in a session that this workspace's identity provider opened. See Two-factor authentication.
• Allowed login methods apply to every member, and at least one method must stay selected. The owner can always log in with a password or a passkey, so a login rule can't lock the owner out. Someone who belongs to several workspaces can use only the methods that all of them allow. When SSO is enforced, members sign in through SSO only. When you take a method away, members who ticked "Keep me logged in" log in once more.
• Sign members out after ends a session that many hours after the member signed in, however active they are. Someone who belongs to several workspaces gets the shortest lifetime among them.
• IP allowlist. Only the listed addresses can open the workspace in the app or use its API tokens. Put one entry per line, such as 203.0.113.0/24 or 2001:db8::/32. An empty list allows any address. A request from another address is refused with a 403. The list must include the address you are saving from (the page shows it), so you can't lock yourself out.
• Support access lets Privatus Analytics support view the workspace for 7 days from the time you save. Support staff cannot see your workspace unless you allow it. Turn it off to end access at once. Access is read-only, each support session lasts at most one hour, and every page viewed is written to the audit log.

The mobile app follows the same rules. Its login is judged by how the member logged in when they approved the app, and the rules are checked again every time the app renews its access. A workspace whose rules the login doesn't meet is left out of the app, with the reason shown when logging in.

Security settings are a REST resource at /workspaces/<workspace id>/security (GET to read, PATCH to change) and the MCP tools workspace_security_get and workspace_security_update. The inputs are enforce_2fa, login_methods, session_ttl_hours, app_ip_allowlist and support_access. Over the API, session_ttl_hours takes any whole number of hours up to 2,160 (90 days), and 0 means no limit. The API reference lists every input. Over MCP workspace_security_update only returns a link to the security page, see Actions for a person.