Default-deny vs. fail-closed
Default-deny means a request is refused when no applicable permission allows it. Fail-closed means a control refuses the protected operation when it cannot establish the required safe or permitted condition. Fail-open allows the operation to continue under a defined control failure.
A system might deny an export because no policy permits it, yet let that same request through when the evaluator is unavailable. Test normal no-match behavior and failure behavior separately.
Explore Dome: Authorization · Docs: Authorization model.
Find out why the request was refused
Suppose an agent asks to export a dataset. Several different conditions can produce a denial.
| Condition | Policy or failure question |
|---|---|
| No permit covers the export | Is the normal decision default-deny? |
| A matching restriction forbids it | How are conflicting rules combined? |
| The evaluator cannot run | Does the control fail open or closed? |
| Required identity context is missing | Is the request invalid or is a defined policy outcome applied? |
| The available policy is too old | What freshness limit applies? |
If no policy permits the export, review the permission. If the evaluator is unavailable, investigate that failure instead. Retrying may help with a temporary outage, but it won't change an explicit policy denial.
Dome's authorization documentation separately describes no-match denial, evaluator errors, missing policy, and hosted policy-freshness behavior.
Explore Dome: Authorization · Docs: Authorization model.
Specify which operations stop, and when
A fail-closed gateway may refuse a model call while the agent process keeps running. Identify exactly which operation stops and whether the application can reach the same service by another route.
Cached policy introduces another condition. During a control-plane outage, a system may use a previously validated policy for a limited time, then refuse further requests. That behavior is different from both immediate shutdown and indefinite use of stale policy.
Write down what is cached, how freshness is measured, which requests are affected, and what event tells an operator why the request was refused. These details determine how fail-closed behavior affects the application.
The NIST zero trust architecture provides broader context for explicit resource-access decisions. The exact failure behavior depends on the implementation.
Explore Dome: Tool Gateway · Docs: Tools gateway.
Test the failure paths separately
For a controlled test, create an unmatched request, an explicitly forbidden request, and an evaluator or policy-availability failure. Define the expected outcome for each before running it.
Also test that a valid policy allows the work the application is intended to perform.
Recovery should keep the required checks in place. If an application responds to a policy-service failure by calling the backend directly with a different key, the application may bypass the check that was meant to stop it. Review retries and alternate routes as part of the test.
Save the expected outcome and observed result for each failure case, including missing context and stale policy. See runtime enforcement for checking that a refusal stops the operation, and failover for reviewing alternative model routes.
Explore Dome: Authorization · Docs: Simulate rules.