Audit Log

The Audit Log page (Dashboard > Audit Log) records administrative actions and changes across the platform: who did what, to which resource, from which IP address, and when. It is the authoritative record for compliance investigations, change reviews, and answering "who changed this?" — every privileged action taken through the console lands here, scoped to your tenant.

Audit entries are written server-side as actions happen and cannot be edited or deleted through the console. Each entry is linked into a tamper-evident cryptographic chain (an HMAC hash chain with per-tenant sequence numbers) when the deployment's encryption key is configured, so gaps or modifications in the history are detectable. Chain integrity can be verified through the REST API — see the interactive reference under Settings > API Documentation.

Screenshot

[SCREENSHOT PLACEHOLDER: The Audit Log page showing the filter bar (Action, Resource Type, Start Date, End Date, Export CSV) above the table with Timestamp, Actor, Action, Resource, Resource ID, and Details columns]

How it works

Whenever an administrator performs a privileged action — triaging an alert, changing a setting, deleting a policy, requesting a device wipe — the server writes an audit entry as part of handling the request. The entry captures:

• the actor: the authenticated admin account (email and account ID) that made the request;
• the action and the resource it targeted, including the resource identifier;
• a human-readable details description of what changed;
• request context: the originating IP address and browser user agent;
• a server-assigned timestamp.

Because entries are attributed by the server from the authenticated session — not supplied by the client — an actor cannot claim to be someone else, and actions taken through the REST API are attributed the same way as actions taken in the console.

Each tenant's log is independent: admins see only their own tenant's history, and entries are sequence-numbered per tenant for the integrity chain described above.

What gets recorded

Recorded actions span every administrative surface of the console, including:

Area	Examples of recorded actions
Alert triage	acknowledge, resolve, claim, assign, unassign, reopen, update severity, learn site, silence stale alerts
Employees (monitored users)	create, update, delete, bulk import, bulk delete
Policies and domain scopes	create, update, delete
Devices	revoke, delete, wipe requested
Groups	create, update, delete, add/remove members, assign/remove policy
Admin accounts	create, update, reset password
Settings and platform	tenant settings changes, license update, setup completion
Detection content	phishing signature and signature pack changes, ClickFix signature changes, phishing whitelist changes, extension whitelist changes
Integrations	log destination create and update

Filterable resource types cover the same breadth — alerts, policies, users, devices, groups, admin users, directory sources, log destinations, tenant settings, threat intel settings and API keys, notification settings, secrets (recorded as changed, never with their values), whitelists, signatures, licenses, and more.

Actions performed by the system on the server's own behalf (for example, telemetry ingestion) are not admin actions and do not appear here; for endpoint security events, use the Events and Alerts pages instead.

Using the page

Columns

Each row shows:

• Timestamp — date, time, and a relative age ("2 hours ago"). Sortable; newest first by default.
• Actor — the email address of the admin who performed the action, with the originating IP address beneath it.
• Action — a color-coded badge (for example, destructive actions in red, create actions in green).
• Resource — the type of object acted on, with a shortened identifier.
• Resource ID — the full identifier of the affected object.
• Details — a human-readable description of the change.

Use the column toggle in the table toolbar to show or hide columns. The table is paginated at 50 entries per page by default, the toolbar shows the total entry count, and clicking the Timestamp, Actor, Action, or Resource column headers changes the sort order.

Action badges are color-coded by category so you can scan a page of history quickly:

Color	Action category
Green	Resolution actions (acknowledge, resolve) and create actions
Purple	Assignment actions (claim, assign)
Orange	Reversals and containment (reopen, unassign, wipe requested, silence stale alerts)
Yellow	Severity changes
Blue	Update actions and password resets
Cyan	Setup completion, bulk imports, signature pack uploads
Red	Destructive actions (delete, revoke, remove)

Filters

The filter bar narrows the table by:

• Action — a specific recorded action (for example, "policy update" or "employee bulk import").
• Resource Type — a specific object type (for example, "tenant settings" or "device").
• Start Date / End Date — an inclusive date range.

Filters combine, and a Clear Filters button appears whenever any filter is active. The results count updates to show how many entries match. There is no free-text search box — combine the Action, Resource Type, and date filters to narrow results, or export to CSV and search in your own tooling.

Exporting

