You will need to turn on WordPress Sensors for Aegisify Audit to be able to fetch, ingest and analyze your site for you.

Go to your wordpress wp-admin -> Aegisify Audit Agent -> WordPress Activity Log
– Enable all the sensors you want from your wordpress application and website.
– You can specify the Severity or keep it default

You will need to allow Aegisify Audit access to fetch the logs.

Log into the Aegisify Dashboard and click Fetch WP Logs Now to fetch all logs.

How to Enable Debugging in WordPress for Aegisify

WordPress includes built-in debugging tools that can capture PHP errors, warnings, notices, plugin conflicts, and other technical issues. Aegisify Audit can retrieve this debugging information through the Aegisify Audit Agent, but WordPress, the Agent, and Aegisify Audit SaaS must all reference the same debug log file.

Instead of using the default /wp-content/debug.log, Aegisify supports a custom log location such as:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Using a custom filename also makes the debugging file less predictable than the standard debug.log filename.

Before You Begin

Before editing wp-config.php, create a recent backup of the website or make the change in a staging environment when possible.

You will configure the debug location in three places:

1. WordPress wp-config.php

2. Aegisify Audit Agent

3. Aegisify Audit SaaS

The path configured in all three locations must identify the same file.

For this example, we will use:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

---

Step 1: Access Your WordPress Files

Access the WordPress installation using one of the following:

• FTP or SFTP

• Your hosting provider’s file manager

• cPanel

• Plesk

• Another server-management interface provided by your host

Open the root directory of the WordPress installation and locate:

wp-config.php

---

Step 2: Configure the Custom Debug Log in wp-config.php

Open wp-config.php and look for an existing WordPress debugging configuration.

You may find:

define( 'WP_DEBUG', false );

Replace the existing debugging configuration, or add the new configuration before:

/* That's all, stop editing! Happy blogging. */

Use:

define( 'WP_DEBUG', true );

define(
    'WP_DEBUG_LOG',
    __DIR__ . '/wp-content/path/to/file/file-dweih32afhi325oho23.txt'
);

define( 'WP_DEBUG_DISPLAY', true );

@ini_set( 'display_errors', 0 );

WordPress supports setting WP_DEBUG_LOG to a valid file path instead of only setting it to true. This causes WordPress debugging output to be written to the specified file rather than the standard /wp-content/debug.log.

In this example, the physical log file is:

<WordPress installation>/wp-content/path/to/file/file-dweih32afhi325oho23.txt

The corresponding portable path that will be entered into Aegisify Audit and the Aegisify Audit Agent is:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Do not enter __DIR__ into Aegisify Audit or the Agent. __DIR__ is PHP syntax used inside wp-config.php. Aegisify uses the WordPress-content-relative path beginning with /wp-content/.

---

Step 3: Save wp-config.php

Save the updated wp-config.php file.

If you are using FTP or SFTP, upload the modified file back to the WordPress installation.

The custom directory must exist and the WordPress/PHP process must be able to write the configured log file.

Your WordPress configuration should now point debugging to:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

---

Step 4: Configure the Same Path in Aegisify Audit Agent

In WordPress Administration, go to:

Aegisify Audit Agent → Agent Settings and Logs → WordPress Debug

Locate:

Location of Debug Log

Enter exactly:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Save the location.

The Agent path must match the file configured in wp-config.php.

After saving, the Protected Debug Log Viewer should read debugging information from that configured file.

If wp-config.php contains:

__DIR__ . '/wp-content/path/to/file/file-dweih32afhi325oho23.txt'

the Agent must contain:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

---

Step 5: Configure the Same Path in Aegisify Audit SaaS

Log in to Aegisify Audit and open the WordPress logging page for the appropriate Target Domain.

Under:

Debugging

locate:

Location of Debug Log

Enter exactly:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Save the location.

The SaaS configuration and Agent configuration must be identical.

Correct:

WordPress:
__DIR__ . '/wp-content/path/to/file/file-dweih32afhi325oho23.txt'

Aegisify Audit Agent:
/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Aegisify Audit SaaS:
/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Incorrect:

Agent:
/wp-content/debug.log

SaaS:
/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Aegisify intentionally requires the Agent and SaaS Debugging locations to agree so that a request cannot silently retrieve debugging information from a different file than the one configured for the site.

---

