Roles in Dynamo AI
The platform has two types of role, and a user's effective permissions are the combination of both.
| Type | Scope of effect | Assigned by |
|---|---|---|
| Organization level | The whole platform | An administrator, or an identity-provider mapper |
| Resource level | One specific resource | Creating that resource, or having it shared |
The exact scopes each role grants are in Scopes and Roles. This page describes what each role is for.
Creating a Resource Grants Ownership of It
An organization-level role decides whether a user may create a kind of resource. It does not, on its own, decide what they may do afterwards. Creating a resource attaches the matching owner role for that resource to the creator, which is what supplies edit, train and delete.
This is why a Developer needs no further permission to work on their own material: they create a policy, become its owner, and own every subsequent action on it. It is also why a Developer cannot touch a colleague's policy, because they never received a resource role on it.
An administrator sees every resource in their product. Every other role sees only what the user owns or what has been explicitly shared with them. No role grants a team a shared view, so decide how resources will be shared before onboarding a group of users.
Organization-Level Roles
DynamoGuard
| Role | Intended for |
|---|---|
| Member | Consuming resources shared by others. Grants no create permission of any kind. |
| Developer | Building policies, models and AI systems, and managing the ones they create. |
| Admin | Managing every DynamoGuard resource in the organization, including resources created by other users. |
| Extension Admin | Creating models and policies for the browser extension, including self-managed models. |
| Extension User | Using the browser extension. Grants no create permission. |
DynamoEval
| Role | Intended for |
|---|---|
| Member | Consuming resources shared by others. Grants no create permission of any kind. |
| Developer | Creating models, datasets and custom RAG applications, and managing the ones they create. |
| Admin | Managing every DynamoEval resource in the organization, including resources created by other users. |
User Management
| Role | Intended for |
|---|---|
| IAM Viewer | Reading the user list and the roles each user holds. |
| IAM Editor | Inviting users and setting their roles, excluding the administrator roles. |
| IAM Admin | Everything IAM Editor allows, plus removing users, resetting passwords, and writing per-user platform configuration. |
Only a user holding IAM Admin may grant the administrator roles, and only IAM Admin may write per-user platform configuration such as DynamoGuard access activation.
Resource-Level Roles
Each resource type has the same three tiers. They are attached per resource, never organization-wide.
| Role | Intended for |
|---|---|
| Owner | The creator. Full control of that resource, including deleting it. |
| Editor | Changing the resource without being able to delete it. |
| Viewer | Reading the resource only. |
Choosing a Role
Assign the narrowest role that completes the task:
| The user needs to | Assign |
|---|---|
| Author and manage their own policies | DynamoGuard Developer |
| Manage policies created by other people | DynamoGuard Admin |
| Run evaluations on their own models | DynamoEval Developer |
| Read specific resources shared with them | Member, plus a resource-level share |
| Invite users and set roles | IAM Editor |
Related
- Scopes and Roles — the complete role to scope mapping
- Understanding Access — how the access model fits together
- User Management — assigning roles in the interface
- Adding Mappers — granting roles from identity-provider claims