Click Export CSV to download the log as a spreadsheet-ready file named audit-log-YYYY-MM-DD.csv. The export respects your active filters, streams the complete matching result set (not just the visible page), and includes columns the table view abbreviates: Timestamp, Actor Email, Actor ID, Action, Resource Type, Resource ID, IP Address, User Agent, and Details. Cell values are sanitized against spreadsheet formula injection, so the file is safe to open directly in Excel or Sheets.

Screenshot

[SCREENSHOT PLACEHOLDER: An exported audit-log CSV open in a spreadsheet showing the Timestamp, Actor Email, Action, Resource Type, IP Address, and Details columns]

Retention

Audit log entries live in the transactional database, separate from telemetry. They are not governed by the Event Retention Period configured under Settings > General Settings > Data Retention (the Retention Matrix on that page lists exactly which event stores that window covers — the audit log is not among them). Audit entries are retained for the life of the tenant with no automatic expiry, so historical investigations remain possible regardless of your telemetry retention window.

If your compliance program requires audit records to be preserved outside the platform as well, schedule periodic CSV exports or forward events to your SIEM via SIEM Integration.

Compliance workflows

Two habits make the audit log most useful during an audit:

• Periodic evidence exports. At the end of each review period, filter by the date range and click Export CSV. The export carries the full actor identity (email and account ID), IP address, and user agent for every entry — fields your auditors typically ask for but that the on-screen table abbreviates. Store the file with your other period-end evidence.
• Integrity verification. Because entries are chained with per-tenant sequence numbers, an auditor (or your own security team) can confirm the history is complete and unmodified by calling the chain-verification endpoint in the REST API. A successful check reports the total record count and the first and last sequence numbers; a failed check reports the exact sequence number where the chain breaks. The interactive API reference under Settings > API Documentation documents the endpoint.

Changes to sensitive values are recorded without the values themselves: for example, an SMTP password or webhook secret change appears as a resource-type entry showing who changed it and when, but the secret never appears in the log or the export.

Worked example: confirming a device wipe

A departing employee's laptop was scheduled for a remote wipe, and HR asks for confirmation of who initiated it and when:

1. Open Dashboard > Audit Log and set Resource Type to "device".
2. Set Action to "wipe requested".
3. Narrow Start Date / End Date to the employee's departure week.
4. The matching entry shows the initiating admin, the timestamp, the originating IP address, and the device identifier in Resource ID.
5. Export the filtered view to CSV and attach it to the HR ticket.

Device revocations and deletions follow the same pattern with the "revoke" and "delete" actions.

Worked example: investigating an unexpected whitelist entry

Suppose a phishing alert you expected never fired, and you discover the domain in question is on the phishing whitelist. To find out who added it and when:

1. Open Dashboard > Audit Log.
2. Set Resource Type to "phishing whitelist". The table now shows only whitelist changes.
3. Set Action to "phishing whitelist create" to exclude deletions.
4. If you know roughly when detection stopped, set Start Date and End Date around that window.
5. Scan the results. The matching row shows the Actor (admin email), the originating IP address, the exact Timestamp, and the Details describing the domain that was whitelisted.
6. Cross-check the actor: was this a sanctioned change? The Actor's IP address helps confirm whether the action came from an expected network. If the account itself is in question, review it under Admin Users & Roles.
7. Click Export CSV with the filters still applied and attach the file to your investigation ticket as evidence.

If the change was unauthorized, remove the whitelist entry under Settings > Phishing Domain Whitelist — that removal is itself audited, closing the loop with a documented remediation.

Video

[VIDEO PLACEHOLDER: Filtering the Audit Log by resource type and date range, opening a matching entry's details, and exporting the filtered result set to CSV]

FAQ

Who can view the audit log? Access is role-based. Analyst-level roles and above can view it; see Admin Users & Roles for what each role can see and do.

Can audit entries be edited or purged? Not through the console. Entries are written by the server, chained cryptographically for tamper evidence, and have no expiry.

Why does an entry have no Resource ID or Details? Some actions apply tenant-wide (for example, setup completion) rather than to a single object; those fields are shown as "-".

Can I search for a keyword? Not directly — use the Action, Resource Type, and date filters to narrow the table, or export a filtered CSV and search it locally.

Do failed login attempts appear here? The audit log records administrative actions taken through the console. For authentication and endpoint security events, use the Events page and Alerts.