Step 6: Reproduce the Problem

Return to the WordPress site and repeat the action that generated the issue.

Examples include:

• Reloading the page that produced an error

• Submitting a form again

• Running the plugin feature that failed

• Repeating an administrative action

• Running a scheduled task

• Reproducing an AJAX or REST API failure

WordPress can record errors generated during requests that are not directly visible in the browser, which is one of the primary uses of WP_DEBUG_LOG.

---

Step 7: Verify the Protected Debug Log Viewer

Return to:

WordPress Admin → Aegisify Audit Agent → Agent Settings and Logs → WordPress Debug

Under:

Protected Debug Log Viewer

verify that entries from the custom file are displayed.

The Agent should now be reading:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

instead of assuming:

/wp-content/debug.log

If the expected entries do not appear, first verify that the path saved in the Agent is identical to the path configured in wp-config.php.

---

Step 8: Fetch the Debugging Log into Aegisify Audit

In Aegisify Audit, select the correct Target Domain and verify that Location of Debug Log is:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Then click:

Fetch WP Logs Now

The expected flow is:

WordPress
   ↓
Custom Debug File
   ↓
Aegisify Audit Agent
   ↓
Authenticated Aegisify Communication
   ↓
Aegisify Audit SaaS
   ↓
Debugging Ingestion and Analysis

The Agent retrieves the configured file and Aegisify Audit ingests the returned debugging information.

For this process to succeed, these locations must match:

wp-config.php:
__DIR__ . '/wp-content/path/to/file/file-dweih32afhi325oho23.txt'

Agent:
 /wp-content/path/to/file/file-dweih32afhi325oho23.txt

SaaS:
 /wp-content/path/to/file/file-dweih32afhi325oho23.txt

If the Agent and SaaS paths do not match, correct the configuration before fetching again.

---

Step 9: Review the Latest Debugging Information

After the fetch completes, Aegisify Audit displays the retained Debugging information associated with the selected Target Domain.

Use the latest entries to investigate:

• PHP errors

• PHP warnings

• PHP notices

• Plugin failures

• Theme failures

• Background-processing errors

• REST or AJAX problems

• Scheduled-task failures

• Other WordPress application errors captured by the configured debug log

The physical debugging file remains on the WordPress server while Aegisify uses its authenticated Agent communication to retrieve the authorized debugging information.

---

Step 10: Turn Debugging Off When It Is No Longer Required

WordPress recommends debugging features primarily for development and troubleshooting rather than leaving them unnecessarily enabled on a production website.

When troubleshooting is complete, change:

define( 'WP_DEBUG', true );

to:

define( 'WP_DEBUG', false );

You can leave the custom file path documented so it is available the next time debugging is intentionally enabled.

---

Recommended Aegisify Debug Configuration

WordPress wp-config.php:

define( 'WP_DEBUG', true );

define(
    'WP_DEBUG_LOG',
    __DIR__ . '/wp-content/path/to/file/file-dweih32afhi325oho23.txt'
);

define( 'WP_DEBUG_DISPLAY', true );

@ini_set( 'display_errors', 0 );

Aegisify Audit Agent:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Aegisify Audit SaaS:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

The important rule is:

The custom Debugging file configured in wp-config.php, Aegisify Audit Agent, and Aegisify Audit SaaS must all reference the same WordPress debug file.

Important Note About Displaying Errors

The configuration above uses:

define( 'WP_DEBUG_DISPLAY', true );

With WP_DEBUG_DISPLAY enabled, WordPress may display debugging messages in applicable page output. WordPress documents WP_DEBUG_DISPLAY as the control for whether debugging messages are shown in generated HTML.

If the objective is to log errors without displaying WordPress debugging information to website visitors, use:

define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

while keeping the same custom WP_DEBUG_LOG location.

Step 1:
1) Download Agent

2) Login to your WordPress Admin -> Plugins -> Add Plugins -> Upload Plugin -> select the download, install and Activate
3) Once installed, verified, the agent will run a local scan.

