Audit log
The audit log is your workspace’s append-only answer to “who did what, and when?” Every security-relevant or destructive action a person (or automation) takes — inviting a member, rotating an LLM credential, deleting an agent, revoking an API key — is recorded as an event that only admins can read.
At a glance
| Where | Audit Log in the left nav (admin group) |
| Key API route | GET /audit |
| Who can read | Company admins only — members and viewers get 403 |
| Scope | Company-wide: covers events across all your orgs and agents |
| Retention shape | Append-only; events are never edited or deleted by the application |
What gets recorded
Events are named <target>.<verb> and grouped by the surface they touch:
| Area | Actions |
|---|---|
| Members | member.invite, member.update, member.remove, member.resend_invite, member.bulk_persona |
| Sign-in security | auth.invite_accepted, auth.password_change, auth.password_reset_requested, auth.password_reset |
| API keys | api_key.create, api_key.revoke |
| LLM connections | llm_connection.create, llm_connection.update, llm_connection.delete |
| Judges & evals | judge.create, judge.delete, judge_version.create, judge_deployment.create, judge_deployment.update, eval_run.start, eval_run.cancel |
| Datasets | dataset.create, dataset.update, dataset.delete, dataset.version_create |
| Enrichments | enrichment.create, enrichment.update, enrichment.delete, enrichment_run.start |
| Topics | topic_space.create, topic.update, topic.merge, topic.split |
| Orgs & agents | org.create, org.update, project.create, project.update, project.delete |
| Views (personas) | persona.create, persona.update, persona.delete |
| Onboarding | tenant.onboarding_step_ack, tenant.onboarding_complete |
A failed password-reset request for an unknown email is deliberately not recorded — logging it would let an audit reader enumerate which addresses exist. Only resets issued for real, active accounts appear.
Sign-ins live on their own tab. Logins, failed logins, throttles, logouts, rejected sessions, and operator impersonation are recorded as security events and shown under Sign-in activity on this same page, not in the workspace activity list below. The split is: this log answers who did what inside your company; security events answer who authenticated, and who tried. Authentication rejections happen before a company is even resolved, so they cannot be filed under one.
What each entry contains
| Field | Meaning |
|---|---|
| When | createdAt — UTC timestamp of the event |
| Who | actorId, actorName, and actorType (user, operator, service, scheduler, automated, system) |
| What | action (the dotted verb) and a human-readable summary |
| Target | targetType, targetId, targetName — the resource that was affected |
| Where | orgId / projectId when the event is scoped below the company |
| Outcome | status: success, failure, or denied |
| Context | metadata (structured extra detail, e.g. before/after values), plus the caller’s ipAddress and userAgent |
Filtering and search
The Audit Log page (and GET /audit) supports:
- Time range — the standard picker; defaults to the last 30 days.
- Facet filters — action, actor type, and target type dropdowns, populated from the
values actually present in your log (plus
actorId,orgId,projectId, andstatusas API parameters). - Free-text search —
qmatches against the summary, target name, and action. - Sorting and paging — sortable by time, action, actor, target, or status; pages of up to 500 events (100 by default).
Picking a filter never collapses the other dropdowns — facets are computed over the full time-scoped log, so you can pivot between filters freely.
Audit log vs. Activity feed
These answer different questions:
| Audit log (this page) | Activity feed | |
|---|---|---|
| Question | Who changed what? | What background work ran? |
| Contents | Security-relevant mutations: members, keys, connections, judges, datasets, orgs/agents, auth | Eval, clustering, and enrichment runs — durations, target counts, success rates |
| Audience | Admins only | Members |
| Shape | Append-only event trail | Operational run history |
(Platform operators additionally have their own separate log covering company provisioning and lifecycle — that never appears in a tenant’s audit log.)
How it works
- Events are written after the primary action commits, on a separate connection, and the write is best-effort — an audit hiccup can never roll back or block the action itself.
- The log lives inside your company’s physically isolated storage, and reads are additionally scoped to your company, so no other tenant’s events can ever appear.
- Reading is gated by an admin-only permission; there is no API to modify or delete entries.
Related
- Activity — the background-run feed for evals, clustering, and enrichments.
- Members & roles — the admin role that grants audit access.
- API keys and LLM connections — the credential events recorded here.