Aegisify AI Alerts: Turn Completed Scan Findings Into Focused WordPress Security Notifications
Aegisify AI Alerts lets security teams define what deserves attention after a supported security scan completes. Scope an alert to one authorized WordPress domain or the account’s targets, set a minimum severity and evidence-matching rule, choose immediate or recurring delivery, and route the matched findings to approved notification recipients.
Use saved alerts to turn normalized scan evidence into a repeatable notification rule: match the finding conditions that matter, deliver the right context, and keep lower-priority noise from overwhelming the people responsible for action.
How a Saved Alert Moves From Scan Completion to Notification
The current alert engine evaluates stored normalized findings after supported Aegisify scans finish. It does not launch a new scan simply because an alert exists.
Click a stage to expand
01DefineDomain or global rule
02Complete ScanFinding evidence arrives
03FilterSeverity + evidence
04MatchFinding context
05RouteImmediate or scheduled
06NotifySMTP or custom email
Aegisify AI Alerts Is a Finding-Detection and Notification Layer—Not Another Scanner
The feature starts with findings that Aegisify has already produced. It does not independently crawl the website, inspect source code, fetch WordPress telemetry or create vulnerability evidence.
When a supported security scan completes, Aegisify’s scan workflow finalizes its findings and then gives enabled saved alerts an opportunity to evaluate that completed result. Each alert defines the target scope, minimum severity, optional keywords, evidence area to search, notification schedule and destination behavior.
This makes AI Alerts useful for operational questions such as: notify the security team when a High or Critical finding relates to a specific technology or control family; create a global rule for a recurring class of issue; send a notification immediately for urgent findings; or collect matching findings into a scheduled digest when the organization prefers fewer interruptions.
Create a Structured Rule Directly or Ask Aegisify AI to Build It
The current feature supports both explicit alert configuration and natural-language AI-assisted alert creation.
Define the Security Condition Yourself
A saved alert can carry a name, on/off status, minimum severity, match scope, one or more keywords, explanatory notes, delivery schedule and destination settings. The notification can also be configured to include affected-path context, finding details and remediation guidance when those fields are available in the matched finding.
Describe the Alert in Plain English
Aegisify AI can translate a natural-language instruction into the supported alert structure. The AI is constrained to the existing alert fields: it cannot create arbitrary database columns, redefine the application’s schema or invent a new alert engine. The generated definition is normalized and validated before it is saved.
Modify an Existing Alert Without Rebuilding It
The AI builder can receive the current saved definition and update the supported fields requested by the user while preserving the rest of the alert context. This makes natural-language editing possible without treating the AI response as unrestricted configuration code.
Turn a Security Conversation Into a Saved Alert
Supported Aegisify AI Select follow-up requests can hand an alert or notification instruction into the same saved-alert workflow. The resulting rule remains a normal validated alert that evaluates future completed scan findings; creating it does not retroactively rerun old scans.
A New Alert Starts With a High-Severity, Details-Focused, Immediate Notification Profile
These are the current application defaults in the supplied 1.3.5-rev1 implementation. They are starting values, not recommendations for every environment.
New alert definitions are enabled by default.
High and Critical findings meet the default threshold.
Keyword evaluation defaults to finding-detail evidence.
A matching completed scan is routed without waiting for a digest cycle.
Uses approved finding-alert recipient profiles for the applicable domain.
Included when the matched finding contains path/resource context.
Finding detail text is included when available.
Recommended remediation is included when the finding provides it.
Keywords are optional. When no keywords are supplied, the alert behaves as a severity-based rule. A name can be supplied explicitly; if it is omitted but the rule contains enough keyword or severity context, the current implementation can generate a descriptive default name.
Alert definitions also support Daily, Weekly and Monthly schedules. When a recurring definition does not provide a usable schedule time, the current implementation normalizes the time to 09:00 in the WordPress application’s configured timezone; weekly scheduling normalizes to Monday and monthly scheduling to day 1 unless another valid value is supplied.
Filter on the Risk Threshold First, Then Look for the Evidence You Care About
An alert only matches findings that meet its configured severity floor. Keywords then narrow the result further when keywords are present.
The supported minimum-severity levels are Any, Critical, High, Medium, Low and Info. A High alert therefore evaluates High and Critical findings, while a lower minimum threshold can broaden the eligible finding set.
Keywords can be used to focus the rule around a technology, control name, vulnerability class, provider, security concept or other text present in the normalized finding evidence. Multiple keywords can be supplied. If no keyword is configured, every finding that meets the severity requirement is eligible.
Use One Alert for example.com—or Apply the Rule Across Authorized Targets
The alert engine supports both domain-specific and global account scope while preserving domain ownership and recipient routing.
Domain-Specific Alert
A rule scoped to example.com evaluates completed scans for that authorized target. The account must own the selected Target Domain before the alert can be created or reassigned to it.
Global Alert
A global rule can evaluate supported completed scan findings across the user’s authorized target domains. The matched finding still preserves its originating domain so notification routing and scan context remain tied to the correct site.
Account State Still Applies
Alerts remain part of the Aegisify account security boundary. Scheduled processing does not continue as though an account were active when the associated account is locked.
Choose Between Fast Escalation and a Consolidated Notification Cycle
The match condition and the notification cadence are separate decisions.
Scheduled delivery is processed by Aegisify’s recurring background scheduling workflow. The schedule controls when accumulated matching evidence is delivered; it does not control when the underlying security scan runs. Scan cadence and alert-delivery cadence therefore remain separate operational choices.
Route Findings Through Approved SMTP Profiles or a Valid Custom Address
The current destination model supports the account’s standard finding-notification recipients and a custom-email mode.
SMTP Default uses the per-domain notification profiles configured for new Critical and High findings. Aegisify respects the recipient’s domain authorization and whether that recipient is configured for Critical findings, High findings, or both.
This creates an important operational boundary: the default SMTP recipient profiles are designed around Critical and High finding notifications. If an alert definition is intentionally broadened to Medium, Low or Info findings and those lower-severity matches also need email delivery, the current implementation requires an appropriate custom destination rather than silently sending lower-severity findings to recipients who only opted into Critical/High notifications.
Custom Email can route the matched alert to a valid configured address for the alert definition. This can be useful for a dedicated security mailbox or another approved operational destination.
Deliver Enough Evidence to Triage the Finding Without Requiring a Blank-Slate Investigation
The current email workflow can combine alert metadata with selected finding context from the completed scan.
Name, Domain, Scan and Match Policy
A notification can identify the saved alert, the affected Target Domain, the completed scan context, the minimum severity, the evidence area used for matching and the alert’s notification cadence.
Severity, Title and Provider
Each matched finding can carry its severity, finding title and relevant provider/source context so the recipient knows why the item entered the alert.
Affected Path and Finding Details
When the alert definition enables them and the finding contains the data, the message can include the affected file/resource path and the normalized finding detail text.
Remediation Guidance and Alert Notes
The notification can include the finding’s remediation guidance and the saved alert definition/notes so the recipient has both the matched condition and the response context available for review.
AI Alerts Does Not Directly Fetch WordPress Evidence
The alert engine reads normalized completed-scan findings. It does not independently invoke the Audit Agent, WordPress sensors, telemetry, debug logs or application logs.
A finding evaluated by AI Alerts may have originated from a scan that used Aegisify Agent evidence. A Static Code Analysis result, vulnerability assessment or another supported scan may include WordPress-side intelligence that the scan workflow previously collected. Once normalized as a finding, that result can be evaluated by the saved alert.
However, creating or enabling an alert does not connect the Agent, enable Activity Log sensors, alter Telemetry Access Control, fetch WordPress Debug Log data, fetch Application Logging sources, or launch a new static or dynamic assessment.
Saved Alerts Stay Inside the Existing Aegisify Account and Finding Model
The feature uses several boundaries to keep AI-assisted alert creation from becoming arbitrary application configuration.
Turn Rules On or Off, Edit Them as Risk Changes, and Remove Rules You No Longer Need
A saved security rule should evolve with the environment rather than becoming permanent configuration that nobody reviews.
The current Alerts workflow maintains saved definitions with target scope, alert name, keywords, enabled status, minimum severity, match scope, delivery schedule, destination summary and update time. Alerts can be edited, enabled or disabled, and deleted.
This makes it possible to keep a useful rule without receiving notifications during a temporary maintenance window, tighten a broad keyword definition after observing too many matches, change the severity threshold when operational risk changes, or retire an alert after a migration removes the technology or control it was meant to watch.
Common Questions About Aegisify Security Finding Alerts
Does creating an AI Alert run a scan?
No. AI Alerts evaluates normalized findings after supported scans complete. The scan itself must be started or scheduled in the appropriate Aegisify security-scan workflow.
What is the default minimum severity?
The current default is High, which means High and Critical findings meet the severity threshold before any configured keyword matching is applied.
Do I have to provide keywords?
No. Keywords are optional. An alert without keywords can operate as a severity-only rule. When keywords are configured, they are evaluated within the selected Control, Details, Provider or Any evidence scope.
Can one alert apply to every authorized domain?
Yes. The current implementation supports a global alert scope as well as a rule tied to a single authorized Target Domain such as example.com.
What delivery schedules are supported?
The current saved-alert model supports Immediate, Daily, Weekly and Monthly delivery. Immediate delivery reacts after matching completed scans; recurring schedules collect matching findings for their configured delivery cycle.
Where do SMTP Default alert emails go?
They use the approved per-domain notification recipient profiles for new Critical and High findings. Recipient routing respects whether each profile is configured for Critical findings, High findings or both.
Can a Medium or Low alert use SMTP Default recipients?
The current SMTP recipient profiles expose Critical and High finding preferences. Medium and lower matches therefore require a valid custom destination if those findings need email delivery rather than remaining only as matched alert evidence.
Does AI Alerts use the Audit Agent or Activity Log sensors?
Not directly. It evaluates stored normalized scan findings. Those findings may originate from an Agent-assisted scan, but the alert workflow itself does not connect the Agent, enable sensors or request new telemetry.
Can I create an alert from an AI Select conversation?
Yes. When a supported AI Select follow-up clearly requests an alert or notification rule, the current implementation can create and save a validated alert definition tied to that conversation and domain context.
Does a newly created alert evaluate old scans retroactively?
The supplied implementation processes alerts as supported scans complete. Saving a new alert does not automatically rerun or backfill historic scan jobs. Run a fresh assessment when you want the new rule evaluated against current evidence.