Step 2: Add Domain below -> Create a txt DNS record with the details below -> click Verify Record
1) Log In: Sign in to the dashboard of the domain registrar or hosting provider where you purchased your domain (e.g., GoDaddy, Cloudflare or Any Hosting Provider).
2) Find DNS Settings: Navigate to the DNS Management, DNS Zone Editor, or Advanced DNS settings page.
3) Add Record: Click to add a new record and select TXT (or Text) as the record type.
4) Enter the Details:
– Name/Host: Enter @ to apply the record to your root domain, or input a specific subdomain if instructed by your service provider.
– Value/Content: Paste the exact text string provided by the third-party service.
– TTL (Time to Live): Leave this at the default setting (often 1 hour or 3600 seconds) unless the service requested otherwise.
5) Save: Save your changes. Keep in mind that DNS updates can take anywhere from a few minutes up to 48 hours to fully propagate globally.

Step 3: From SaaS Domain Settings page, click to expand “Agent Details” below, copy the generated Encryption / Security Key

Step 4: Go back to Destination WordPress Website, In WordPress Admin -> Open “Aegisify Audit Agent” from the left menu and open the Agent -> Paste the Encryption / Security Key. Click the wide blue button “Save Encryption Key”.

Step 5: Go back to SaaS Domain Settings page, under “Agent Details” below and click on “Connect Over SSL” and view the connectivity logs. It should say Success -> Agent Verified Succeeded.

This card provides an operational summary of account consumption, verified asset readiness, reporting state, and latest scan/report activity. It is intended to help administrators, security leads, and program owners understand whether the account is properly configured, actively connected, and producing usable reporting artifacts.

This subcard summarizes domain consumption against the account’s allowed capacity. It is used to track whether the organization is approaching or exceeding its licensed target limit.

This subcard reports how many domains have completed ownership validation. It is an important governance indicator because verified ownership is foundational to authorized scanning and reporting.

This subcard reports how many verified domains currently maintain active remote agent connectivity. It indicates whether deeper defensive and log-based features are operational across the expected target set.

This subcard summarizes scan history across the major scan families within the account scope. It provides a concise view of which assessment tracks are contributing data to the dashboard.

This subcard identifies the most recently generated report in the current scope. It gives the user a direct reference point for the latest formal reporting artifact available.

This subcard reports how many downloadable export files are currently available in scope. It is a practical indicator of reporting volume and artifact readiness for distribution or retention.

This subcard records when the most recent scan completed. It helps the user assess how current the visible posture and reporting state are.

This subcard identifies the most recent scan profile completed in scope. It provides clarity on what type of assessment most recently informed the dashboard.

This subcard reports the current count of findings tied to the latest scan state. It is intended to give a compact indication of whether the latest completed assessment surfaced unresolved issues.

The Compliance Insights card is the comparative control-gap view for the selected scope. It translates compliance findings into operationally meaningful analysis so leadership and technical teams can understand where the environment is diverging from expected baseline, what changed recently, and where remediation should be prioritized.

This subcard provides an AI-generated interpretation of compliance posture, recent control regressions, and remediation direction. It is intended to convert raw control observations into a prioritized narrative that is useful for both governance and engineering audiences.

This subcard reports the total number of compliance findings currently present in scope. It provides a concise measure of control deviation at the present point in time.

This subcard reports how many compliance findings were introduced in the latest cycle. It is important for identifying whether the control posture is deteriorating.

This subcard reports how many compliance findings were cleared since the prior comparison point. It reflects whether remediation activity is improving the control environment.

This subcard reports how many control or evidence providers contributed to the current compliance view. It indicates the breadth of supporting input behind the result set.

This section highlights newly introduced compliance observations that have the greatest operational or governance significance. It is designed to direct attention to the issues most likely to affect policy, audit readiness, or platform assurance.

This section presents the most recent significant compliance observations now present in the environment. It helps the user quickly understand what is currently driving the compliance posture.

The Vulnerability Insights card is the executive and technical view for known vulnerability exposure in the selected scope. It is designed to show whether vulnerability risk is changing, whether dependency exposure is being introduced, and whether any high-priority intelligence such as KEV alignment is present.

This subcard provides an AI-generated interpretation of the vulnerability state, including operational blockers, coverage gaps, and remediation priorities. It is intended to help users distinguish between true vulnerability movement and scan execution problems.

This subcard reports the number of known vulnerabilities currently present in the selected scope. It provides the clearest high-level count of recognized software exposure.

This subcard reports the number of identified dependency-related risks affecting the environment. It is used to summarize software supply chain exposure at a glance.

