How Roles and Permissions Work Inside tiCrypt Virtual Machines
In most platforms, being an administrator means having access to everything: every file, every machine, every user's data. tiCrypt is built on the opposite principle. A system-wide admin has no inherent access to any virtual machine, its drives, or the data inside them. The person who starts the VM is in control.
This separation is not a side effect of how tiCrypt was designed. It is the design. VM roles and permissions operate as a completely independent system from the main tiCrypt role hierarchy, and understanding how they work is essential for anyone deploying or using tiCrypt VMs.
Why VM Permissions Are Separate
tiCrypt enforces separation of duties at an architectural level. The main system handles user accounts, team membership, projects, and vault-level file encryption. VMs handle research environments: operating systems, applications, attached drives, and live user sessions.
These are distinct trust domains. A main-system admin can manage teams, activate user accounts, and configure hardware setups, but they cannot open a VM terminal, read its drives, or manage its users. Conversely, a VM Owner has full authority over their VM but cannot promote users, change system settings, or access another user's vault.
The key principle: access to a VM is explicitly granted by the VM Owner. It is never inherited from the main system.
This means a regular user in the main system can be the Owner of a VM with full authority over it, while a Super-admin may have zero access to that same VM. Neither role implies the other.
How a VM Gets Its Owner
To understand roles inside a VM, it helps to understand how a VM comes into existence.
A VM is launched from a VM Config, a template that specifies the hardware setup, image, attached drives, and Co-Owners. The VM Config is the blueprint; the running VM is an instance of it. The user who starts the VM becomes the Owner, and that role bootstraps the entire VM user management system.
Once the VM is running, the Owner can add users, assign roles, and configure permissions. Users who were previously added to the VM retain their roles and permissions across restarts, because that information is stored in a database on the VM's home drive (the first attached drive).
Home drive portability: if a home drive is detached from one VM and attached to another, the VM user database travels with it. The new VM inherits the users, roles, and permissions from the drive.
All Co-Owners listed in the VM Config are added to the running VM with the Co-Owner role, but only the user who actually starts the VM becomes the Owner.
The Role Hierarchy
VM roles form a hierarchy. From lowest to highest: User, Manager (also called Co-Owner), and Owner. Users can only modify other users with a role lower than their own.
Owner & Co-Owners
The Owner has unrestricted authority over the VM. They can:
- Add, remove, and manage all users in the VM
- Assign and revoke any role or permission
- Manage groups, drives, and access directories
- Connect to the VM via RDP/VDI
- Transfer files between the VM and the Vault (subject to main-system permissions)
- Shut down the VM
There is exactly one Owner per running VM: the user who started it from the VM Config.
Co-Owners in particular receive their role automatically when the VM is started from a VM Config. They can also restart the VM and mount its drives in other VMs, because Co-Owner status grants access to the associated drive keys.
Adding Co-Owners has consequences. When a user is added as a Co-Owner, they also gain access to the VM's associated drives. This is by design: Co-Owners need drive access to manage the VM, but it means the Owner should only grant Co-Owner status to trusted users.
Manager
Managers sit between the Owner(s) and regular Users. They can perform management tasks within the VM, but only to the extent that the Owner has granted them specific permissions.
A Manager can:
- Add and manage users with a lower role
- Manage VM groups and access directories (if permitted)
- Connect to the VM and perform research
- List, mount, and manage drives (if permitted)
User
The User role provides access to the VM for research purposes, typically through an RDP or VDI-like interface. Users can interact with data and applications inside the VM, but their actual access is governed by their membership in VM groups and the configuration of access directories.
Users have no management abilities. They cannot access the VM management interface, manage other users, create groups, or modify drive configurations.
Permissions Within a VM
Roles establish the hierarchy, but permissions determine what a user can actually do. Each user in a VM has a set of granular permissions that the Owner or a Manager can configure individually.
Permissions cover several areas:
| Permission Area | Controls |
|---|---|
| Remote Desktop | Whether the user can connect to the VM via RDP/VDI |
| Drives | Listing, formatting, mounting, and unmounting drives |
| Groups | Viewing and managing VM-internal groups |
| Users | Viewing and managing other VM users |
| File Transfer | Transferring files between the VM and the Vault |
| VM Statistics | Viewing VM resource usage and details |
Permissions are assigned per user and can be customized regardless of role. A Manager with only the Remote Desktop permission, for example, can connect to the VM but cannot list drives or manage groups. The Owner retains full control over which permissions each user receives.
Where Main-System and VM Permissions Intersect
While VM and main-system permissions are separate, certain operations require both. The clearest example is file transfer.
If a user is the VM Owner and has full permissions within the VM, they can initiate a file transfer to the Vault. But if that same user lacks the main-system permission to write files in the Vault, the transfer will fail. The VM grants the ability to initiate the transfer; the main system gates whether it completes.
Similarly, starting a VM requires main-system permissions to spawn VMs and access to the relevant drive keys. Once the VM is running, control shifts to the VM's own permission system.
The rule of thumb: VM permissions govern what happens inside the VM. Main-system permissions govern everything outside it. Operations that cross the boundary require both.
What System Admins Can and Cannot Do
This is where tiCrypt's separation of duties is most visible:
| Action | System Admin | VM Owner |
|---|---|---|
| Configure VM hardware setups and images | Yes | No |
| Manage VM host infrastructure | Yes | No |
| Shut down a VM | Yes | Yes |
| Start a VM | Requires drive key access | Yes |
| Connect to a VM | Only if explicitly granted access | Yes |
| Manage VM users | No | Yes |
| Access data on VM drives | No | Yes |
| View VM audit logs | Yes (with permission) | No |
System admins can manage the infrastructure that VMs run on, but they cannot reach into a running VM. They can shut down a VM in an emergency, but they cannot connect to it, manage its users, or read its drives unless the VM Owner has explicitly granted them access.
This is a deliberate design constraint. In compliance-sensitive environments (CMMC, NIST 800-171, ITAR, HIPAA), the ability to prove that administrators cannot access research data is not optional. tiCrypt makes that proof architectural rather than procedural.
Key Takeaways
- VM roles and permissions are completely independent from the main tiCrypt system.
- The Owner is the user who starts the VM from a VM Config. There is exactly one Owner per VM.
- Co-Owners are defined in the VM Config and receive their role automatically, along with access to the VM's drives.
- Managers can perform delegated management tasks within the scope of their granted permissions.
- Users can access the VM for research but have no management capabilities.
- All VM user data is stored on the home drive and travels with it if the drive is moved to a different VM.
- Operations that cross the VM boundary (such as file transfers to the Vault) require both VM and main-system permissions.
- System admins cannot access VM data, manage VM users, or connect to VMs unless explicitly granted access by the VM Owner.