Skip to main content

Audit Log

Audit Log​

Awthy's audit log is the display-safe event trail for account security, recovery, policy, support, commerce evidence, export, privacy, and system activity. It is designed to answer who did what, when, to which target, from which source, with what outcome.

Hub company activity​

Company members can review the retained Hub changes that affect their own company on the account's Activity view. This includes changes made by Awthy staff, so a customer can see what Awthy did to their account even when the operator is not a member of that company.

The view is scoped to the authenticated company. Another company's events are never included, and a filter supplied in the request cannot widen that scope. Only display-safe fields are shown: actor, target, action, status, time, risk, and a bounded set of before/after values. Stored messages, raw metadata, internal identifiers, and keyed hashes stay behind the read boundary.

Company Activity covers two separate histories, and you choose which one to view:

  • Awthy Hub activity — the retained Hub changes that affect your company, as described above.
  • WordPress activity — the audit events a connected site has exported, as the provider holds them.

The two are shown one at a time rather than merged into a single timeline. They differ in retention, in delivery guarantees and in who the actor is, and a merged view would imply they share those properties when they do not. You can always tell which source you are looking at.

Connected-site history and its limits​

A connected site's retained history is only as complete as what that site has successfully exported. Rather than show an empty list, Awthy states which of these applies:

  • Complete — the provider answered the whole request and the data is inside the freshness window.
  • Nothing exported yet — the read succeeded and the window is inside retention, so the site is simply idle.
  • Aged out — this history existed but has passed the provider's retention window and can no longer be shown.
  • Behind — events exist, but the provider reports its data as stale, so recent changes may be missing.
  • Not readable — Awthy has no usable event-read credential for this site, so nothing can be shown. This is not an empty history.
  • Incomplete read — the provider did not answer the whole request, so what you see is a partial view.

Awthy never presents an unreadable history as "nothing happened". You can also remove access at any time by disconnecting the site.

Actor attribution​

Awthy records the actor explicitly — an Awthy operator, a company member, a connected WordPress site, an automated Hub job, or an external provider — instead of inferring it from the event name. Events recorded before this attribution was introduced can show an unknown actor. Awthy reports that as unknown rather than guessing, and says so on the view.

What the audit log does not capture​

Awthy records the supported changes it can observe through WordPress, WooCommerce, and Hub hooks. It does not record a change that bypasses those hooks: direct database or filesystem edits, hosting-console changes, and writes made by third-party code outside the supported hooks are outside the trail. Awthy does not claim to audit every change to a site.

Reads are bounded by the retention window that applies to the site or account. Activity outside that window, and events recorded before a capability existed, are not recoverable.

Filters and reports​

Use filters to narrow by time window, event type, severity, outcome, actor, source, reason category, user, target, and safe search terms. Download reports when you need a bounded support or compliance artifact.

Audit reports should contain sanitized context only. They must not include passwords, authenticator secrets, backup codes, recovery tokens, OAuth tokens, raw cookies, payment details, raw order data, or full request payloads.

Local audit capture is part of Awthy's security model, but broad audit-log viewing, extended retention, and export destinations can depend on plan entitlement. If a panel shows an upgrade state, Awthy should not expose rows, destination credentials, or export controls for that locked capability.

Check the active panel's entitlement and retention before relying on it for a particular history window.

Reference lookup and reveal​

Some sensitive values are stored as keyed references. The default audit view shows safe labels, hashes, previews, or reference IDs. Revealing a sensitive reference is a deliberate action and should itself be audited.

Reveal only what is necessary for the support or compliance task. Do not paste revealed values into public tickets or screenshots.

Source-IP investigation​

Source-IP investigation can summarize event types, related users, actors, and user-agent previews for a source. Treat IP data as operational evidence, not proof of one person. Proxies, VPNs, carrier NAT, and shared offices can all collapse multiple users into one visible address.

Privacy and redaction​

Awthy supports WordPress privacy export/erase flows for audit-related personal data, subject to security-log retention needs. Redaction should preserve compliance evidence while removing or anonymizing personal data where required.

Last updated on