Guide
Trace an authorization decision across inherited rules
An agent-scoped permit is present, but the call is denied. Editing that permit repeatedly will not help if a matching forbid is active at organization scope.
Dome evaluates the rules that cover the agent as one effective set. Scope decides which bundles participate; a narrower scope does not give a permit extra weight. Trace the contributing rules before changing one of them.
Why is this export still denied?
The following example is illustrative policy logic, not deployable rule syntax. A support agent attempts a bulk export.
| Scope | Relevant contribution | Effect on this request |
|---|---|---|
| Organization | Forbid bulk customer export | Matches: denies |
| Tenant | Permit approved support operations | May match: cannot defeat a forbid |
| Workspace | Permit calls to the support service | Matches broadly: still cannot defeat a forbid |
| Agent | Permit this export for the named agent | Matches specifically: still cannot defeat a forbid |
The call is denied. Naming this agent more specifically doesn't override the organization forbid.
Now remove the organization forbid in a controlled candidate and keep the broad workspace permit. A narrow agent permit for ticket reads does not remove the workspace's broader allowance. This explains the opposite surprise: adding a more precise permit did not actually tighten the boundary.
The rules concept describes the participating bundles and evaluation semantics. Preserve the distinction between adding an allowance and constraining an existing allowance.
Look beyond hand-written rules
Effective rules include more than manually authored files. Dome also generates bundles from managed configuration such as allowed resources, act-as settings, and blocked tools. Those contributions can explain a result that is not visible in the file an author was editing.
Change a generated contribution through the feature that owns it. Do not treat a generated bundle as a hand-maintained policy file or roll it back independently of its owning configuration.
Use a diagnosis worksheet:
| Item | Record before editing |
|---|---|
| Request identity | Agent, represented-user context if applicable, and addressed scope |
| Operation | Action and resource actually evaluated |
| Contributing policy | Active user-authored and generated bundles at applicable scopes |
| Expected condition | The rule/attribute relationship the owner intended |
| Observed result | Verdict, relevant rule errors, and available deciding-rule provenance |
| Proposed owner | The scope or configuration feature that must actually change |
| Verification | Candidate test and post-change runtime evidence |
Keep the full worksheet with the incident. A screenshot of the agent's permit leaves out the other rules that may explain the denial.
Check which version the gateway used
An accepted management change and a request using that change are different observations. The gateway polls for effective-policy changes; the authorization model describes synchronization and fail-closed freshness behavior.
If the decision evidence points to an earlier effective version, investigate propagation before rewriting the policy. If a control refuses because policy is stale or missing, do not describe that as a matching business forbid unless the record supports it.
Save the old and new policy identifiers. Otherwise, you may credit an edit for a passing test that actually used a different version.
Change the contributing source, then retest
- Reproduce the surprising decision with the intended inputs.
- Identify all applicable contributions.
- Explain the result using permit/forbid semantics.
- Change the responsible user-authored bundle or managed configuration feature.
- Evaluate the intended candidate using the policy test matrix.
- Verify the expected effective version and protected neighboring cases on the controlled live path.
If the retained events lack the tool arguments or represented identity needed for a decision, add synthetic cases with those inputs. Historical replay alone cannot cover them.
For a broader tightening project, agree on the intended default-deny behavior and keep the candidate changes, test results, and rollout approval together. For this incident, start by identifying the rule or setting responsible for the surprising decision.