Technical summary
How does Rule “Contains (all)” matching (one token per line; ALL must match) work in Aegisify WAF, and what should administrators verify? governs deterministic inspection of AI-facing traffic, including prompt-injection signals, sensitive-data handling, provider/model policy, agentic action controls, signed actions, and resource budgets. This article is grounded in the supplied Aegisify WAF 1.20.13 plugin package. It documents current behavior and defaults rather than relying on older FAQ wording.
Where administrators configure or verify it
Primary wp-admin path: wp-admin → Aegisify WAF → AI Security. Exact controls can be distributed across the related tab/page when the feature is composed of multiple engines.
Current 1.20.13 defaults and related controls
The table below lists settings in the supplied current source that are directly related to this topic. The current default/bound/status shown is code-derived. Where the product does not define a named Medium preset, the shipped default is documented as the baseline operating point rather than inventing a value.
| Setting | Current default / bound / status | Why this default | How to tune safely |
|---|---|---|---|
custom_rules.allowed_actions |
Allowed values: ["log","block","skip_waf"] | This list is the current accepted-value set enforced by the supplied implementation. | Choose only from the supported set. Narrower methods/actions reduce unintended scope; unsupported values are normalized or rejected by the current implementation. |
custom_rules.allowed_methods |
Allowed values: ["ANY","GET","POST","PUT","PATCH","DELETE","HEAD","OPTIONS"] | This list is the current accepted-value set enforced by the supplied implementation. | Choose only from the supported set. Narrower methods/actions reduce unintended scope; unsupported values are normalized or rejected by the current implementation. |
managed_rules.challenge.enabled |
ON / true | Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. | ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. |
managed_rules.challenge.ttl_seconds |
1800 | The shipped value of 1800 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. | For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. |
custom_rules.action_default |
log | “log” is the shipped baseline so administrators can collect evidence and verify normal traffic or behavior before moving to stronger enforcement where applicable. | Use the shipped observation mode while establishing a baseline. Move toward enforcement only when logs show the signal is reliable. Returning to monitor/observe is preferable to disabling a control entirely during false-positive tuning. |
custom_rules.free_max_rows |
Maximum: 5 | 5 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. | Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. |
custom_rules.global_or_root_waf_exclusions_rejected |
Rejected | The current safety logic rejects this condition to prevent an overly broad security bypass. | This row documents fixed current-version behavior or a capability boundary. Change the related user-facing setting rather than attempting to tune this reference value. |
custom_rules.import_max_bytes |
Maximum: 524288 | 524288 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. | Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. |
Adjustment strategy
Change one control at a time, save it through the product UI, reproduce the legitimate and malicious/test flow, and review the product log/status surface. For enforcement controls, use Monitor/Observe first when normal behavior is uncertain; move to Block only after the signal is reliable. For thresholds, do not jump directly from the default to an extreme unless an active incident requires emergency containment and a recovery path exists.
Operational guidance
On a production WordPress site, a sudden block spike after a plugin/API deployment should first be investigated in WAF logs. Narrow the issue to the exact route, rule family, client identity, or payload characteristic. Prefer a precise exclusion/allowlist or threshold adjustment over disabling broad protection.
Technical keywords
Aegisify WAF, 1.20.13, all, contains, custom, line, managed, match, matching, must, one, per, rule, rules, signature, token
Source baseline
Verified package: Aegisify WAF 1.20.13. Primary source files: includes/class-aegiswaf-storage.php; includes/class-aegiswaf-ai-security.php; includes/class-aegiswaf-api-security.php; includes/class-aegiswaf-managed-rules.php; includes/ddos/class-aegiswaf-ddos-storage.php; includes/admin/pages/class-aegiswaf-page-waf-rules.php; includes/admin/pages/class-aegiswaf-page-logs.php; includes/admin/pages/class-aegiswaf-page-access.php. If a future plugin version changes these settings, support should re-read the installed version rather than carry these defaults forward automatically.