Scopes and Roles

Every permission decision combines two independent role tiers. Reading either one alone predicts the wrong answer, which is the most common source of confusion when an access problem is investigated.

Tier	Granted by	Decides
Organization level	A realm role such as org:dynamoguard:developer	Whether the user may create a kind of resource at all
Resource level	A role attached to one specific resource	What the user may do to that resource

The creator of a resource becomes its owner. This is what makes the tiers combine usefully: a user whose organization role grants only policy:create can still edit, train and delete the policies they created, because creating one grants them dynamoguard:policy:owner on it.

There is no group or team tier

An organization administrator sees every resource. Everyone else sees only what they own or what has been explicitly shared with them. No role grants visibility of a colleague's resources, so plan sharing before onboarding a team.

Organization-Level Roles

These roles are assigned in Keycloak, either directly or through an identity-provider mapper. Read what a user actually holds with the command in Verifying Effective Roles.

DynamoGuard

Role	Policy	Model	AI System
org:dynamoguard:admin	create, get, edit, delete, train, apply	create, get, edit, delete, share, getGuardDashboard, getAssociatedPolicies, getMonitoringLogs, applyPolicy	create, get, edit, delete, managePolicies, manageAISystems, managePoliciesOnAISystems
org:dynamoguard:developer	create	create	create
org:dynamoguard:member	none	none	none
org:dynamoguard:extensionAdmin	create	create, createSelfManaged	none
org:dynamoguard:extensionUser	none	none	none

member grants no scopes on any resource type. A user holding only member can sign in and see the interface, and every create action is denied.

DynamoEval

Role	Model	Dataset	Custom RAG Application
org:dynamoeval:admin	create, get, edit, delete, share, and the full test and report set	create, get, edit, delete, share, createTest	create, get, update, delete
org:dynamoeval:developer	create	create	create
org:dynamoeval:member	none	none	none

IAM and Platform

Role	Scopes
org:iam:admin	user:create, user:edit, user:resetPassword, user:delete, user:get, user:setRole
org:iam:editor	user:create, user:get, user:setRole
org:iam:viewer	user:get
org:platform:admin	billing:createReport, billing:getTokenUsage, billing:getReport, billing:updateReport

Administrative configuration requires org:iam:admin

Per-user platform configuration, including DynamoGuard access activation, is written through an endpoint gated on org:iam:admin. Confirm that at least one account holds this role and that it is reachable without the identity provider, because a mapper that grants it can fail at the same time it is needed.

Resource-Level Roles

These roles are attached to a single resource, either by creating it or by having it shared. They are never assigned organization-wide.

Resource	Role	Scopes
Policy	dynamoguard:policy:owner	get, edit, delete, train, apply
Policy	dynamoguard:policy:editor	get, edit, train, apply
Policy	dynamoguard:policy:viewer	get
AI System	dynamoguard:application:owner	get, edit, delete
AI System	dynamoguard:application:editor	get, edit, managePolicies, manageAISystems, managePoliciesOnAISystems
AI System	dynamoguard:application:viewer	get
Model	dynamoguard:model:owner	get, edit, delete, getGuardDashboard, getAssociatedPolicies, getMonitoringLogs, applyPolicy
Model	dynamoguard:model:editor	get, edit, getGuardDashboard, getAssociatedPolicies, getMonitoringLogs, applyPolicy
Model	dynamoguard:model:viewer	get, getGuardDashboard, getAssociatedPolicies, getMonitoringLogs
Model	dynamoguard:model:extensionUser	get
Model	dynamoeval:model:owner	get, edit, delete, and the full test and report set
Model	dynamoeval:model:editor	get, edit, createTest, updateTest, and the report set
Model	dynamoeval:model:viewer	get, getTest, getAllTests, getTestReport, getTestReportDeepDive, getMetricsFromTests, getEvalDashboard
Dataset	dynamoeval:dataset:owner	get, edit, delete, share, createTest
Dataset	dynamoeval:dataset:editor	get, edit, share, createTest
Dataset	dynamoeval:dataset:viewer	get, createTest
Custom RAG Application	dynamoeval:cra:owner	get, update, delete
Custom RAG Application	dynamoeval:cra:editor	get, create, update
Custom RAG Application	dynamoeval:cra:viewer	get

An editor cannot delete, and an owner cannot always create

editor omits delete on every resource type. owner omits create, because creation is an organization-level decision. A user who owns a policy but lost their organization role can still edit that policy and cannot make another.

Choosing a Role

The user needs to	Assign
Build and manage their own policies, models or AI systems	org:dynamoguard:developer
Manage resources created by other people, or see everything	org:dynamoguard:admin
Run evaluations against their own models and datasets	org:dynamoeval:developer
Read only, with specific resources shared to them	member, plus a resource-level share
Invite users and set roles	org:iam:editor
Write per-user platform configuration	org:iam:admin

Assign the narrowest role that completes the task. developer covers the entire authoring workflow for a user's own work, including behavior generation on a policy they created, because ownership supplies the edit scope.

Verifying Effective Roles

Read what the platform resolved, rather than inferring it from the Keycloak console:

Read a user's effective org-level roles

curl -s -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://api.<domain>/v1/user/all?includeOrgLevelRoles=true" \
  | jq '.users[] | select(.email=="USER_EMAIL") | {email, orgLevelRoles}'

An empty orgLevelRoles array on a federated user means no identity-provider mapper matched. See Claim-Mapped Roles Missing, and note that a user in this state receives a server error rather than a permission denial.

Related

• Understanding Access — how the access model fits together
• Roles — what each role is intended for
• User Management — assigning roles in the interface
• Adding Mappers — granting these roles from identity-provider claims