User & access management
This page explains the controls that VIKTOR has to manage access to data and logic. These are divided into three categories: environment, app, and app instances.
An app contains only the logic — the code that defines the tool. It has no data and no users, and is created and maintained by developers.
An app instance is a running copy of an app that users open and work in. It holds the data, the users, and the access settings (such as visibility and permissions). A single app can have multiple app instances — for example, one per project or team. (App instances were previously known as workspaces.)
Environment access
Access to the environment can be setup in two ways:
- login with username and password
- Single Sign-On
Environment rights
Each user has two access attributes that determine the role they have. The possible combinations, together with their name are listed below. The matrix with their permissions is shown below.
| Access level | Developer access | Role |
|---|---|---|
| User | Internal user | |
| User | ✓ | Internal developer |
| Admin | Admin user | |
| Admin | ✓ | Admin developer |
| External user | External user | |
| External user | ✓ | External developer |
| external user | external developer | internal user | internal developer | admin user | admin developer | |
|---|---|---|---|---|---|---|
| invite users to organization | n | n | n | n | y | y |
| edit users on organization | n | n | n | n | y | y |
| remove users | n | n | n | n | y | y |
| create app instance | n | y* | n | y* | y | y |
| edit app instance | if app instance admin | if app instance admin | if app instance admin | if app instance admin | y | y |
| set app instance visibility to public | n | n | n | n | y | y |
| archive app instance | if app instance admin | if app instance admin | if app instance admin | if app instance admin | y | y |
| manage users in app instance | if app instance admin | if app instance admin | if app instance admin | if app instance admin | y | y |
| access private app instance | when invited | when invited | when invited | when invited | y | y |
| access internal app instance | n | n | y | y | y | y |
| access public app instance | y | y | y | y | y | y |
| view activity dashboard | n | n | n | n | y | y |
| list and modify workers | n | n | n | n | y | y |
| see library | n | n | y | y | y | y |
| manage apps they maintain | n | y | n | y | y | y |
| manage all apps on the platform | n | n | n | n | y | y |
| create app | n | n | n | y | y | y |
| publish app version | n | y* | n | y* | n | y |
* Only for apps they maintain
Besides rights on the environment, there are more granular controls on apps and their instances.
App instance rights
App instance rights (what a user can do when they enter the app instance) are configured using usergroups. You define what this usergroup is allowed to do and assign users to this group. The possible permissions per object type are:
| category | detail | explanation |
|---|---|---|
| Read | Navigate | Minimum (navigation) access, excluding summary info and excluding editor access |
| Read | Basic | Makes an object and its summary information accessible to a user, not including the editor |
| Read | All | Gives access to all object information including the editor |
| Write | Create | Allows the user to create an object |
| Write | Update | Allows the user to update an object |
| Write | Rename | Allows the user to rename an object |
| Delete | Allows the user to delete an object |
Usergroup assignment differs between internal and private app instances:
privateapp instances: users are explicitly invited to get access. During invitation, the appropriate usergroup (and thus access level) is selectedinternalapp instances: users automatically get access when they are invited to the environment. They are added to the default user group of each internal app instance. This default can be configured per app instance.
App access
All users (except for external users/developers) can access the Library and find the applications that have been published. Here they can checkout app details and learn about the application and which developers maintain the app.
Apps are not used by users directly; these are app instances that are added to projects. The apps only contain the logic, without data and no users. Users can contact (one of) the maintainers to get access.
Internal developers and admin users can create apps. Developers are automatically assigned as the first maintainer on the app.
Managing apps happens outside of the Library. Developers manage the apps they maintain on the Develop page. Administrators manage every app in the organization from the "All apps" page in the Administrator panel.
App rights
Only app maintainers can publish new versions of an app. They are treated as being allowed to have access to the code. This means that error reports (with tracebacks containing code) are available to them.
App maintainers are not allowed to create app instances. They can use their development workspace when developing, but need explicit access to relevant app instances to get access to production data.
Agent access via MCP
MCP lets users connect an external AI agent to your environment, so the agent can run VIKTOR apps on their behalf. It is currently in BETA.
What to know as an administrator:
- Users approve the access explicitly. Agents authenticate with OAuth. After the normal VIKTOR login, a consent screen states which account is being accessed and what is granted: seeing the logged-in user, seeing the available tools, and running them. The user has to click Allow, and the access granted is short-lived.
- Users cannot exceed their own access. Each user authenticates as themselves, and every app run is checked against their access at the moment it runs. An agent reaches exactly the apps its user already reaches. There is no separate allow-list for MCP yet, so every published app a user can access is available to their agent.
- Agents run calculations, they do not access projects. An agent can only run an app with the inputs it supplies in that call. It cannot read data from your projects, and it cannot write data to them.
- Your organization chooses the agent. Inputs an agent sends to an app, and the results it receives, are handled by the agent's model provider, as with any other content shared with that agent. If your organization has policies on which AI providers may process engineering data, share them with your users.