The third of six Dashboard Guide pages. Covers the four "read the log" pages: Activity, Security, Audit Logs, and Usage. All four respect the header's Live/Test environment toggle — scoping is consistent across this whole page, not something you need to re-check per screen.
The full auth-event feed — every login, registration, and failure, across every user in your project. Four real filters combine together: Period (last 1 hour / 24 hours / 7 days / 30 days), Method (Passkey / OTP / Magic Link), Event Type (Register / Login / Failed Login), and Result (Success / Failed). A Reset control appears the moment any filter differs from the default. Separately, a Request ID lookup box searches for one specific event by its request ID — if that event falls outside your current filters, it's shown in its own callout above the table rather than silently hidden; if it's already visible, the matching row is scrolled to and briefly highlighted instead. Clicking any row whose event has a resolved user takes you straight to that user's detail page.
Worth being precise about: this is not the same feed as Activity. Security shows only events the risk engine actually flagged — attempts it challenged or blocked — not every login. Its own header says as much: "Flagged auth events scored above the risk threshold." Filters here are Period (24h / 7d / 30d) and Action (Challenge / Block).
Two sub-pages hang off this one: Passkeys (every registered passkey across your project, with device type and transports, independent of any single user) and Settings (your risk-response policy — Monitor / Challenge / Block — with the real score thresholds each maps to).
One real navigation inconsistency worth knowing, since it's exactly the kind of thing that generates a support ticket: there's a third page at this same URL depth, security/auth-methods (where you actually turn individual auth methods on or off), but Security's own page doesn't link to it — only to Passkeys and Settings. The only way to reach Auth Methods is from the separate Authentication page, a different nav section entirely. So the URL groups Auth Methods under Security, but the navigation doesn't — if you're looking for where to disable SMS OTP or enable TOTP, it isn't on the page named Security, it's one click from Authentication instead.
Who did what, and when — admin actions like disabling a user, revoking an API key, or changing the risk policy. What's genuinely worth surfacing here: these rows are tamper-evident at the database level, not just access-controlled in the UI. A Postgres trigger unconditionally rejects any UPDATE or DELETE against this table — and critically, that block applies even to the service-role database credential every write path in this app uses, which normally bypasses row-level security entirely. There is no code path anywhere in the product, including this dashboard, that can edit or delete an existing audit log entry. It's append-only by construction, not by convention.
One thing worth knowing about what you'll actually see: the Action column only has a friendly label and colored badge for five action types — Disabled User, Enabled User, Deleted User, API Key Revoked, and Risk Policy Changed. Plenty of other real admin actions get logged here too (webhook created/deleted, project renamed/deleted, team member invited/removed, BYOAM registration changes, domain verification, origin changes, and more) — they just render as a plain grey badge showing the raw action string (e.g. webhook.created, project.deleted) instead of a human-readable name. The logging is complete; the label polish isn't.
Five real panels, and all five respect the environment toggle:
@threshold1/auth 0.3.0 or later — older SDK versions don't send the correlation header this relies on. If you have real successful logins but no funnel rows, the empty state tells you exactly that (it reports how many successful logins it already has on record, so you can tell "no data" apart from "data that can't be grouped yet").