The default keyword gives a Rego rule a value to use when none of its definitions match. Writing default allow := false means any input that no allow rule approves gets false instead of an undefined result. That makes the policy fail closed, which is the safer behavior for access and deployment decisions.
The problem default solves
In Rego, a rule whose conditions are not met is not false. It is undefined. If your pipeline asks whether a request is allowed and the policy has no matching rule, the answer is undefined, and what happens next depends on the code that called the policy. Some callers treat undefined as a denial, others as a pass, and others as an error.
Setting a default removes the ambiguity. The OPA documentation explains that the default keyword defines a default value for documents produced by rules with complete definitions, and that the default is used when all the rules sharing that name are undefined.
A small example
The language reference shows this form:
package example
default allow := false
allow if {
input.user == "bob"
input.method == "GET"
}
With input where the user is bob and the method is GET, allow is true. For any other input, no allow rule matches, so allow takes its default of false. The docs note that without the default definition, allow would be undefined for the same input.
Allow lists and deny lists
| Style | Pattern | What an unexpected input does |
|---|---|---|
| Allow list | default allow := false, then rules that set allow | Denied, because nothing approved it |
| Deny list | default deny := false, then rules that set deny | Allowed, because nothing forbade it |
Neither is wrong. Use an allow list when the set of acceptable things is small and well understood, such as approved base images. Use a deny list when the set of bad things is small and the rest is fine, such as a handful of forbidden settings. For high risk decisions, prefer the allow list, since new unknown cases fail closed.
Rules about the default itself
The docs state that with the default keyword, the rule syntax is restricted: the form is default, a name, the assignment operator and a term. The term can be a scalar, a composite value or a comprehension, but it cannot be a variable or reference, and a composite value cannot contain variables or references. Defaults also work for functions.
Test the fall through case
A default is easy to forget and easy to break. Add a test that gives the policy an input nobody anticipated and asserts that the result is the default. See how to unit test a policy as code rule for the test conventions.
Do not confuse policy default with pipeline default
A fail closed policy still needs a decision about what the pipeline does when the policy engine itself is unreachable. That is a separate question, and it deserves its own written answer. Decide whether it fails open or fails closed, and write that down.
Where Safeguard fits
Safeguard provides policies, gates and guardrails for supply chain and dependency decisions without asking you to write Rego for those rules, so teams that want a fail closed baseline can start from managed policies. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does default allow := false mean everything is denied?
No. It means anything not approved by an allow rule is denied. Inputs that match an allow rule are still allowed.
What happens with no default at all?
The rule is undefined when nothing matches, and the result depends on how the calling code treats undefined. Set a default so the answer is explicit.
Sources
Last reviewed: 19 October 2026.