This subcard reports whether any vulnerabilities align to known exploited vulnerability intelligence. It is a prioritization signal intended for rapid risk escalation where exploitation relevance is known.

This subcard reports how many new vulnerability items were introduced in the latest comparison cycle. It helps determine whether exposure is actively increasing.

This section explains whether the current cycle introduced any newly identified vulnerabilities. It provides narrative context behind the numeric summary.

This section explains whether any previously identified vulnerabilities were cleared between the last two comparable scans. It is intended to show measurable remediation progress.

This card is the executive delta view between comparable scans. It focuses specifically on change in the highest-priority finding tier so decision-makers can determine whether risk is newly emerging, being reduced, or simply persisting over time.

This section provides the headline interpretation of the current security state. It is designed to communicate whether posture is stable, improving, or degrading, and whether any immediate executive concern exists.

The Site Drift card is the operational change-analysis view for the selected domain. It is intended to explain how site composition, inventory, and environment movement may have changed since the prior scan, and to provide AI-assisted interpretation of what those changes mean for security and stability.

This subcard provides an AI-generated interpretation of what changed, what should be reviewed, and where remediation or validation should begin. It is designed to turn raw drift signals into a structured operational assessment.

This subcard reports newly observed components or assets since the prior comparison point. It helps teams detect expansion of inventory, newly deployed functionality, or fresh attack surface.

This subcard reports components or assets no longer observed in the current cycle. It is useful for tracking decommissioning, rollback, or potential visibility gaps.

This subcard reports components whose version state changed between scans. It is especially important for patch validation, regression tracking, and change-control review.

This subcard reflects the currently observed component inventory for the selected scope. It serves as the present-state baseline for drift comparison and exposure review.

The AI Summary card is the executive narrative layer of the dashboard. It translates posture, findings, scan history, and operational conditions into a structured summary that can be consumed by leadership, security management, architects, and engineers without requiring them to manually interpret every underlying metric.

This section provides the headline interpretation of the current security state. It is designed to communicate whether posture is stable, improving, or degrading, and whether any immediate executive concern exists.

This section presents the core operating indicators behind the AI narrative, including posture score, overall risk level, and open findings. It serves as the factual anchor for the broader executive interpretation.

This section explains whether meaningful environmental or finding-level change has occurred since the prior assessment. It helps the reader understand whether the current posture reflects stability, regression, or operational disruption.

This section provides immediate next-step guidance based on the current state. It is intended to direct engineering and security teams toward the most important operational or remediation action rather than offering generic advice.

This card summarizes the current state of the defensive scan family for the selected scope. It compares historical and current execution, surfaces the latest profile in use, and provides a concise delta view so defensive posture can be reviewed quickly.

Scan Profile

This subcard identifies the defensive profile most relevant to the current comparison. It tells the user what type of defensive analysis is informing the displayed posture and trend.

Previous Scan

This subcard records the prior completed defensive scan used as the comparison baseline. It is important for understanding the time reference behind drift and delta calculations.

Current Scan

This subcard records the most recent completed defensive scan in scope. It establishes the latest point of reference for posture and findings interpretation.

Current Critical + High

This subcard shows the number of currently open top-severity defensive findings. It is the fastest measure of whether the latest defensive state includes urgent unresolved issues.

New Critical + High

This subcard shows how many top-severity defensive findings were introduced in the latest cycle. It helps determine whether new risk has emerged rather than simply persisted.

Resolved Critical + High

This subcard shows how many top-severity defensive findings were cleared between the prior and current cycles. It indicates whether remediation activity is materially reducing risk.

Posture Delta

This subcard shows the directional change in defensive posture between the compared scans. It is intended to convey improvement, regression, or stasis in a single compact metric.

This card summarizes the state of the offensive scan family for the selected scope. It shows whether standard dynamic testing is actively contributing comparable data and makes gaps in offensive coverage immediately visible.

Scan Profile

This subcard identifies the offensive profile used for comparison when available. It tells the user what category of dynamic assessment is expected to inform the current state.

Previous Scan

This subcard records the last completed offensive scan in the comparison chain. It clarifies whether there is a valid offensive baseline available.

Current Scan

This subcard records the most recent completed offensive scan. It indicates whether the dashboard has current offensive evidence or whether the scope lacks recent runtime assessment.

Current Critical + High

This subcard reports the currently open top-severity offensive findings. It provides a direct view into the highest-signal runtime exposure still present.

