Role and Permission Assignment Checklist for DAVE

DAVE ships with six default roles. Roles are editable database rows, so your tenant may have modified the defaults or added custom roles. The six defaults and their permission grants are:

DAVE enforces 20 permission types in total, at both the API and frontend level. The permissions listed above are those documented in the User Management help page for the five roles whose permission grants are published. The Financial role's specific permission strings are not listed in the current User Management documentation: see the dedicated role documentation or ask your DAVE Admin for the full list.

Multiple roles can be assigned to a single user. A user with both Create and Curate can build agents and workflows. A user with both Use and Reporting can run instances and view the audit log. Assign combinations only when a single role genuinely does not cover the user's full job function.

The least-privilege principle is the foundation of correct role assignment: give each user only the roles they need to do their job, and nothing more. In DAVE, this means:

• Do not assign Admin unless the user genuinely needs to configure the tenant. Admin grants admin:*, which covers all settings, all user management, all provider configuration, and the audit log. It is the most powerful role on the tenant. Every additional Admin is an additional attack surface. Most team members do not need it.
• Do not assign Create to users who only run workflows. A user who launches instances and completes tasks needs the Use role, not the Create role. Create grants agent write access, which is a configuration capability, not an operational one.
• Do not assign Curate to users who only build agents. A user who only creates and edits agents needs the Create role. Curate adds workflow write access, which is broader than agent creation alone.
• Do not assign Reporting to users who need it for a one-time audit. Export the relevant data for them instead. Reporting grants ongoing read access to reports and the audit log. If a user only needs audit evidence for a specific period, an Admin can export the relevant CSV and share it without granting the Reporting role permanently.
• Multiple roles are additive. Assigning both Create and Admin does not reduce Admin's scope. Every permission from every assigned role is active simultaneously. If a user has Admin, the other roles they hold are redundant: Admin already covers everything.

When in doubt, assign the narrower role and expand it only if the user encounters a genuine access gap. It is easier to add a role than to explain why a user had more access than they needed.

One operational detail that causes confusion: role changes in DAVE take effect on the user's next login, not immediately. The user's current browser session holds a permissions token that reflects the roles assigned at login time. Changing a role in User Management updates the database record, but the active session token is not invalidated until the user logs out and back in.

This means:

• If you add a role to a user, they will not see the new access until they log out and log back in. Tell them to do so immediately after you save the change.
• If you remove a role from a user, their current session still has the old permissions until they log out. For sensitive role removals (for example, removing Admin from a user), ask them to log out immediately, or deactivate and reactivate the account to force session invalidation.
• If you deactivate a user account, any existing sessions are invalidated on their next API call. The user cannot complete further actions after the next request fails, but they may be mid-session when you deactivate. For immediate effect on a sensitive deactivation, coordinate with the user or wait for their session to expire naturally based on the tenant's session timeout setting.

Document role changes in your internal admin log with the date, the user affected, the old role set, the new role set, and the reason. The DAVE audit log records all user edits automatically, but an internal log with the business reason provides context that the audit log does not capture.

Can a user have no roles?
Yes. A user with no roles assigned can log in but sees an empty dashboard and cannot access any feature. This is not a useful state for an active team member. If a user should not have access, deactivate their account rather than removing all roles.

Can I create custom roles?
Yes. Roles are editable database rows in DAVE. The six defaults can be modified and new roles can be created. Custom role management is done through the Admin interface. If your tenant has custom roles, document their permission grants alongside the defaults so the checklist items below remain meaningful.

What happens to task assignments when a user is deactivated?
Deactivating a user does not automatically reassign their tasks. Review any open tasks assigned to a departing user before deactivating their account and reassign them to an active user with the Use role.

Why does the document only list five roles in the permission table?
The User Management help page was written before the Financial role was added. The editorial corrections banner on the document confirms six default roles. The Financial role exists and is assignable: its specific permission strings are not listed in the current User Management documentation.

Can I assign the Admin role to myself?
An Admin can assign any role to any user, including themselves. However, a workspace Admin cannot grant platform-wide access or move users between workspaces: those actions are reserved to the platform operator and are refused on the ordinary edit path.

Do role changes affect MCP key access?
MCP keys are scoped by capability preset, not by the user's tenant role. Changing a user's tenant role does not change what their MCP key can do. If you remove a role from a user, also review their MCP keys and revoke any whose preset is no longer appropriate for their reduced access level.