Audit log

The audit log records, one entry per action, who signed in, who changed what, what ran, what data left the installation and who changed the permissions. It is for whoever must answer "who did this, and when": administrators, auditors, the security team. The log is append-only, outlives the accounts that wrote it, and can be forwarded to a SIEM.

At a glance

How it works

Every action that matters writes one row. Writing it never fails the action: if the audit cannot be written, the error goes to the gateway's log and the person's action goes on.

Secrets never go in. A token appears by its name, never its value; a SIEM token, a connection password or a scripting variable's value is never written; a setting change records what changed. When an API token does something, its name is added to the detail ("token": "nightly-export"), so the actions of a leaked token can be found and undone.

The client address is the address of the connection as the gateway's server sees it. Behind a reverse proxy, the X-Forwarded-For header is believed only from the addresses in FORWARDED_ALLOW_IPS (on Kubernetes, the chart's gateway.trustedProxies): anyone else cannot choose the address they appear to come from.

The Audit page

Administration → Audit has three parts:

• Active sessions: one row per open session (a browser, a script), with the account, the sign-in method, the last activity and the address. An administrator closes one with Sign out this session: the next click of whoever uses it lands on the sign-in page (auth.session_revoke).
• Access · last 24 hours: successful and failed sign-ins per hour, in the installation's time zone.
• Audit log: newest first, 50 per page. Search actor, target, IP… searches the email, the target's name, the action and the address; All actions narrows to one action; Any outcome to successes or failures.

The Audit log part of the page: each row says when, who, what, on which object, with what detail, from which address, and whether it succeeded.

What is recorded

A schedule switched off because someone else widened what it does is recorded too, as a flow.schedule (or the object's own schedule action) with the reason, so "why did my nightly run stop" has an answer in the log.

Accounts and groups. An entry names the account or the group, and what changed from what to what ({"full_name": {"from": "Anna", "to": "Anna Bianchi"}}); a password never appears. A membership's target is the person, with the group in the detail ({"group": "finance", "group_id": 4}, plus "admin": true or "observer": true when the group carries that role). Joining or leaving an administrators' group writes group.member_add (or group.member_remove) and then group.admin_join (or group.admin_leave): the first action holds a group's whole membership history, the second every change of privileges. Deleting a group writes one group.delete with the number of its members, not a removal per person, and a role the group carried is withdrawn as group.demote or group.observer_revoke. A change that changes nothing (a form saved again, an account deactivated twice) writes nothing. The first administrator of a try-it stack, created at the sign-in page, is auth.first_run_setup.

What single sign-on does by itself goes with the same actions and "via": "sso" in the detail: the account created at its first sign-in (user.create), the email or name the identity provider changed (user.update), a group created by OIDC__AUTO_CREATE_GROUPS (group.create), each membership the synchronization adds or removes (group.member_add, group.member_remove), and the administrator rights of OIDC__SUPERUSER_GROUP (user.promote, user.demote). Their actor is the person signing in, the change happening in their sign-in; a sign-in that changes nothing writes only its auth.sso_login.

Example

An administrator gives the finance group VIEW on the Sales folder. The entry, as GET /audit?action=permission.grant returns it:

{
  "id": 48213,
  "ts": "2026-10-27T08:14:03.512000+00:00",
  "actor_id": 1,
  "actor_label": "marta.bianchi@example.com",
  "action": "permission.grant",
  "outcome": "success",
  "target_type": "permission",
  "target_id": 57,
  "target_label": "view",
  "detail": {"project_id": 7, "user_id": null, "group_id": 4, "capability": "view"},
  "ip": "10.20.4.17",
  "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) …"
}

An observer reading the same entry sees "actor_label": "m***@example.com", "ip": null and "user_agent": null.

Reading the log from a script, with the token of an administrator or a service account that may read it:

curl -s -H "Authorization: Bearer tab_…" \
  "https://tabularia.example.com/api/audit?action=export.download&since=2026-10-01T00:00:00&limit=200" \
  | jq '.items[] | {ts, actor_label, target_label, detail}'

The answer is a page, {"items": […], "total": n}; the filters are q, action, target_type, outcome, actor_id, since and until (UTC), limit (up to 200) and offset. GET /audit/actions lists the actions present in the log.

Permissions

An observer's own actions are recorded without their address and browser: what they did stays, where they came from does not. A failed sign-in keeps its address whoever it claims to be, because that is what the defences against password guessing rest on.

Retention

Deleting entries is never a person's choice: no route deletes them, and deleting an account does not delete what it did. Turning on a retention window is the installer's decision; with SIEM forwarding on, entries older than the window are deleted even if Splunk has not received them yet (delivery).

Privacy notice

Administration → Privacy sets the notice shown in a bar at the top of every page: Line in the bar, Full text (Markdown), an optional Link to your organisation's policy, and show the notice to everyone. The starting text describes what the installation really records, for full accounts and for read-only guests, and where data goes (the assistant sends questions and the rows it reads to the configured model provider). Rewrite it if your processing differs. The placeholder {audit_retention} becomes the configured audit retention, so the notice cannot drift from the configuration. Every change is recorded (privacy.update).

Limits and good to know

• Not recorded: reading. Opening a flow, a preview, the Viewer, a datasource's page are not in the log; exports, SQL script runs and the assistant's queries are.
• Older entries. Up to 1.2.2 an account showed only when it was created administrator or observer, a deactivation only as the closing of its sessions (auth.session_revoke with the reason deactivated), and the memberships of ordinary groups, a deleted group and what single sign-on changed not at all (except inside the detail of each auth.sso_login, which still carries it).
• No export button. Use the API above, or forward the log to a SIEM.
• Large logs. Entries are indexed by time, action, actor and target kind; on a busy installation set a retention window and keep the long history in the SIEM.

Related

• Audit log to Splunk: forwarding, delivery guarantees, searches.
• Permissions: administrators, observers, what each action needs.
• Security and governance: the map.
• Configuration: webhooks and audit log.