New Critical + High

This subcard reports newly introduced top-severity offensive findings in the latest cycle. It helps distinguish fresh runtime exposure from older unresolved issues.

Resolved Critical + High

This subcard reports the number of offensive critical and high issues cleared since the prior cycle. It provides a concise signal of remediation progress in the offensive track.

Posture Delta

This subcard shows whether the offensive scan family has materially improved, regressed, or remained flat since the prior comparison point.

This card summarizes the advanced scan family for the selected scope. It is intended to capture deeper or specialized assessment activity and present its comparative state in the same executive format used across the platform.

Scan Profile

This subcard identifies the advanced scan profile contributing to the comparison. It clarifies which specialized assessment lens is represented in the card.

Previous Scan

This subcard records the previous completed advanced scan available for comparison. It provides the historical reference for delta and resolution analysis.

Current Scan

This subcard records the current completed advanced scan used in the card. It defines the latest specialized assessment baseline available to the dashboard.

Current Critical + High

This subcard reports how many critical and high findings currently remain open in the advanced scan family.

New Critical + High

This subcard reports how many top-severity advanced findings were introduced in the latest comparison cycle.

Resolved Critical + High

This subcard reports how many advanced critical and high findings were closed between the prior and current scans.

Posture Delta

This subcard shows whether the advanced assessment family has improved, regressed, or remained stable relative to its prior comparison point.

The Main Menu is the primary navigation framework for the Aegisify Audit workspace. It gives the user structured access to executive dashboards, scan operations, domain administration, WordPress log ingestion, AI-assisted intelligence, and account configuration, ensuring that both operational workflows and governance tasks can be reached from a single control surface.

The Select Domain card sets the active scope for the dashboard and all related executive reporting. It ensures that metrics, AI summaries, findings, and account posture indicators are shown in the context of the selected verified asset rather than across unrelated targets.

The Select Domain card sets the active scope for the dashboard and all related executive reporting. It ensures that metrics, AI summaries, findings, and account posture indicators are shown in the context of the selected verified asset rather than across unrelated targets.

The Plan indicator confirms the subscription tier governing feature access, reporting depth, and scan availability. It helps the user understand whether the current experience reflects the licensed operating model.

The Analyze Now action refreshes the dashboard narrative and comparative reporting for the selected scope. It is the primary control used when the user wants the latest scan-derived interpretation surfaced immediately utilizing Artificial Intelligence.

This card identifies the tenant boundary under which all dashboard data is being presented. It is important for governance and multi-tenant clarity because it confirms that metrics, findings, and reports are constrained to the correct organizational account.

This card confirms the active asset scope for the current executive view. It makes clear which domain the current posture, findings, and comparative insights are tied to, reducing ambiguity when multiple targets exist under the same account.

This card presents the current risk state of the selected domain in a simplified executive form. It is intended to summarize the overall level of concern based on the latest completed scan results without requiring the user to interpret raw findings first.

This card provides a weighted security posture score for the selected scope. It offers an at-a-glance indicator of relative strength or deterioration, helping leaders and engineers gauge whether the environment is improving, stable, or regressing over time.

This card isolates the highest-priority open issues currently affecting the selected scope. It is designed to surface the clearest signal of present business and technical risk requiring immediate attention.

This card shows whether new top-severity issues have been introduced since the prior comparable scan. It is intended to help teams distinguish between existing known risk and newly emerging exposure.

This card highlights newly surfaced known vulnerabilities in the latest scan cycle. It is particularly useful for understanding whether recent changes, component updates, or missed coverage have introduced fresh software risk.

This card summarizes whether the observed site composition has changed between scans. It is a concise indicator of environmental movement that may explain new findings, altered posture, or changed attack surface.

This card reports the count of current compliance-related observations within the selected scope. It is intended to quantify control and baseline deviation in a way that is immediately useful for governance and remediation planning.

This card indicates how many completed scans are available for comparison and reporting. It helps the user understand the depth of available history and whether the environment has enough prior state for meaningful trend analysis.

This card shows how many domains have been ownership-validated within the account. It supports both governance and operational readiness by confirming how many assets are formally approved for managed assessment.

This card shows how many verified domains currently have active agent connectivity. It is a readiness indicator for deeper defensive and log-based capabilities that depend on live integration with the target environment.