Aegisify company logo
Aegisify Audit Control Center2026-08-10T02:22:13+00:00
Aegisify Audit — Security Intelligence

Aegisify Control Center and Account Intelligence Chat: Turn WordPress Security Evidence Into Clear Action

The Aegisify Control Center 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.

Collect once. Correlate across the stack. Ask what matters next.
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.
1CollectScans + logs + Agent evidence
2CorrelateDomain-scoped risk context
3DecideInsight + chat + verification
Interactive Intelligence Flow

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
Aegisify begins with the signed-in user’s current account and only the domains that user is authorized to access. A site such as example.com is evaluated inside that account boundary rather than as a free-form domain lookup.
02CollectStored security evidence
Separate Aegisify workflows produce scan results, vulnerability evidence, inventories, logs, threat intelligence, hardening observations, commerce evidence, and Agent-derived context. The dashboard reads those stored results; simply viewing it does not launch a new scan.
03NormalizeOne selected-domain view
Evidence from different security disciplines is normalized into a consistent domain-scoped model with severity, freshness, trend, open findings, source availability, and supporting context.
04CorrelateNine evidence domains
The Control Center organizes scan reporting, vulnerabilities, DAST/API evidence, SAST/code quality, activity and app logs, hardening, threat intelligence, WordPress components, and commerce evidence without pretending every source measures the same thing.
05InterpretRisk Insight
Stored evidence can be summarized into a Risk Insight view. AI-assisted analysis is designed to explain what changed, what matters, why it matters, what to do first, and what remains unknown, with an explicit requirement for human review.
06AskAccount Intelligence Chat
Authorized users can ask about one permitted domain or, when explicitly selected, all authorized domains in the account. The chat uses minimum-necessary, redacted security evidence for analytical questions and can answer selected account questions locally without sending them to an AI provider.
07ActPrioritize + verify
Use the resulting evidence to prioritize investigation, remediation, ownership, and follow-up. The correct next step is often to return to the relevant scan or operational workflow, make a controlled change, and verify the result with fresh evidence.
What the Control Center Is

A Security Intelligence Layer Above the Individual Scanners

The Control Center 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 Control Center 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.

Operating principle: the dashboard is valuable because it preserves evidence boundaries. “No finding stored,” “source unavailable,” and “zero findings in a completed assessment” are different states. Aegisify keeps those distinctions instead of converting missing evidence into a false green status.
Executive Snapshot

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.

01 — Security Score

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.

02 — WordPress Audit

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.

03 — SAST Findings

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.

04 — DAST Findings

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.

05 — Vulnerabilities

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.

06 — Attacks Blocked

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.

Why “Attacks Blocked” is conservative: an error, failed login, rule match, or suspicious event is not automatically counted as a blocked attack. Aegisify requires an explicit enforcement outcome in the retained evidence. If a source keeps less history than the displayed reporting window, earlier activity may be incomplete.
Operational Metrics

Beyond Findings: Inventory, Drift, Logs, Agent Status, and Control Evidence

Security posture is more than a total finding count. The Control Center includes operational metrics that explain whether the site is changing, whether supporting evidence is available, and whether important WordPress controls can be observed.

Plugins & Themes

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.

Dark Web & Domain BL

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.

WP Logging

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.

Drift Events

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.

Agent Coverage

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.

Compliance Status

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.

Nine Evidence Domains

What the Control Center 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.

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

07

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.

08

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.

09

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.

Agent, Sensors, and Telemetry

How WordPress-Side Evidence Reaches the Dashboard

The Control Center 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.

1Aegisify Scan WorkflowsStatic, dynamic, vulnerability, inventory, hardening, commerce, and other supported assessment workflows create the security evidence that later appears in the dashboard.
2Connected Agent ContextThe SaaS dashboard can report whether the selected domain has a recognized connected Agent state and can consume Agent-derived inventory or assessment evidence that has already been stored.
3Activity and Log IngestionWhen WordPress activity, debug, WAF, Shield, or application-log evidence has been authorized and ingested by the relevant workflow, the dashboard can correlate those retained events with other domain evidence.
4Control Center Read LayerThe dashboard reads the latest relevant stored evidence, normalizes it, and exposes freshness or missing-data conditions. It does not silently expand telemetry permissions or treat a connected Agent as proof that every source is populated.

This SaaS build confirms how the Control Center 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.

Sensor evidence is contextual, not magical: when WordPress activity data has been ingested, the dashboard can surface leading activity sensors and priority events. If the relevant source is absent or stale, Aegisify should show that limitation instead of inferring activity that was never collected.
Evidence Quality

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.

Domain ScopedDashboard evidence is rebuilt for the selected domain from the current user’s authorized account scope.
Source AwareDAST, SAST, vulnerabilities, logs, hardening, threat intelligence, plugins, and commerce retain distinct evidence sources.
Unknown Stays UnknownMissing or stale evidence is represented as unavailable, partial, or unknown instead of being converted into an invented passing result.
Trend Needs HistoryDrift and trend views require comparable stored evidence. A single scan or inventory cannot prove improvement over time.

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.

Risk Insight

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 Control Center 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.

Redacted Analysis

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.

Priority Findings

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.

Section Analysis

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.

Meeting-Ready Output

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.

Human review remains required: AI-assisted insights can be wrong or incomplete. Aegisify explicitly instructs users to review the supporting findings before making production changes. The AI layer explains evidence; it does not replace scan verification, change control, or security judgment.
Account Intelligence Chat

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.

Single-Domain Scope

Ask Deep Questions About example.com

A domain-scoped chat can use the fresh Control Center context for that authorized site: executive metrics, findings, scan evidence, logs, vulnerabilities, hardening, freshness, compliance observations, and section summaries where available.

Account-Wide Scope

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.

Saved Conversations

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.

Bounded Conversation

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.

Local Answer Path

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.

AI Evidence Path

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 Control Center 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.

Account and AI Safety Boundaries

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.

1Current Authorization RebuiltEvery request resolves the signed-in user, current account, and current authorized-domain set again rather than trusting old browser state.
2Identifiers RedactedAccount references and domain names are removed or replaced before analytical evidence is sent to the configured AI provider.
3Unauthorized Requests BlockedCross-account, cross-tenant, or private-data requests for domains outside the authorized scope are rejected instead of being used as search instructions.
4Authorization Rechecked After AIIf the account or domain authorization changes while an AI request is running, the response is discarded rather than returned or saved under stale permissions.

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.

Why saved-chat scope matters: if an account-wide conversation originally covered three sites and access later changes, the old conversation is not silently expanded to new sites or exposed after a site is removed. The current authorized-domain snapshot must still match before that account-wide history is available.
What These Features Do Not Do

A Dashboard and Chat Cannot Replace Fresh Security Evidence

The strongest use of the Control Center 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 Control Center 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.

Recommended Operating Workflow

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.

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

Control Center FAQ

Common Questions About the Dashboard and Account Intelligence Chat

Does opening the Control Center run a new security scan?

No. The Control Center 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 Control Center?

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.

See What Matters

Turn WordPress Security Data Into an Evidence-Driven Operating View

Bring scans, vulnerabilities, code findings, dynamic testing, logs, hardening, threat intelligence, WordPress inventory, commerce evidence, and AI-assisted interpretation into a security workflow built around authorized evidence and measurable follow-up.