Audit Logs

KeenAgents keeps a permanent audit trail of your organization. Every admin operation — creating, changing, or deleting anything — is recorded as an action line naming the requester (email, user id, role), what was changed, and when. When the requester is an AI agent signed in through the Keen MCP Server, the line names the MCP account's id and role; the email is empty because MCP accounts have none. Platform errors are recorded the same way. This is the system audit — the platform's own record of who did what. Runtime lines your agents and scripts emit are kept separately, as per-space, per-agent Log Records you turn on and watch under Logs & Monitoring.

Delivery is buffered and durable: a log line is considered delivered only after it has been written. Lines emitted while the platform is briefly restarting or under maintenance wait and are written afterwards — the audit trail keeps recording even when other parts of the platform are in trouble, precisely because that is when you need it most.

{
  "timestamp": "2026-08-21T09:14:02.113Z",
  "level": "action",
  "channel": "system",
  "message": "Log Settings: admin@example.com / <user id> / admin set log setting: debug / true"
}

Channel

A named on/off destination for the system audit — the platform's own action, error, warning, info, and debug lines. Each channel + level pair is a setting you can see — and, where allowed, toggle — on the Logs page. Runtime logging from your own flows and agents is separate: it lands in dynamic Log Records per space and agent, covered under Logs & Monitoring.

Action lines

The audit trail proper: one line per admin operation, always naming the requester's email, user id, and role, plus what was done. Recorded unconditionally — the platform refuses to switch this channel off, because an audit trail you can silence is not an audit trail.

Log records

One JSON record per line: timestamp, level, channel and message — the requester (email, user id, role) and what changed are spelled out in the message itself. What you read back in the Logs page is exactly what was recorded — no summarizing, no rewriting.

Daily files

Lines are grouped into one file per channel + level per day — for example system-action-2026-08-21.log (the warning channel's files use the short level name, system-warn-2026-08-21.log) — and each channel keeps 30 days of history browsable from the Logs page.

Buffered delivery

A line is only counted as delivered once it has been written; until then it waits and is retried. Lines emitted during a restart or maintenance window are written when recording resumes, so a brief interruption never punches a hole in the trail.

System action and error lines are written unconditionally. Their switches are locked in the console — the row shows a Permanently engaged badge and cannot be flipped — and any attempt to flip them through the API is refused. The audit and error trails cannot be silenced, by anyone, so they are always trustworthy evidence.

• Reading a file returns its last 40 records, newest first — a tail view built for quick triage.
• Each channel + level keeps 30 days of daily files; older days age out of the browsable list.
• Toggling a channel takes effect for lines emitted afterwards — a line that arrived while its channel was off is dropped by design, not held for later.

• List a channel's files — pick a channel + level to see its available daily files, newest first, together with the channel's current on/off state.
• Read a file — open a daily file to see its last 40 records as parsed JSON, newest first.
• Toggle a channel — flip warning, info or debug on or off; action and error are locked (Permanently engaged) and cannot be flipped. A successful toggle shows a confirmation (for example Debug channel turned on) and is itself recorded as an audit line naming who flipped it, which setting, and the new value — changes to the trail are part of the trail.
• Access is role-gated: viewing the channels and files requires the logs permission; the on/off switches appear only for roles with logs write permission. Without the read grant the page refuses — audit data is sensitive, so access is deny-by-default.

• A line on a switched-off channel is gone, not buffered for later — toggling a channel on only affects lines emitted afterwards.
• System action and error lines are always written regardless of settings — do not expect those channels to go quiet.
• The file view shows the last 40 records only — it is a triage tail, not a full-file export.
• An AI agent connected through the Keen MCP Server with the logs permission can list and toggle channels and read files the same way; the same locks apply.
• Right after maintenance, the Logs page may briefly refuse access — try again a moment later. Recording itself is unaffected, and nothing is missing from the trail.