Skip to main content
When a compliance reviewer asks “who changed this firewall policy, and when?”, the answer is one row in your workspace audit log. Every mutation that touches a governed resource — a firewall policy, a rule, a guardrail, a prompt, an approval decision, a member’s role — writes an immutable audit row stamped with the actor, the target, the timestamp, and a stable action verb. This page is the lookup table for those verbs: the complete set of audit log actions, grouped by the resource they describe, so you can filter the trail to exactly the events you need.
An audit row records who did what to which resource. It never carries secret values, gateway-key plaintext, rule blobs, or prompt bodies — the payload is safe metadata only (ids, names, verdict, stage, is_default). For the enforcement trail of what a policy did to live traffic — denied tool calls, masked PII — see the Firewall events and Guardrail Matches feeds, which are a separate store from this audit log.

​
1. What the audit log actions catalog covers

Two things write to the audit trail, and it helps to keep them apart:
  • Audit log — this page. An append-only record of configuration and governance changes: a policy edited, a member invited, an approval resolved. Stamped with the action verb, the actor, and the moment it committed, after the change succeeds.
  • Enforcement feeds — the Firewall events and Guardrail Matches feeds. The record of every runtime decision the gateway made on a request. Higher volume, different store.
The action verbs below are stable, lower-snake-case strings. They survive renames in the console, grep cleanly in an export, and are what you filter on when you slice the trail by event type.
Every governed write emits its audit row in the same transaction as the change, so the trail can never drift from reality — there is no “the edit committed but the audit row didn’t” window.

​
2. The audit log actions, grouped by resource

OrcaRouter ships a fixed catalog of action verbs. The ones you author day to day fall into the groups below.
Every create / update / delete on a firewall policy or one of its rules, plus workspace-level settings changes:firewall_policy_create · firewall_policy_update · firewall_policy_delete · firewall_rule_create · firewall_rule_update · firewall_rule_delete · firewall_settings_updatePolicy payloads carry {id, name, is_default, default_verdict, enabled}; rule payloads carry {id, policy_id, verdict, stage, tool_name_glob, priority}. Never the full rule blob.
The one-click autonomy picker (tight / balanced / permissive) writes one row when applied and one when undone:firewall_autonomy_applied · firewall_autonomy_undoneThe applied row carries the pre-apply undo snapshot in its payload, which is exactly what the one-click undo reconstructs from.
When a reviewer resolves a held tool call (a pending_approval verdict), the decision is recorded:firewall_approval_approve · firewall_approval_rejectThe payload notes whether the decision came via the console or an out-of-band webhook callback — never the tool arguments.
Actions on a registered MCP server’s governed tool set — when its live tool set is found to differ from the approved set, when an admin re-approves the current set, and when an admin quarantines a server:firewall_mcp_schema_changed · firewall_mcp_schema_approved · firewall_mcp_schema_quarantinedPayload is {mcp_server_id, name, tool_count} — never tool arguments or credentials.
Forensic trail for the prompt registry — create, edit, soft-delete (Trash), hard-delete (Purge), restore, label move, version rollback, and import from a connected provider:prompt_created · prompt_updated · prompt_deleted · prompt_purged · prompt_restored · prompt_label_moved · prompt_rollback · prompt_importedPayloads serialize only safe metadata (id, name, kind, tags) — never the prompt content or messages.
Lifecycle and membership events on the workspace itself — creation, archival, invites, role changes, removals, wallet top-ups, and seat / group / status changes:workspace_create · workspace_archive · invite · invite_resend · invite_revoke · accept · member_leave · role_change · remove · workspace_topup · group_change · seats_limit_change · status_change · workspace_promote_to_team
Guardrail edits keep their own per-guardrail version history — a diff-and-revert trail attached to each policy — in addition to the audit log. When you need to roll back a content-policy change, that history is the surface to use.

​
3. One concrete example: tracing a firewall policy change

Say a teammate loosened a deny rule last week and you need to know exactly what changed. Open the workspace audit drawer in the console and filter by the firewall_rule_update action. Each matching row gives you the same shape:
FieldWhat it tells you
Actionfirewall_rule_update — the verb you filtered on.
ActorThe member who made the change.
TargetThe rule’s {id, policy_id} and its new verdict, stage, tool_name_glob, priority.
That is enough to reconstruct the before/after of the rule without ever exposing its full match clauses. If the change was an autonomy-level switch instead, filter on firewall_autonomy_applied and the row carries the snapshot the one-click undo restores from.
Filtering by a single action verb is the fastest way to answer a point-in-time question (“when did we turn on auto-approve?”, “who deleted that policy?”). The verbs are stable strings, so a saved filter keeps working across console redesigns.

​
4. Scope, retention & erasure

Workspace-scoped

Every audit row belongs to exactly one workspace and is readable only within it — nothing crosses the tenant boundary. The actor, target, and payload are all scoped to that workspace. See Scope, keys & policies.

Retention

Audit rows are retained up to 180 days, then aged out by a background cleanup. Your request logs are a separate store with their own retention — a 30-day default, server-clamped to a 180-day hard maximum.

Right to erasure

On a workspace deletion or explicit erasure request, OrcaRouter grants a 30-day grace window, then scrubs PII from logs and audit records for that workspace. See the glossary.

Compliance evidence

The audit trail is one of the signals a compliance pack draws on for a signed readiness report. Reports are Ed25519-signed and publicly verifiable.
Don’t reach for the audit log to answer “was this request blocked?” — that lives in the enforcement feeds, not here. The audit log answers “was this policy changed, and by whom?”. They are deliberately separate stores with different retention and different access paths. See Why was this blocked? for the runtime side.

​
5. Where to go next

Firewall observability

The events, runs, and discovered-tools feeds — the runtime enforcement record that complements this configuration trail.

Verdict glossary

Every firewall verdict and guardrail action the trail references, with HTTP status and quota impact.

Compliance API

Turn the trail into a signed, auditor-shareable readiness report.

Scope, keys & policies

How workspace scoping bounds what any single audit row can ever expose.