Once you know how a service policy matches a request, the remaining question is what happens on a match. That is the action, and it has a bit more nuance than allow-or-block.
The three actions
A rule's action is one of three values. ALLOW lets the request proceed. DENY terminates processing and returns an error to the client. NEXT_POLICY stops evaluating the current policy and moves to the next policy in the set, skipping any remaining rules in the current one. (The broader policy framework also documents actions like NEXT_POLICY_SET, LAST_POLICY, and GOTO_POLICY for chaining across policy sets, but the inline rule action is one of the three above, defaulting to DENY.)
The default is worth noting: if a rule does not state an action, it denies. Deny is the safe default at every level of this system.
Default deny
The most important behavior is not written on any single rule. If a request does not match any rule that allows it, it is denied. A service policy is fundamentally a list of reasons to allow (or to explicitly deny) a request; absence of a match means no.
This is why an empty rule_list denies everything, and why a rule_list that only contains DENY rules, with nothing to allow the rest, also denies everything that is not explicitly caught. When you audit a policy, the question is always: what, if anything, actually allows the traffic you expect to serve?
Whole-policy shortcuts
Not every policy uses a rule list. The rule choice can also be a blunt instrument: allow_all_requests permits everything that reaches the policy, and deny_all_requests blocks everything. These are legitimate but worth flagging, because an allow_all_requests policy performs no checks at all, and a stray one in a policy set can undo the intent of everything around it.
The allow_list and deny_list forms are source-based shortcuts. They match on where a request comes from (IP prefixes, prefix sets, ASNs, countries, TLS fingerprints) and carry a default action for the non-matching case. An allow_list allows matching sources and applies its default to the rest; a deny_list denies matching sources.
Modifiers: more than a verdict
A rule does more than allow or deny. On a match it can attach modifiers that shape how the request is handled: a waf_action (skip or customize App Firewall processing), a bot_action, rate limiters, an OpenAPI validation action, response masking, and others. These are not the verdict; they ride along with it. A rule can also carry an expiration_timestamp, after which it still exists in the config but is no longer applied, and a log_rule_evaluation flag that logs matches without changing the decision.
The explainer separates these clearly: it shows each rule's verdict as an allow, deny, or next-policy badge, lists the predicates that must match, and notes the modifiers that fire on a match, so the difference between "this rule decides the request" and "this rule also does something on the way" is never blurred.