# User roles & permissions

GLBNXT Workspace uses a role-based access control system to manage what each user can see, access, and do within the platform. Rather than granting the same level of access to everyone, roles allow administrators to define precisely what each person or group of people can interact with, ensuring that the right people have the right access and nothing more.

This is one of the foundational governance capabilities of Workspace, and it underpins how the platform is managed safely and consistently across an organisation of any size.

***

### What Role-Based Access Control Means in Practice

When a user logs into Workspace, what they see and what they can do is determined by the role assigned to their account. Two users in the same organisation may have a very different experience of the platform depending on their roles. One may have access to a broad set of AI models, the ability to create and publish agents, and visibility of usage data across the team. Another may have access only to specific agents made available to their role, with no ability to modify configurations or view other users' activity.

This is by design. Role-based access control allows Workspace to serve a wide range of users, from end users to power users to administrators, within a single governed environment, without exposing functionality or information to people who do not need it.

***

### Default Roles in Workspace

Workspace comes with a set of default roles that cover the most common access patterns within an enterprise organisation. These roles can typically be customised and extended by administrators to match the specific structure and requirements of your organisation.

#### End User

The standard role for the majority of Workspace users. End users can access the chat interface, interact with AI models made available to them, upload documents within conversations, and use agents that have been shared with them. They cannot create or edit agents, access administrative settings, or view other users' activity.

This is the appropriate role for knowledge workers, business professionals, and anyone whose primary use of Workspace is day-to-day AI-assisted work.

#### Power User

An extended role for users who need to do more than interact with existing configurations. Power users can typically create and edit agents, build and manage prompt templates, and share assistants with colleagues within the boundaries set by their permissions. They may also have access to a broader range of models or features than standard end users.

This role is suited to team leads, AI champions, and individuals who are responsible for building and maintaining AI tools for their colleagues.

#### Administrator

The highest level of access within a Workspace environment. Administrators have full control over the platform configuration, including user management, role assignment, model availability, authentication settings, audit log access, and policy enforcement. They can create and manage all agents regardless of who built them, and have visibility of usage and activity across the entire organisation.

This role is typically restricted to IT managers, platform owners, or designated Workspace administrators within your organisation.

***

### Permissions Within Roles

Beyond the broad role categories, Workspace allows permissions to be defined at a more granular level. This means that access can be controlled not just at the role level but at the level of specific features, resources, and actions.

Examples of permissions that can be configured independently of base role include:

**Model access.** Specific AI models can be enabled or restricted for individual users, teams, or roles. An organisation may choose to make a broad range of models available to power users while restricting end users to a curated subset appropriate for their tasks.

**Agent creation and publishing.** The ability to create agents, edit existing agents, and publish agents to the shared library can each be controlled independently, allowing organisations to define exactly who has the ability to build and distribute AI tools within the platform.

**Knowledge and document management.** Permissions around which knowledge collections a user can access, upload to, or manage can be set at the user or group level.

**Sharing permissions.** The scope at which a user can share agents, whether limited to individuals, restricted to their own team, or extended to the whole organisation, can be configured per role or per user.

**Administrative access.** Specific administrative functions, such as viewing audit logs, managing user accounts, or configuring authentication settings, can be assigned independently, allowing organisations to distribute administrative responsibilities without granting full administrator access.

***

### Managing Users and Roles

User and role management is handled through the administrative settings of the Workspace environment. Administrators can:

* Create, edit, and deactivate user accounts
* Assign and change roles for individual users
* Create custom roles tailored to specific teams or functions within the organisation
* Assign users to groups, which can then be used as the target for role assignments, agent sharing, and access policies
* Review which users have access to which agents, models, and features at any point in time

Changes to roles and permissions take effect immediately. When a user's role is updated, their access level reflects the new configuration the next time they interact with the platform.

***

### Groups and Teams

In addition to individual role assignments, Workspace supports the use of groups to manage access at a team or department level. Rather than assigning permissions to each user individually, administrators can assign users to a group and manage access for the group as a whole.

This significantly reduces the administrative overhead of managing access for large organisations. When a new user joins a team, adding them to the relevant group gives them the appropriate access immediately, without requiring individual permission configuration.

Groups can also be used as the target for agent sharing, allowing agents to be made available to an entire department or project team through a single sharing action.

***

### The Principle of Least Privilege

A widely adopted best practice in access management is the principle of least privilege: give each user only the access they genuinely need to do their job, and nothing more. This reduces the risk of accidental misuse, limits the potential impact of a compromised account, and makes it easier to maintain a clear and auditable picture of who has access to what.

When designing your organisation's role structure in Workspace, it is worth applying this principle deliberately. Start from what each role actually needs to do, and grant access accordingly, rather than starting from a broad access level and restricting it after the fact.

***

### Getting Help with Role Configuration

If you are an administrator setting up role-based access control for the first time, or if your organisation's access requirements have become more complex over time, the GLBNXT support team can assist with configuration guidance. For day-to-day role and user management questions, refer to the administrative settings documentation or contact your designated Workspace administrator.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.glbnxt.com/workspace/enterprise-controls/user-roles-and-permissions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
