Audit log

The audit log is the per-Team append-only record of everything that happened — every tool call, state transition, webhook delivery, and approval decision. When you hand real authority to an agent, this is the surface that lets you trust it: one coherent stream that answers "what did my agents do, and what did I do?"

What gets recorded

Each entry is one thing that happened — a schedule.create, a deadline.overdue, an approval.approved, a webhook.delivered. The log is append-only: rows are never edited or deleted by the application, so the history you read is the history that occurred.

Crucially, an entry records the event, not a snapshot of the object. A schedule.create row holds the inputs and outputs of that action (fire_at, webhook_url, the recurrence); a webhook.delivered row holds the event_id, URL, status code, and attempt number. State at any past moment is reconstructed by replaying events, which keeps the log bounded and avoids leaking unrelated fields. Sensitive values — a Watch's auth headers, an approval token, a signing secret — are redacted at write time and never appear.

Related events share a correlation id, so the Dashboard can render a whole chain as one thread: this approval.create led to that webhook.delivered, which six hours later led to this approval.approved.

Who did what: actors

Every entry names the actor that produced it, in an actor_type field:

  • user — a human in the Dashboard.
  • api_key — a write over the HTTP API.
  • mcp — an agent over the MCP server.
  • approver — an anonymous human deciding an approval through its capability URL (not a member of your Team, and with no login).
  • system — our own workers: spawning the next occurrence of a recurring series, the overdue scan, the approval-timeout scan.

The mcp-versus-user split is the one you'll lean on most. It is what lets you separate "my agent did this" from "I did this" at a glance — the whole premise of delegating to an agent while staying accountable for the outcome.

Browsing, filtering, exporting

The audit log is a Dashboard-first surface. Open the Activity feed (/a/<team_slug>/aigears/activity/) to browse your Team's stream newest-first, filter by actor, action, or subject, follow a correlation thread, and export. Dead-lettered webhook deliveries are surfaced here prominently. Test deliveries from the Webhook Tester are excluded by default.

There is no audit-read endpoint on the HTTP API in v1. The audit log is a trust-and-inspection surface built for humans, so it lives on the Dashboard; the HTTP API is for driving the primitives, and every write your key makes is recorded in the log for you to review there. (Enterprise log-streaming, when it lands, will be a downstream export pipeline — not a new read API.)

Likewise, no MCP tool reads the audit log. An agent's job is to act, not to audit itself; keeping the record out of the agent's reach is deliberate — you review what the agent did from the Dashboard, where actor_type=mcp marks its writes distinctly from your own.

Retention

How far back the log goes is tier-bound — higher tiers keep a longer window. Rather than restate the numbers here, see Limits & tiers, which links /pricing/ as the source of truth for retention windows.