Fleet rule and scan operations

Last verified: 2026-08-02

Awthy Hub can show signed-rule health and bounded scan results for the WordPress sites connected to your account. It does not turn Hub into a remote file-remediation console.

Data sent to Hub

Each connected site sends bounded operational metadata: plugin and scan-engine versions, the active rule bundle version and SHA-256 identity, bundle health, last-contact time, the latest scan status and completeness, counts grouped by severity and rule identifier, reinfection state, and a coarse remediation outcome. Hub does not receive WordPress customer records, credentials, authorization headers, cookies, raw file bodies, file paths, matched snippets, or scan error bodies in this fleet-status report.

Awthy retains fleet-status history for up to 90 days. The latest status for a disconnected, deleted, or deactivated install is hidden immediately and becomes eligible for bounded deletion after 30 days. Account deletion and install disconnection controls therefore remove access first; scheduled cleanup completes physical deletion within those windows.

Disconnected sites

A disconnected or unreachable site keeps its last verified rule bundle and continues to support local scanning. Hub cannot start a new campaign claim while the site cannot contact Hub. The fleet view labels the missing contact; it does not reinterpret an old clean result as current.

Scan-only campaigns

An account manager previews the eligible cohort before creating a campaign. The preview shows a count and expires after 15 minutes; previewing does not schedule work. A confirmed campaign contains only a signed rule-bundle identity, expiry, and a bounded existing scan profile and budget.

Campaigns can request the existing local scanner. They cannot carry a method, path, code, SQL, shell command, URL, arbitrary arguments, repair instruction, quarantine instruction, deletion instruction, or file-upload instruction. Canary and account rate limits bound the rollout. Each eligible install claims a campaign at most once.

Pausing or cancelling prevents new claims. A local scan already running may finish.
Expiry prevents new claims after the deadline.
Results remain explicit: complete, partial, failed, cancelled, or unreachable.
Partial, failed, stale, and unreachable results are never presented as clean.

Release review and rollback

Signed rule releases require the accountable Awthy operator to complete the review checklist before publication. Canary publication precedes stable publication, and the same configured Hub admin who created the release can review, canary, promote, and revoke it. Revoking a release stops it from being selected for new adoption; connected sites keep their last known-good verified rules when a replacement cannot be accepted.

Rollback never bypasses monotonic version checks or restores an old signature as if it were new. An operator republishes the approved earlier rule content as a newly signed, higher-sequence release, checks it, and promotes it through the normal canary and stable path. This preserves the audit trail and downgrade protection.

Privacy and support

Fleet status is account-scoped. Account members can read only their own connected-site and campaign status. Awthy Hub operators use the Hub admin session for release operations and cannot use these screens to mutate customer files. If a status appears stale, first confirm the WordPress site can reach Hub over TLS, then use the manager-only Refresh rule status control in Awthy Reporting. That action checks signed release metadata only; it does not start a scan.