Skip to main content

Audit Log

The Audit log (Administration → Audit log) records who changed or triggered what in the workspace, and when. It is visible to Managers and Admins — everyone who can enter the Administration area.

Compliance package. The audit log is included in the Cloud Prime, Inhouse Prime and Inhouse Enterprise licenses. With other licenses, the tile shows In the compliance package and nothing is recorded — recording starts once the license includes it. See Licensing.

What is recorded​

  • Automations — created, changed, deleted; triggers started and stopped.
  • Runs — started manually or through the trigger button, input sent, retried, reopened.
  • Knowledge — created, changed, deleted, refreshed; files uploaded and deleted.
  • Models — created, changed, deleted.
  • Workspace — settings changed.
  • Users and roles — people invited, removed and registered, roles changed (with the previous role), email addresses changed by an Admin, profile, sign-in method and password changed.
  • Connections — OAuth connections established and removed; MCP access issued.
  • Inbox — items cancelled, completed, dismissed and assigned; files uploaded.
  • Downloads — run data, inbox files, answers as Word and knowledge files downloaded.
  • Webhooks — runs started by an external caller (with its IP address, never the key).
  • License — license installed (also when it was rejected).
  • Sign-in — successful and failed sign-ins of the workspace's members, with the method (code, password or single sign-on), the second factor and, for failed sign-ins, the reason (for example no invited account, addresses do not match). With single sign-on also Company account linked (first sign-in) and Company account unlinked.
  • Access denied — every attempt to do something the person's role does not allow.
  • Audit log — viewing it, every export, and the automatic removal of old entries.

Changes to automations, knowledges, models and workspace settings name the changed fields (for example agent.model), never their values.

Each entry holds the time, the person (email address), the action, the affected object (for example the automation's ID), whether it succeeded, the IP address and the device (browser) — the last two appear when you hover over the entry — and the sign-in session, so several actions can be attributed to one session. Some actions add a few key facts — the previous and new role, the retry mode, the sign-in method.

IP address: behind a reverse proxy (as in the standard deployment), the address the proxy appends counts — a client cannot fake its address. Which proxies are trusted is set by AIKIT_TRUST_PROXY — see Local resources.

Only metadata, never content. Prompts, messages, documents, file contents and configuration values are not written to the log.

Failed attempts are recorded too — a failed sign-in, an attempt without the required role, or a change the server rejected — and are marked failed. Requests without a valid sign-in are not recorded (that would mostly be noise from scanners).

Sign-ins do not belong to a single workspace. They appear in the log of every workspace the person is a member of.

Filtering and export​

Above the list, filter by Period, Area and Person. Entries are grouped by day, newest first; more entries load as you scroll.

Export CSV downloads all entries matching the current filter as a CSV file with semicolons as separators, which opens directly in Excel. Through the API (GET /api/audit/<workspace>/export?format=json) the same export is available as JSON.

Tamper protection​

Every entry carries a checksum that includes the checksum of the previous entry — a keyed checksum (HMAC) whose key is derived from the installation's secret AIKIT_MODIFIER. Below the list, the page shows whether the log is intact. It detects:

  • an entry that was changed directly in the database — even if the chain was recomputed afterwards, because that requires the key;
  • entries removed in the middle or at the end (the newest ones);
  • entries removed at the start without the record the automatic cleanup leaves.

The page names the entry concerned. Whoever has the key and direct access to the database file — in practice the operator of the server — could still forge the log. For that case, forward the log to a central log management system (next section): a copy there is out of reach.

Forwarding to central log management​

Every entry is additionally written as one JSON line to the application's standard output (and the daily application log), with its number and checksum — for example:

{"type":"audit","id":1042,"ts":"2026-10-08T09:12:44.120Z","workspaceId":"sales","userEmail":"anna@example.com","action":"workflow.update","targetId":"offer-agent","outcome":"success","details":{"changed":["agent.model"]},"prevHash":"…","hash":"…"}

Graylog, Loki, Splunk, Microsoft Sentinel or any other system that collects container logs can pick these lines up by "type":"audit". Because they carry the number and checksum, a comparison with the log in the database shows any later change there.

Retention​

Entries are kept for 365 days by default and then deleted automatically (daily at 3:30). The cleanup itself leaves an entry (Old entries removed, with the number of entries), which keeps the shortened log verifiable. Your administrator can change the period with the environment variable AUDIT_LOG_RETENTION (in days) — see Local resources.

The log is stored in the file audit.db next to auth.db in the configuration directory. Include it in your backups if you need the log beyond a restore.