Aegisify company logo

When should administrators use Auto-profiles for tagging/reporting (when enabled) in Aegisify WAF?

Technical summary

When should administrators use Auto-profiles for tagging/reporting (when enabled) in Aegisify WAF? is part of the WAF request-inspection, enforcement, visibility, or exception-management surface. 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 → WAF Rules / Settings. 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
wp_protect.rest_route_auto_profiles 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.
ai_security.auto_detect_routes 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.

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

Use the feature’s logs and current request evidence as the tuning source. Compare normal traffic with the event that triggered the control, then change only the smallest setting required.

Technical keywords

Aegisify WAF, 1.20.13, auto, enabled, profiles, reporting, tagging, wp_protect, rest_route_auto_profiles, ai_security, auto_detect_routes

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.

2026-01-12T23:30:46+00:00January 12th, 2026||

Find this article interesting, please share.