Aegisify Master Dashboard and Account Intelligence Chat: Turn WordPress Security Evidence Into Clear Action
The Aegisify Master Dashboard brings stored security scans, vulnerabilities, code findings, dynamic testing, WordPress activity, hardening evidence, threat intelligence, software inventory, commerce risk, and Agent status into one domain-scoped command center. Account Intelligence Chat adds a controlled way to ask questions across that evidence without turning AI into an unrestricted account-search tool.
The dashboard does not manufacture a security score from missing data and the chat does not replace scanning. Both depend on evidence Aegisify has actually stored for the authorized account and domain.
How Security Evidence Moves From WordPress to a Decision
Open each stage for a high-level explanation. This public guide describes the product workflow without publishing private routes, request mechanics, security thresholds, or other implementation details that do not belong in public documentation.
Click a stage to expand
01AuthorizeAccount + permitted sites
02CollectStored security evidence
03NormalizeOne selected-domain view
04CorrelateNine evidence domains
05InterpretRisk Insight
06AskAccount Intelligence Chat
07ActPrioritize + verify
A Security Intelligence Layer Above the Individual Scanners
The Master Dashboard answers a different question than a vulnerability scanner, SAST engine, DAST engine, log viewer, or WordPress inventory page: what does all of the available evidence say about this domain right now?
Aegisify Audit produces evidence through multiple workflows. Static assessments can identify software, vulnerability, dependency, hardening, and code risk. Dynamic assessments can examine the live application, APIs, browser behavior, access control, and commerce workflows. WordPress and application logs add operational context. Agent-assisted inventory can add software and site context that an outside observer cannot reliably reconstruct. Threat-intelligence checks add reputation and exposure signals. The Master Dashboard is where those independent evidence streams are brought together for the selected authorized domain.
That distinction is important because the dashboard is not a hidden scan trigger. Loading the page does not automatically rerun SAST, DAST, vulnerability checks, inventory collection, or log ingestion. It reads what is already stored for the account and domain, identifies which sources are present, and reports missing or unavailable evidence rather than silently inventing a result.
The current implementation is also license-aware and domain-aware. Security data loads only for an authenticated user with an active Aegisify Audit entitlement and an accessible domain. The selected site is resolved only from the domains available to that user. If there is no authorized domain or no stored evidence for a particular security category, the interface is designed to say so.
The First View: Posture, Findings, and Confirmed Defensive Activity
The top-level snapshot is built to help an owner, administrator, security engineer, agency, or executive understand the selected WordPress environment before opening the deeper evidence sections.
Current Posture With Trend Context
The dashboard presents a stored security score when sufficient assessment evidence exists and can show movement across recent results. The score is an Aegisify posture indicator, not a guarantee that the website is secure and not a certification score.
Core, Themes, Plugins, Users, and Settings
A concise WordPress audit status summarizes whether supporting evidence exists for major WordPress areas such as core files, themes, plugins, users and roles, and configuration. Missing data remains visibly missing.
Stored Static-Analysis Evidence
The snapshot surfaces the current open static-analysis finding count when a completed SAST result is stored for the domain, giving teams an immediate view of code-level work that may need attention.
Live Application and API Evidence
Open dynamic-analysis findings are summarized from completed DAST evidence. The dashboard preserves the difference between a completed scan with zero findings and a domain for which no completed DAST evidence is available.
Known Software and Dependency Risk
Stored vulnerability evidence is summarized across WordPress core, plugins, themes, and supported dependency records so security teams can quickly see whether known component risk needs deeper review.
Confirmed Enforcement Events
This metric is intentionally narrower than “all suspicious activity.” It is built from stored WAF, Shield, and WordPress activity evidence that explicitly represents enforcement such as a block, deny, rate limit, or lockout. It counts retained events, not unique attackers.
Beyond Findings: Inventory, Drift, Logs, Agent Status, and Control Evidence
Security posture is more than a total finding count. The Master Dashboard includes operational metrics that explain whether the site is changing, whether supporting evidence is available, and whether important WordPress controls can be observed.
Component Inventory and Risk
Summarizes stored plugin and theme inventory, including component counts, update posture, activity state, and known-vulnerability context when that evidence is available.
Threat and Reputation Signals
Provides a compact status from stored domain-intelligence checks, including reputation, accessibility or blocking signals, and available breach or dark-web intelligence.
Operational Event Visibility
Summarizes stored WordPress debug, activity, and application-log evidence with severity context so teams can see whether operational signals need attention alongside scan findings.
What Changed Between Inventories
Compares stored inventory snapshots to identify added, changed, or removed components and other supported drift signals. Drift requires comparable snapshots; a first snapshot cannot create a meaningful before-and-after comparison by itself.
Connection Availability
The current metric indicates whether the selected domain has a recognized live/connected Agent state. It should be read as connection availability, not as proof that every possible scan, sensor, or telemetry source has complete coverage.
Observed Control Evaluation
When control-state evidence exists, the dashboard can show the percentage of evaluated controls that passed. This is an assessment summary of observed control states—not a claim that the organization or website is formally certified or fully compliant.
What the Master Dashboard Organizes
The current dashboard is divided into nine evidence domains. Each one answers a different security question and keeps its own source and freshness boundaries.
Scan Reporting & Drift
Shows recent scan trend, open findings, available security scores, drift over time, and drift categories. Its job is to help teams see whether the environment is improving, regressing, or simply changing between stored assessments and inventory snapshots.
Vulnerabilities
Organizes stored vulnerability evidence by severity, surfaces priority vulnerabilities, and shows trend context across recent vulnerability snapshots. Where the source data supports it, known-exploited context can help distinguish active exploitation concern from severity alone.
DAST, API and Web Apps
Summarizes completed dynamic-testing evidence, including severity, open findings, OWASP-oriented categories, and related application/API posture. Its DAST security score is derived from stored finding severity and is explicitly not a compliance or certification score.
SAST & Code Quality
Organizes static-analysis findings by severity and code area, preserves provider/engine evidence when available, and surfaces priority code findings. This allows code risk to remain visible without being mixed into a generic vulnerability total.
Activity and App Logs
Combines stored WordPress activity, WordPress debug, and application-log evidence. It can summarize severity, source, leading activity sensors, and priority events while acknowledging that different log sources may have different retention windows.
WordPress Hardening
Correlates stored scan evidence for WordPress exposure, headers, cookies, configuration, filesystem posture, logging, REST/AJAX, authentication surfaces, diagnostics, and source or secret-exposure conditions. Missing evidence sources are not estimated.
Dark Web
Provides threat-intelligence status, flagged-mention history, provider-result summaries, and stored domain-intelligence context. This is an intelligence signal, not proof that every possible breach source or private forum has been searched.
WordPress App Plugins
Uses current stored Agent component inventory to show plugin, must-use plugin, and theme posture, including active/inactive state, update availability, known-vulnerability context, component risk distribution, and components requiring attention.
Commerce
Brings together stored commerce package, vulnerability, SAST, and DAST evidence when a commerce environment is detected. It can summarize packages, updates, known vulnerabilities, code findings, risk areas, and priority commerce findings without assuming every WordPress site runs commerce.
How WordPress-Side Evidence Reaches the Dashboard
The Master Dashboard consumes Agent-derived and log-derived evidence after the appropriate Aegisify collection workflows have stored it. The dashboard itself does not turn on sensors, grant telemetry permission, or perform a new Agent scan when the page loads.
This SaaS build confirms how the Master Dashboard consumes stored Agent connection state, inventory, and activity/log evidence. Exact Agent-side sensor and telemetry configuration belongs to the Agent’s own administrative controls; it is not configured by these dashboard components. That separation matters because an administrator may intentionally authorize some evidence sources while leaving others unavailable.
Freshness, Missing Data, and Scope Are Part of the Result
A security command center is only credible when it tells you what it knows, where the evidence came from, and what it cannot currently observe.
For multi-domain customers, the current implementation can also expose domain-level report cards when the subscription includes that entitlement. Those cards let an authorized user compare domain posture and then move into the selected site’s detailed evidence. The report-card capability is entitlement-controlled rather than assumed for every plan.
AI-Assisted Analysis Starts With Stored Aegisify Evidence
The goal is not to ask a general chatbot whether a WordPress site is secure. The Risk Insight workflow packages selected-domain evidence into a controlled, redacted analysis context and asks for decision-oriented interpretation.
The Master Dashboard maintains a stored Risk Insight summary and supports refreshing that view through an AI-assisted background analysis. The current workflow is designed to organize the result around practical questions: What changed? What matters? Why does it matter? What should be done first? What remains unknown? Priority recommendations can include supporting evidence, potential impact, an action to consider, and a verification step.
The analysis is intentionally evidence-aware. The implementation instructs the AI workflow not to treat CVSS as a complete environmental risk score, not to treat exploitation probability as the whole risk decision, and to give stronger weight to supported known-exploitation evidence when relevant. It also requires missing or stale evidence to remain visible as uncertainty rather than being filled with confident guesses.
Minimum-Necessary Environment Package
The AI package is built from normalized dashboard evidence rather than raw customer data. The environment package is designed to exclude customer identifiers, component names and versions where not necessary, private paths or routes, and raw log text from the meeting-ready reporting context.
Focus on Material Risk
The AI payload can emphasize critical and high-priority security findings rather than sending every low-value record into the decision layer. This supports concise triage while preserving the underlying Aegisify evidence for human review.
Analyze Individual Evidence Domains
Each of the nine dashboard evidence domains can be analyzed in its own context, allowing a team to ask for focused interpretation of vulnerabilities, DAST, SAST, logs, hardening, threat intelligence, components, commerce, or scan/drift evidence.
Risk Insight PDF
An authorized user can generate a meeting-ready report that brings together executive metrics, scan trends, vulnerability severity, DAST, OWASP mappings, static-analysis evidence, and a discussion guide using the controlled dashboard evidence package.
Ask Questions Across Authorized Aegisify Evidence—Without Crossing the Account Boundary
Account Intelligence Chat is designed for questions such as “What needs attention first?”, “What changed since the last scans?”, or “Compare risk across my authorized domains,” while keeping the conversation tied to the current user, account, and permitted sites.
The chat rebuilds its authorization state for every request. It does not trust a browser-supplied account number or arbitrary list of sites. The domain scope is intersected with what the current user can access inside the active Aegisify account. Public-test verification domains are excluded from this account intelligence scope.
By default, a new conversation follows the current authorized domain context. An authorized user can explicitly choose an account-wide scope covering all currently authorized account domains. Once a conversation is saved, its original scope is locked: changing from example.com to another domain, or from one domain to account-wide analysis, requires a new conversation. That prevents earlier messages from being silently reinterpreted against different data.
Ask Deep Questions About example.com
A domain-scoped chat can use the fresh Master Dashboard context for that authorized site: executive metrics, findings, scan evidence, logs, vulnerabilities, hardening, freshness, compliance observations, and section summaries where available.
Compare Authorized Sites
When the user intentionally selects all authorized account domains, Aegisify builds a compact multi-domain evidence package. Detailed row-level arrays are reduced while executive metrics, open finding counts, freshness, compliance context, and section summaries are retained for comparison.
Keep Context Without Letting Scope Drift
Saved chats remain partitioned to the current user and account. The current build keeps up to 25 saved chats, with up to 20 messages retained per conversation. Account-wide saved conversations require the same authorized-domain snapshot before they can be reopened.
Security Intelligence, Not General-Purpose Chat
The prompt is limited to 2,500 characters in the current build, and the AI context uses the most recent eight messages. Questions that drift away from Aegisify security, audit, risk, compliance, remediation, or authorized account context are redirected back to the supported purpose.
Some Account Questions Do Not Need AI
When the question is about supported account metadata rather than security analysis, Aegisify can answer locally. Examples include the active plan, subscription/license status, billing interval or period information, account role, authorized domains, authorized-domain count, verified account-user count, or the current chat scope. Keeping those answers local reduces unnecessary data sharing.
Risk Questions Build a Redacted Security Package
Questions about risk, findings, scans, logs, remediation, hardening, compliance observations, DAST, SAST, vulnerabilities, or cross-domain trends cause the chat to rebuild fresh Master Dashboard evidence for the authorized scope. Domain labels are replaced with opaque aliases, account identifiers are removed, raw logs are excluded, and only the controlled evidence package is sent for AI analysis.
The Chat Is Designed to Fail Closed When Scope Is Wrong
The value of account intelligence depends on preventing a convenient AI interface from becoming a path around normal tenant and domain authorization.
The chat also does not use an arbitrary email address as a key to search customer or tenant data. Opaque site aliases are restored to readable domain labels only after the response returns to the currently authorized scope. Security-relevant chat actions can be audited without using direct customer account identifiers as the public event reference.
A Dashboard and Chat Cannot Replace Fresh Security Evidence
The strongest use of the Master Dashboard is to make better decisions about evidence—not to treat aggregation or AI as proof that the underlying environment has been tested recently.
Neither the Master Dashboard nor Account Intelligence Chat is a substitute for running the relevant security scan. If the latest vulnerability evidence is old, the answer is to refresh the vulnerability assessment. If code changed after the last SAST run, new static analysis may be required. If the application or commerce workflow changed, a new DAST assessment may be appropriate. If WordPress activity or WAF events are not being ingested, a chat summary cannot reconstruct the missing history.
The same applies to Agent status. A connected Agent is useful because it establishes a path for authorized WordPress-side evidence, but connection state alone does not mean every sensor, log source, inventory, SAST result, telemetry category, or defensive control has fresh data. The dashboard reports what is present; the security program decides what needs to be collected next.
Compliance observations require the same restraint. The dashboard can summarize whether evaluated controls passed, failed, require manual review, or were not observable. That can support governance and remediation work, but it should not be marketed as a formal certification or as proof that every requirement of a regulatory framework has been satisfied.
Use the Dashboard to Decide Where the Next Security Action Belongs
Aegisify is most useful when the command center, scanners, Agent, defensive tools, and human review operate as a loop.
Select the Authorized Domain and Check Evidence Freshness
Begin with the domain that matters to the current task. Review when the latest scans, inventory, logs, and other evidence were collected before interpreting a score or count as current.
Read the Executive Snapshot Before Opening Individual Findings
Use security score, audit status, SAST, DAST, vulnerabilities, confirmed blocked events, inventory, drift, Agent connection, logs, and control observations to identify which evidence domain deserves attention first.
Open the Evidence Domain That Owns the Problem
Investigate a code issue in SAST, a live application issue in DAST, a known component problem in Vulnerabilities, a change question in Scan Reporting & Drift, a WordPress control issue in Hardening, or an operational event in Activity and App Logs. Keep the original evidence source visible.
Use Risk Insight or Account Intelligence Chat to Clarify Priority
Ask for a concise explanation of what changed, what needs attention first, how domains compare, or what supporting evidence should be reviewed. Treat the AI answer as an interpretation layer that must remain traceable to stored Aegisify evidence.
Remediate Through the Correct Operational Control
Apply updates, code fixes, hardening changes, WAF or Shield changes, operational corrections, or risk-acceptance decisions through normal administrator and security-team change control. Do not make production changes solely because an AI summary recommended them.
Generate New Evidence and Compare
Rerun the relevant assessment, refresh the required inventory or log evidence, and return to the dashboard. The objective is not to close an alert by declaration; it is to show that the new evidence supports the intended improvement.
Common Questions About the Dashboard and Account Intelligence Chat
Does opening the Master Dashboard run a new security scan?
No. The Master Dashboard is an aggregation and intelligence layer. It reads stored evidence for the current authorized domain, including available scan results, inventories, logs, threat intelligence, hardening, commerce, and Agent-derived context. To create fresh security evidence, use the appropriate Aegisify assessment or ingestion workflow.
Does Account Intelligence Chat run scans when I ask about a risk?
No. Analytical questions cause the chat to rebuild fresh dashboard context from stored Aegisify evidence within the authorized scope. The chat can explain and compare that evidence, but it does not silently create a new vulnerability, SAST, DAST, inventory, or log-ingestion job.
What happens when a dashboard source has no data?
Aegisify is designed to preserve the distinction between missing evidence and a completed assessment with no findings. A missing source can be shown as unavailable, partial, or unknown. This prevents an absent scan or telemetry source from being interpreted as a passing security result.
What does Agent Coverage mean?
In this dashboard implementation, Agent Coverage reflects whether the selected domain has a recognized connected Agent state. It is not a statement that every Agent-assisted scan, sensor, telemetry category, log source, or security control has complete coverage.
Are activity sensors and telemetry automatically enabled by the Master Dashboard?
No. The dashboard consumes stored activity or Agent-derived evidence when those sources have been collected and authorized by the appropriate workflow. It does not enable Agent sensors or change telemetry permissions itself.
Can Account Intelligence Chat look up another customer if I provide an account number, email, or domain?
No. The chat is designed around the current signed-in user’s authorized Aegisify account and domains. Cross-account, cross-tenant, and unauthorized-domain requests are blocked, and an arbitrary email address is not used as a customer-data search key.
Can I compare more than one authorized domain in chat?
Yes, when the user explicitly selects the all-authorized-domains scope. Aegisify then builds a compact account-wide evidence package suitable for comparison. A saved conversation keeps its original scope and cannot silently switch to a different site or authorization set.
Does every Account Intelligence Chat question go to an AI provider?
No. Supported account metadata questions can be answered locally, including plan, subscription status, billing-period information, account role, authorized-domain information, verified user count, and current chat scope. Security-analysis questions use a redacted, minimum-necessary evidence package.
Does the Compliance Status metric mean my organization is compliant?
No. It is a summary of the control states Aegisify was able to evaluate from stored evidence. It can support compliance operations, but it is not a regulatory certification, legal opinion, or guarantee that every applicable control has been satisfied.
Should I make production changes directly from an AI recommendation?
No. Risk Insight and Account Intelligence Chat are advisory. Review the underlying Aegisify finding, confirm the affected system and business context, use normal backup and change-control practices, then generate fresh evidence to verify the result.