Audit trail

An audit trail is a baseline requirement for any platform that touches production infrastructure. WatchTower15 records security-relevant events to an immutable, write-once log that org administrators can review and filter.

What’s recorded today

The audit trail currently captures authentication events — the highest-value events for detecting account compromise and satisfying access reviews:

Event	Details captured
Login success	The method (password or sso), and for SSO the provider (google / microsoft).
Login failed	A structured reason — e.g. wrong credentials, account locked, password disabled for an SSO-only org, email not verified, or an SSO domain restriction.
Logout	The signed-out session.

Every record captures the actor (user, or none for anonymous/system events), the IP address, the user agent, the request URL, a category, and a JSON metadata bag for event-specific context (such as the SSO provider or the failure reason).

Immutability

Audit records are write-once. There is no update path — records carry a creation timestamp and nothing else that can change — so the trail is tamper-evident by construction. Records are retained and not automatically pruned, so historical access reviews stay complete.

Categories

Every event is filed under a category (a module-level label such as authentication, servers, domains or users). Categories let the audit view drill from “everything” down to a focused slice, and give future event types a consistent home.

Viewing the trail

Two surfaces expose audit data:

• Organisation audit view — a paginated, filterable log of events for the organisation’s members. Filter by category, user, action, and date range. This view is gated by the audit.view permission, so you can grant auditors read access to activity without granting them any operational rights.
• Recent logins — each user can see their own last few successful logins (time, IP, method), a simple self-service way to spot an unexpected session.

Access is permission-gated, not admin-only

Because the audit view uses its own audit.view permission, you can create a read-only “Auditor” role that sees the trail and nothing else — useful for compliance functions that shouldn’t hold operational permissions.

Roadmap

Expanding coverage

The audit framework is built to record far more than authentication. Additional event coverage — resource create/update/delete, role and membership changes, and other administrative actions — is on the roadmap and will file into the same immutable trail and category model documented here. This page will grow as those events are wired in.

Related

• Roles & permissions — the audit.view permission.
• Single sign-on — the login events the trail records.