Roles and permissions
Access control is the part of an implementation that compliance reviewers read most closely, and the part clients most often want changed after they have seen the workspace in use. Define it against the structure you built in organization structure.
The four workspace roles
Owner
Full control. Can delete the workspace, transfer ownership, and access billing. Give this to the client, never to the implementation partner.
Admin
Manages users, settings, and integrations. Cannot delete the workspace or change billing. The working role for day-to-day administration.
Editor
Creates and modifies projects, skills, and content. Cannot reach workspace settings. The right default for most employees.
Viewer
Read-only access to assigned projects and resources. For auditors, stakeholders, and anyone who needs visibility without authorship.
Assign the least privilege that lets someone do their job. Editor is the correct default for most employees; Admin should be a named, small group with an owner in each department.
Permissions scope downward
Roles set the ceiling. On Enterprise, permissions scope further down: to individual projects, skills, connectors, and memory layers. Access can be granted by role, department, project, and data sensitivity level, which is what lets one workspace serve departments with genuinely different confidentiality requirements.
Administrators can see every active project, deployed skill, connected integration, and user session from a central admin console. For clients with internal audit obligations, demonstrate this during scoping rather than describing it.
Skills inherit permissions
This is the property to explain early, because it is the one that reassures security teams.
A skill can only reach the tools and data the approving user already has permission to use. If someone cannot access a data source, a skill they build cannot access it either. Permissions flow through automatically, so automation never becomes a route around access control.
The practical consequence for implementers: who approves a skill matters as much as who wrote it. Approving a skill as an Admin can give it a broader reach than the person who will run it day to day.
Identity and session controls
SSO and SAML
Connect the client identity provider so access follows joiners, movers, and leavers automatically rather than through manual invitations.
Two-factor authentication
Enforced at the workspace level. Agree with the client whether it is mandatory before the first wave of onboarding.
Session and IP policy
Session lifetime limits and IP allowlisting, for clients who restrict access to managed networks.
Audit logs
A record of administrative activity. Confirm the client audit requirement during scoping, not at their first compliance review.
Configuration for all of these lives in workspace settings.
Rollout order
Connect identity before bulk onboarding. Inviting users manually and migrating them to SSO afterwards means reconciling two sets of accounts, and it is the most common avoidable rework in a rollout.
Next: model policy.