Admin audit log

Schema: migration 11.

The mutating admin actions listed under “Action naming convention” below — API-key creation, update, rotation and revocation, provider-key validation, customer-managed-key register, rotate and revoke, prompt promotion and canary, account email change — each write one row to admin_audit_log (Postgres). Other admin actions are not recorded in this table. The row captures the actor, the target, before/after JSON snapshots, the request IP, and the user agent. The table is indexed for the most common query: “show me everything that happened to this workspace in the last 30 days.”

Schema at a glance

Column	Type	Meaning
`id`	`BIGSERIAL` PK	monotonically increasing row id
`occurred_at`	`TIMESTAMPTZ` (default `now()`)	when the action happened
`actor_user_id`	`TEXT`	WorkOS user id (opaque string `user_01H...`)
`actor_workspace_id`	`UUID` (nullable)	internal `tenants.id`; null for cross-workspace operator actions
`action`	`TEXT`	`<target>.<verb>` (see below)
`target_type`	`TEXT`	`api_key` / `provider_key` / `cmk_key` / `prompt` / `user`
`target_id`	`TEXT`	the mutated row’s id
`before_json`	`JSONB` (nullable)	row snapshot before the mutation; NULL for creates
`after_json`	`JSONB` (nullable)	row snapshot after the mutation; NULL for deletes
`ip_addr`	`INET` (nullable)	request first-hop IP (`x-forwarded-for`)
`user_agent`	`TEXT` (nullable)	request `User-Agent` header

Indexes:

idx_admin_audit_workspace (actor_workspace_id, occurred_at DESC) — workspace-scoped scan
idx_admin_audit_target (target_type, target_id, occurred_at DESC) — “what ever happened to this resource”

Action naming convention

<target>.<verb>. The verb is lowercase + concise; the target groups related actions. Recorded actions:

`action`	`target_type`	`target_id`	Source
`api_key.create`	`api_key`	apiKey UUID	`POST /api/settings/api-keys`
`api_key.update`	`api_key`	apiKey UUID	API-key settings edit
`api_key.rotate`	`api_key`	apiKey UUID	API-key rotation with a grace window
`api_key.revoke`	`api_key`	apiKey UUID	`DELETE /api/settings/api-keys/[keyId]`
`provider_key.validate`	`provider_key`	provider id	provider-key “Validate now” check
`cmk_key.register`	`cmk_key`	key id	`POST /api/settings/cmk-keys`
`cmk_key.rotate`	`cmk_key`	key id	`POST /api/settings/cmk-keys/[keyId]/rotate`
`cmk_key.revoke`	`cmk_key`	key id	`DELETE /api/settings/cmk-keys/[keyId]`
`prompt.promote`	`prompt`	prompt name	`POST /api/prompts/[name]/promote`
`prompt.canary`	`prompt`	prompt name	`POST /api/prompts/[name]/canary`
`account.email.change`	`user`	user id	account email change

Querying the log

”What did I do to this workspace in the last 30 days?"

SELECT occurred_at, action, target_type, target_id, actor_user_id
FROM admin_audit_log
WHERE actor_workspace_id = $1
  AND occurred_at >= now() - INTERVAL '30 days'
ORDER BY occurred_at DESC
LIMIT 200;

"What ever happened to this specific resource?"

SELECT occurred_at, action, actor_user_id, before_json, after_json
FROM admin_audit_log
WHERE target_type = 'api_key'
  AND target_id = $1
ORDER BY occurred_at DESC;

"Who is changing things from outside our office IPs?”

SELECT occurred_at, actor_user_id, action, ip_addr
FROM admin_audit_log
WHERE actor_workspace_id = $1
  AND ip_addr IS NOT NULL
  AND NOT (ip_addr <<= INET '203.0.113.0/24')
ORDER BY occurred_at DESC;

What the log is, and is not

Is: A durable record of who did what in the dashboard / gateway control surface — the table you query during an internal incident review. Is not: The tamper-evident agent event ledger That ledger captures the runtime behaviour of customer agents (LLM calls, tool calls, guardrail decisions) with a tamper-evident SHA-256 hash chain and customer-runnable verifier CLIs (Ed25519 batch signing

Sigstore Rekor v2 anchoring live, best-effort, on every plan). The admin audit log is the application-control mirror — a separate, simpler promise backed by Postgres + indexes, not by cryptographic anchoring.

Retention

There is no automated retention or archive job for this table. It is expected to grow ~100 rows/workspace/day at active use, ~36 K rows per workspace per year — well within Postgres comfort.

Coverage

Not every admin endpoint writes to this table; the actions listed above are the ones recorded.

Failure mode: write failure does not fail the request

recordAdminAction() (TypeScript, apps/web/lib/admin-audit.ts) is best-effort: a Postgres blip writes a console.error line and lets the calling route succeed. Rationale: we’d rather lose one audit row than return a 5xx to the user on a transient connection error. Operators tail the error log to catch sustained write failures.

Get started

SDKs

Integrations

Concepts

Features

Tools

Audit & compliance

Operations

Migrations

Comparisons

Admin audit log

Admin audit log

Schema at a glance

Action naming convention

Querying the log

”What did I do to this workspace in the last 30 days?"

"What ever happened to this specific resource?"

"Who is changing things from outside our office IPs?”

What the log is, and is not

Retention

Coverage

Failure mode: write failure does not fail the request

​Admin audit log

​Schema at a glance

​Action naming convention

​Querying the log

​”What did I do to this workspace in the last 30 days?"

​"What ever happened to this specific resource?"

​"Who is changing things from outside our office IPs?”

​What the log is, and is not

​Retention

​Coverage

​Failure mode: write failure does not fail the request

Admin audit log

Schema at a glance

Action naming convention

Querying the log

”What did I do to this workspace in the last 30 days?"

"What ever happened to this specific resource?"

"Who is changing things from outside our office IPs?”

What the log is, and is not

Retention

Coverage

Failure mode: write failure does not fail the request