Audit log

The audit log records security-relevant activity in your workspace: who did it, when, from which IP address and browser, and what it was done to. Workspace admins can read it in the app, download it as a CSV file, and connect a SIEM to it through the API.

Workspace settings → Audit log sits under Security & data. Owners and admins see it by default. The permission behind it is View and export the audit log (see Permissions). It is read-only, so an admin can grant it to a viewer, for example an outside auditor who should see the log and nothing else.

What is recorded

Area	Events
Sign-in	Each sign-in to the web app, with a password or through single sign-on. Each sign-in the identity provider accepted but the workspace refused: SSO required, no access to the workspace, or access still pending approval.
Members	Invitations by email or link, and invitations revoked. Members joining, whether by accepting an invitation, being approved, joining through SSO or being added directly. Role changes with the old and new role. Members removed, timed access granted or lifted, a password set by an admin, and ownership transferred.
API keys	Keys created, revoked or rotated: workspace keys, personal keys and developer-gateway keys. The event records which key, never the key itself.
Workspace configuration	Settings changes with each changed setting's old and new value; credentials such as provider keys are masked to their last four characters. Also changes to the permission matrix (each changed cell), single sign-on, workspace features and integrations, and deletion of the workspace.
Sharing	Chat share links created or revoked. Changes to the share-link policy appear as settings changes.
Data leaving the platform	Survey, narrative test and report exports (spreadsheet, PDF, PowerPoint), reports sent by email with their recipients, and every download of the audit log itself.
Deletions	Documents, knowledge bases, personas and chats.

Actions by Kumkuat support staff in your workspace are recorded like anyone else's. When the staff member is not a member of your workspace, the actor is marked Kumkuat support.

What each event contains

Field	Meaning
occurred_at	When it happened, in UTC.
type	The event type, for example member.role_changed. GET /api/v1/audit-events/types lists every type with a description.
outcome	success, or failure for a refused sign-in.
actor	Who did it: a user (with their email at the time), a workspace API key, Kumkuat support, or Kumkuat itself for automatic actions. Includes the id of the API key or session used.
source	The client IP address and user agent. For an action taken in the web app this is the person's browser. For an API call it is the caller.
target	What was acted on: its type, id and name.
detail	Event-specific fields, such as old and new values.
id	A unique event id. Use it to deduplicate.

Download a CSV

In Audit log → Download, choose a date range and click Download CSV. The file lists the events oldest first and follows the filter chosen above it. Each download is itself recorded as an audit_log.exported event.

Send it to your SIEM

Most SIEMs can poll a REST API on a schedule. Point yours at the audit events endpoint with a workspace API key:

curl -H "X-API-Key: $KUMKUAT_KEY" \
  "https://api.kumkuat.ai/api/v1/audit-events?since=2026-10-01T00:00:00Z&limit=1000"

{
  "events": [
    {
      "id": "evt_6f1c...",
      "cursor": "18342",
      "occurred_at": "2026-10-23T14:02:11.204Z",
      "type": "member.role_changed",
      "outcome": "success",
      "workspace_id": "ws_...",
      "actor": {"type": "user", "user_id": "...", "email": "ada@example.com", "api_key_id": "..."},
      "source": {"ip": "203.0.113.7", "user_agent": "Mozilla/5.0 ..."},
      "target": {"type": "member", "id": "...", "name": "sam@example.com"},
      "detail": {"old_role": "member", "new_role": "admin"},
      "request_id": "..."
    }
  ],
  "next_cursor": "18342",
  "has_more": false,
  "order": "asc"
}

• Polling. Events come oldest first. Store next_cursor from each response and send it as cursor on the next request. Use since only for the first request. When has_more is true, another page is ready, so request it straight away.
• Delay. An event appears in the feed about 5 seconds after it happens. The feed holds back the newest few seconds so that a cursor never skips an event.
• Filtering. type takes a comma-separated list of types or whole categories, for example type=auth.*,api_key.*. until bounds the range, and limit is at most 1000.
• Key. Audit log → Create a read-only key for your SIEM creates a workspace API key that can read the audit log and nothing else. It is listed with the other workspace keys under Integrations, where you can revoke it. The CSV is also available at GET /api/v1/audit-events/export.csv.
• Policy. The API refuses keys while API clients is off in Workspace policy.

The full contract for the three endpoints is in the API reference under Audit log.

Integrity and retention

• Append-only. Events cannot be edited or deleted from the app or the API. The database itself refuses to change an event, or to delete one less than a year old.
• Kept for 400 days. Events are deleted automatically once they are 400 days old. They are not affected by the data retention setting, and they are kept after the workspace is deleted until they age out.
• Recorded as it happens. Each event is written when the action completes. If an event cannot be stored, it is written to Kumkuat's service logs instead, so it is not lost.

What is not recorded

• Reading. Opening documents, chats and reports is not logged.
• Wrong passwords. Your identity provider checks passwords before Kumkuat sees the sign-in. With single sign-on, your own identity provider's logs hold failed attempts.
• Infrastructure. Administrative activity on Kumkuat's cloud project is recorded in Google Cloud's audit logs, which Kumkuat retains for 400 days. Those logs are not in this feed.
• Push delivery. Kumkuat does not push events to a webhook or a SIEM collector. Your SIEM polls the API.