Your agent may be allowed to read tickets and forbidden to export them. Who can change the rule that enforces that restriction? That's a separate permission to review.
Dome's management permissions govern people and API clients administering the platform. Runtime rules govern agent actions. A review that mixes them can approve the right runtime policy while leaving too many people able to replace it.
Use the worksheet below to check who can change the platform configuration, as well as what the agent can do.
Start with the work each person needs to do
List the actual operations each team needs: inspect audit evidence, export records, deploy rules, manage guards, register agents, or configure webhook delivery. Then use the current permission reference to find the required permission and the roles that carry it.
Role summaries are useful orientation; the per-operation matrix is the stronger source for a particular change. A role called “security” does not imply permission to administer every security-related object.
The following worksheet gives concrete starting points. Check the current reference when applying it; this is not a frozen substitute for the permission matrix.
| Duty | Permission to inspect | Assignment question |
|---|---|---|
| Read audit events | audit.view | Which scope does the reviewer need to see? |
| Export audit evidence | audit.export | Does the reviewer need export, not just view? |
| Deploy a user rules bundle | rules.deploy | Who may replace the active configuration? |
| Roll back rules | rules.rollback | Who owns the recovery decision? |
| Manage guards | guards.manage | Does the selected role actually carry this permission? |
| Register agents | agents.register | Are additional permissions needed for the requested access fields? |
| Configure subscriptions | eventing.manage | Who owns destinations and signing-secret handling? |
| Replay webhook delivery | eventing.replay | Who may trigger another delivery into the receiver? |
An operation can require a combination of permissions. Do not assume that permission to register an agent authorizes every access or delegation setting included in that request.
Check scope before granting more power
Dome's platform permission model follows the administrative hierarchy. Higher-scope grants can cascade into lower scopes.
If a person only needs to operate one workspace, start the review there. A tenant-level operator and a workspace-level operator are not interchangeable assignments merely because their role labels share a word. Their administrative reach differs.
Inspect all grants that apply to the person or API client. Removing a workspace membership does not establish least privilege if an organization-level grant still supplies broad authority.
For management API keys, inspect the explicit permissions and scope as well as the owning integration's operational purpose. Keep secret values out of the worksheet.
Work through two common mistakes
First, consider a developer who must test an agent and read relevant audit events. That does not automatically create a need to export the organization's audit corpus or deploy production rules. Check those duties separately. Developer access doesn't mean unrestricted operations access.
Second, consider a security reviewer responsible for rule changes. The current matrix permits rule deployment and rollback for the security role, but guard management belongs to the applicable admin/operator grants, not automatically to the security role. If that reviewer must also manage guards, make the extra operational requirement explicit instead of relying on the role's name.
These examples are administrative decisions. Neither grants the reviewer's agent runtime permission to call a backend tool.
Test the assignment with positive and negative cases
For each assignment, record one allowed operation and one neighboring operation that should remain unavailable.
A reviewer might be able to read audit events but not export them. A scoped management API key might permit replay without permitting changes to the subscription destination. The exact pair depends on supported assignments and permissions; do not invent a custom role the product does not provide.
Use a genuinely scoped test principal. A test performed with a second broad administrative grant can hide a broken least-privilege design. Record the expected and observed outcomes without placing credentials in logs.
For cross-workspace cases, use the scope-boundary acceptance suite. For runtime roles and attributes, use the authorization model explainer.
Keep the assignment and its tests together
The completed worksheet should name the duty, exact permission, scope, assignment mechanism, owner, positive test, and negative test. Revisit it when a team takes on a new operational responsibility or an integration gains a new management endpoint.
For each person or integration, another reviewer should be able to answer: what can they change, in which scope, and which nearby operation is still denied? Keep that answer separate from the agent's runtime permissions.