Access Control
In traditional engines, access control is left to external systems.
In 3dverse, it is a core architectural feature: assets live in the cloud and access must be governed from the ground up.
In 3dverse, assets are never local files — they exist entirely within the platform. This makes access control an inherent part of how the system works, not a separate concern.
This page explains how that control is structured through the access model — environments, folders, users, and roles — and how these rules extend into rendering sessions.
Access Model
Access control in 3dverse follows a layered model.
At the top level are environments, which define the boundaries of access. Inside them, folders organize assets. Users represent identities scoped to an environment, and their rights are expressed through access that is assigned a role, which groups the underlying permissions.
Environments
An environment is the top-level boundary of access control in 3dverse. It defines a closed universe where all resources — assets, sessions, etc. — live.
- Assets created in one environment cannot be accessed from another.
- All other resources (sessions, logs, etc.) are equally confined within their environment.
- Permissions are always resolved inside the environment they belong to.
From the outside, an environment acts as the backend counterpart to the applications that connect to it. Multiple dashboards, editors, integrations, or custom UIs can all point to the same environment and operate on the same pool of resources.
This separation ensures resources are never mixed across environments, while giving developers freedom to decide how their applications interact with a given environment’s data and rules.
Folders
Controlling access at the level of individual assets would be unmanageable.
A single scene can reference hundreds, thousands, or even tens of thousands of assets — meshes, textures, materials, animations — many of which are reused across multiple scenes. Granting or revoking permissions one by one would quickly become error-prone and impossible to scale.
To solve this, 3dverse organizes assets into folders. A folder behaves much like it does in a file system: it can contain assets, subfolders, or both.
Every environment starts with a root folder, which acts as the entry point of its asset hierarchy.
- Permissions are always applied at the folder level, never directly on assets.
- Access is inherited by default, so granting rights to a parent folder automatically applies to everything inside it.
- Access can be overridden or removed deeper in the hierarchy, allowing precise control when needed.
This strikes a balance between flexibility and manageability: developers can grant broad access where convenient, while still applying restrictions to sensitive subsets of content.
Users
If folders define where access is applied, users define who has that access.
A user represents an identity within a single environment. Users are never shared across environments: the boundary of an environment is also the boundary of its user base.
In practice, the user is the central actor of access control: all interactions with assets, sessions, or other environment resources are mediated through a user identity.
Users can be granted different levels of access across the folder hierarchy.
For instance, the same user might have full permissions on one folder, read-only permissions on another, and no access at all to a third. Since permissions cascade down by default, access to subfolders is determined by the closest parent rule unless explicitly overridden.
Groups
In addition to individual users, environments can define groups.
A group is a collection of users that serves as a central point for assigning access. Instead of configuring roles and permissions user by user, developers can grant access to a group, and all its members inherit those rights.
Groups make it easier to manage access at scale, especially in environments with many users or multiple teams working on the same assets.
Roles and RBAC
Defining access at the folder level solves the problem of scale, but it still leaves the question of what a given user is allowed to do once access is granted.
3dverse answers this with a Role-Based Access Control (RBAC) model.
Every user in an environment is assigned one or more roles, and each role maps to a predefined set of permissions.
The standard roles are:
- Guest — view-only access. Guests can inspect assets, open sessions, and issue transient changes, but cannot persist modifications.
- Contributor — edit-level access. Contributors can create, update, and delete assets within folders they have access to, as well as persist changes in sessions.
- Owner — full administrative access. Owners can manage folders, users, and permissions, in addition to all contributor capabilities.
Roles are evaluated in the context of folder permissions. This means a user can be an Owner in one folder, a Contributor in another, and have no access at all to a third.
The access model in 3dverse can be summarized as follows:
- Environment — the top-level boundary: resources, users, and permissions never cross it.
- Folder — the unit of access control: permissions are applied here and cascade to assets and subfolders.
- User — the identity acting within an environment: all access checks resolve through a user.
- Access — the link between a user and a folder: determines what rights the user has.
- Role — a grouping of permissions: simplifies management but always resolves to explicit permissions.
- Permission — the fundamental unit: defines the actual operations a user can perform.
Sessions
The access model does not stop at stored assets.
It also governs sessions, the live context where assets are used and users interact together.
Access in sessions works on two layers:
- Session access — the rules that determine who can create a new session and who can join an existing one.
- Runtime access — continuous checks performed while the session is live, whenever assets are referenced.
Session Access
Creating or joining a session requires a user to pass access checks:
- The request is authenticated and maps to a valid user in the environment.
- The requested scene is resolved to its containing folder.
- The user has the necessary permissions on that folder.
If all checks succeed, the session is created or joined. If not, the request is denied with a permission error.
Runtime Access
Access control continues after the session is opened. Whenever a user creates entities that reference assets, the platform verifies that the user has permission to use the targeted asset.
This ensures participants cannot bypass folder-level restrictions simply because they are inside a live session. Every reference to stored assets is validated against the same rules that apply outside of sessions.
Clients
Inside a session, a user is represented by one or more clients. Each client is an active connection that consumes session resources such as bandwidth and available slots.
- A user may spawn multiple clients (for example, by connecting from a laptop and a phone).
- Limits apply per client, not per user. If a session allows five clients, one user joining from two devices consumes two of those slots.
This makes resource usage predictable while still tying each client back to its user identity.
Guest Access
Guests are temporary connections that exist only within a live session. They are not part of the environment’s user base: instead, each guest is counted as a client flagged as guest and attached to the user who issued the invitation.
While the session is live, guests can:
- Join through the link provided by the host.
- View assets and interact in real time.
- Perform changes visible to other participants during the session.
They cannot:
- Persist changes.
- Manage folders, users, or permissions.
When the session ends, guest access simply becomes invalid and can no longer be used.
This allows temporary participation for reviews, demos, or external collaborators without expanding the environment’s user base.
Session Tracking
Opening and joining sessions covers only part of access control. To keep collaboration clear, the platform also tracks who is present and when.
Sessions are visible to any user who has access to the folder that contains the underlying scene. This makes them discoverable without extra coordination, while still respecting environment boundaries.
The platform records:
- Who joined and left a session.
- When these events occurred.
- The user or guest identity associated with each connection.
This provides a simple history of participation, consistent with the same access model that governs assets.
Architectural Reflection
Access control in 3dverse is not a layer added on top of the engine — it is embedded in how the platform is built.
- Environments provide hard boundaries: users, assets, and sessions never cross them.
- Folders make access manageable at scale, ensuring permissions cascade without being applied asset by asset.
- Users, roles, and permissions give fine-grained control while keeping management practical.
- Sessions extend the same rules into runtime: only authorized users can create or join them, asset references are checked continuously, and participation is tracked.
Comparison at a Glance
The contrast with traditional tools can be summarized in the table below:
| Aspect | Traditional Tools | 3dverse |
|---|---|---|
| Access boundaries | Project files, repos, or shared drives | Environments with hard isolation |
| Granularity | Per file / project | Folder-level, inherited, overrideable |
| Access unit | Individual files or project assets | Folders containing assets and subfolders |
| Session creation | Not governed by access model (if sessions exist at all, access is external) | Permission checks on the containing folder |
| Joining sessions | Not applicable — no unified model | Allowed for any user with access to the folder |
| Runtime checks | Not applicable — once in, full trust | Continuous validation on every asset reference |
| Participation tracking | External logs, if configured | Built-in: joins, leaves, user/guest identities |
By folding sessions into the same access model as stored assets, 3dverse eliminates the gap between storage security and collaboration security, ensuring the same rules apply from storage to live collaboration.