Access and Security Logs

The Access & Security tab is the IT-governance view of Audit Trails: the firm’s security event log, with identity, network context and severity on every row. It is the answer to “who did what, from where, and when” — and it is visible only to Firm Admin and Superadmin.

What is recorded

One access_logs table, appended by the flows that mutate identity and access. Thirty event types are defined; the label and the severity badge are resolved from that registry when the list is read, so an unmapped event type would fall back to its raw code and info severity rather than disappearing.

Event	Severity	When it is written
Login / Logout	success / info	A completed sign-in (password, or password plus MFA) and a sign-out
Failed Login	danger	A rejected sign-in attempt; when the account cannot be resolved the row carries no actor id
Account Activated	success	An invitation is claimed and the account activated
Invitation Sent / Revoked	info / warning	Team invitations issued and withdrawn
Role Changed	warning	A member’s role changed
Reporting Line Changed	info	A member’s manager changed
Access Revoked / Access Restored	danger / success	A member’s access removed, or reinstated
Profile Updated	info	A user saves their own profile
Password Changed	warning	A user changes their own password
Theme Changed	info	A user changes their own theme
Password Reset Requested / Completed	info / warning	The reset flow, at each step
MFA Enabled / Disabled	success / warning	Two-factor enrolled or removed
MFA Failed	danger	A rejected second factor — the details block names the channel
MFA Recovery Code Used	warning	A backup recovery code redeemed
MFA Recovered	warning	An MFA lockout cleared for an account, with the recovery flags in the details block
Study Deleted	danger	A study removed through the workflow service
Ledger Export	info	A ledger export is generated — the format is recorded
Tenant Provisioned / Tenant Deleted	success / danger	A firm created, or removed from the platform
Superadmin Created / Updated / Removed	warning / warning / danger	Platform-level administration of superadmin accounts
API Key Created / Revoked / Used	success / danger / info	Developer-console key lifecycle, and a key authenticating an external call

Each row carries: the actor (id, display name, email, role captured on the event), the target email where the event acts on someone else, the IP address and the user agent, a details block (channel, format, flags — event-specific JSON) and the timestamp. The IP and user-agent columns are length-capped at 45 and 500 characters and are truncated on write, so a long x-forwarded-for chain or an extension-heavy user agent lands clipped, never dropped.

The forensic value

The log’s value is the pairing it enables:

• Credential trouble. Failed logins, MFA failures and recovery-code use, with IP and user agent, are the raw material for a credential-investigation timeline.
• Who exported, and what. Every ledger export writes a Ledger Export row naming the format — the provenance chain for a certified PDF starts here.
• What happened around a study. The study-scoped access view (/studies/{id}/audit-trail/access) lists the security rows dated from that study’s creation onward. Read it as a window, not as an attribution: access rows carry no study reference, so the view shows everything the firm logged in that period, not a set of events proven to touch that study.

The RBAC context

Role	Scope
Analyst	No access to the tab
Manager / Partner	Audit Trails views, but not the access log
Firm Admin	The access and security tab, scoped to their own tenant
Superadmin	The tab, but self-scoped: only events where they are the actor id, the actor email or the target email — never a cross-tenant aggregate

The study-scoped access sub-view carries the same admin-only gate, so even inside a study the access rows are Firm-Admin/Superadmin territory. Where the firm keeps its security-side configuration is covered in Firm Settings, Security; nothing in this tab changes it.

Which events to watch first

Not every row is equally important. The ones that start an investigation:

• Failed Login (danger) — a cluster from one IP or one account is the classic credential-test signal; the IP and user agent columns are the first place to look.
• MFA Failed (danger) — repeated rejects on one account; the details block names the channel.
• Access Revoked / Role Changed (danger / warning) — a sudden de-escalation or removal, checked against who made the change in the actor column.
• API Key Revoked / Used — a key used after revocation, or created and used in quick succession, is an external-access red flag. Those rows exist only where the developer console and external API are in use.

The info and success rows (logins, exports, invitations, profile edits) are the baseline that makes those exceptions visible.

FAQ

Are the access rows exportable? They surface in the forensic search for admin views, and a Partner-and-up ledger export merges them in — but only when the exporter holds an admin role, so a Partner’s export carries the transition and override rows alone.

Why is the Superadmin self-scoped on access logs? A platform operator must be able to audit their own actions without holding a cross-tenant camera; the access log is scoped to the superadmin’s own events, not to every firm’s.

What does the free-text box search here? Actor email, target email and user agent. Details payloads and IP addresses are not matched by text — filter by event type and date range instead.

What do the details blocks contain? Event-specific JSON — the MFA channel, the export format, the flags on a recovery — rendered in the tab as-is, with no schema enforced across event types.