Zum Hauptinhalt springen
Wenn ein Compliance-Prüfer fragt „wer hat diese Firewall-Policy geändert, und wann?”, ist die Antwort eine Zeile in Ihrem Workspace-Audit-Log. Jede Mutation, die eine gesteuerte Ressource berührt — eine Firewall-Policy, eine Regel, ein Guardrail, ein Prompt, eine Approval-Entscheidung, die Rolle eines Mitglieds — schreibt eine unveränderliche Audit-Zeile, gestempelt mit dem Akteur, dem Ziel, dem Timestamp und einem stabilen Action-Verb. Diese Seite ist die Nachschlagetabelle für diese Verben: das vollständige Set der Audit-Log-Actions, gruppiert nach der Ressource, die sie beschreiben, sodass Sie den Trail auf genau die Events filtern können, die Sie brauchen.
Eine Audit-Zeile zeichnet wer was mit welcher Ressource getan hat. Sie trägt nie Secret-Werte, Gateway-Key-Klartext, Regel-Blobs oder Prompt-Bodys — das Payload sind nur sichere Metadaten (IDs, Namen, Verdikt, Stage, is_default). Für den Durchsetzungs-Trail dessen, was eine Policy mit Live-Traffic getan hat — abgelehnte Tool-Calls, maskierte PII — siehe die Firewall-Events- und Guardrail-Matches-Feeds, die ein separater Store von diesem Audit-Log sind.

​
1. Was der Audit-Log-Actions-Katalog abdeckt

Zwei Dinge schreiben in den Audit-Trail, und es hilft, sie auseinanderzuhalten:
  • Audit-Log — diese Seite. Ein append-only Datensatz von Konfigurations- und Governance-Änderungen: eine Policy bearbeitet, ein Mitglied eingeladen, eine Freigabe aufgelöst. Gestempelt mit dem Action-Verb, dem Akteur und dem Moment, in dem es committed wurde, nachdem die Änderung erfolgreich ist.
  • Durchsetzungs-Feeds — die Firewall-Events- und Guardrail-Matches-Feeds. Der Datensatz jeder Laufzeit-Entscheidung, die das Gateway auf einem Request getroffen hat. Höheres Volumen, anderer Store.
Die Action-Verben unten sind stabile lower-snake-case-Strings. Sie überleben Umbenennungen in der Konsole, grepen sauber in einem Export und sind das, wonach Sie filtern, wenn Sie den Trail nach Event-Typ schneiden.
Jeder gesteuerte Schreibvorgang erzeugt seine Audit-Zeile in der selben Transaktion wie die Änderung, sodass der Trail nie von der Realität abdriften kann — es gibt kein „die Bearbeitung wurde committed, aber die Audit-Zeile nicht”-Fenster.

​
2. Die Audit-Log-Actions, gruppiert nach Ressource

OrcaRouter liefert einen festen Katalog von Action-Verben. Die, die Sie Tag für Tag verfassen, fallen in die Gruppen unten.
Jeder Create / Update / Delete auf einer Firewall-Policy oder einer ihrer Regeln, plus Einstellungsänderungen auf Workspace-Ebene:firewall_policy_create · firewall_policy_update · firewall_policy_delete · firewall_rule_create · firewall_rule_update · firewall_rule_delete · firewall_settings_updatePolicy-Payloads tragen {id, name, is_default, default_verdict, enabled}; Regel-Payloads tragen {id, policy_id, verdict, stage, tool_name_glob, priority}. Nie den vollständigen Regel-Blob.
Der Ein-Klick-Autonomie-Picker (tight / balanced / permissive) schreibt eine Zeile beim Anwenden und eine beim Rückgängigmachen:firewall_autonomy_applied · firewall_autonomy_undoneDie applied-Zeile trägt den Pre-Apply-Undo-Snapshot in ihrem Payload, was genau das ist, woraus das Ein-Klick-Undo rekonstruiert.
Wenn ein Prüfer einen zurückgehaltenen Tool-Call (ein pending_approval-Verdikt) auflöst, wird die Entscheidung aufgezeichnet:firewall_approval_approve · firewall_approval_rejectDas Payload notiert, ob die Entscheidung über die Konsole oder einen Out-of-band-Webhook-Callback kam — nie die Tool-Argumente.
Actions auf dem gesteuerten Tool-Set eines registrierten MCP-Servers — wenn sich sein Live-Tool-Set vom genehmigten Set unterscheidet, wenn ein Admin das aktuelle Set neu genehmigt und wenn ein Admin einen Server quarantäniert:firewall_mcp_schema_changed · firewall_mcp_schema_approved · firewall_mcp_schema_quarantinedDas Payload ist {mcp_server_id, name, tool_count} — nie Tool-Argumente oder Credentials.
Forensischer Trail für die Prompt-Registry — create, edit, soft-delete (Trash), hard-delete (Purge), restore, label move, version rollback und import von einem verbundenen Anbieter:prompt_created · prompt_updated · prompt_deleted · prompt_purged · prompt_restored · prompt_label_moved · prompt_rollback · prompt_importedPayloads serialisieren nur sichere Metadaten (id, name, kind, tags) — nie den Prompt-Inhalt oder die Nachrichten.
Lebenszyklus- und Mitgliedschaftsereignisse auf dem Workspace selbst — Erstellung, Archivierung, Einladungen, Rollenänderungen, Entfernungen, Wallet-Top-ups und Seat- / Group- / Status-Änderungen: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-Bearbeitungen behalten ihre eigene Per-Guardrail-Versionshistorie — einen Diff-und-Revert-Trail, der an jede Policy angehängt ist — zusätzlich zum Audit-Log. Wenn Sie eine Inhaltspolicy-Änderung zurückrollen müssen, ist diese History die Surface, die Sie verwenden.

​
3. Ein konkretes Beispiel: eine Firewall-Policy-Änderung verfolgen

Sagen wir, ein Teamkollege hat letzte Woche eine Deny-Regel gelockert und Sie müssen genau wissen, was sich geändert hat. Öffnen Sie das Workspace-Audit-Drawer in der Konsole und filtern Sie nach der firewall_rule_update-Action. Jede gematchte Zeile gibt Ihnen dieselbe Form:
FeldWas es Ihnen sagt
Actionfirewall_rule_update — das Verb, nach dem Sie gefiltert haben.
AkteurDas Mitglied, das die Änderung vorgenommen hat.
ZielDie {id, policy_id} der Regel und ihr neues verdict, stage, tool_name_glob, priority.
Das reicht, um das Vorher/Nachher der Regel zu rekonstruieren, ohne je ihre vollständigen Match-Klauseln zu exponieren. Wenn die Änderung stattdessen ein Autonomie-Stufen-Wechsel war, filtern Sie nach firewall_autonomy_applied und die Zeile trägt den Snapshot, aus dem das Ein-Klick-Undo wiederherstellt.
Nach einem einzelnen Action-Verb zu filtern ist der schnellste Weg, eine Point-in-Time-Frage zu beantworten („wann haben wir Auto-Approve eingeschaltet?”, „wer hat diese Policy gelöscht?”). Die Verben sind stabile Strings, sodass ein gespeicherter Filter über Konsolen-Redesigns hinweg weiter funktioniert.

​
4. Scope, Retention & Erasure

Workspace-bezogen

Jede Audit-Zeile gehört zu genau einem Workspace und ist nur innerhalb dessen lesbar — nichts überquert die Tenant-Grenze. Der Akteur, das Ziel und das Payload sind alle auf diesen Workspace gescoped. Siehe Scope, Keys & Policies.

Retention

Audit-Zeilen werden bis zu 180 Tage aufbewahrt, dann durch ein Hintergrund-Cleanup ausgealtert. Ihre Request-Logs sind ein separater Store mit eigener Retention — ein 30-Tage-Default, server-geklemmt auf ein hartes 180-Tage-Maximum.

Recht auf Löschung

Bei einer Workspace-Löschung oder einem expliziten Löschungsantrag gewährt OrcaRouter ein 30-Tage-Gnadenfenster und scrubbt dann PII aus Logs und Audit-Datensätzen für diesen Workspace. Siehe das Glossar.

Compliance-Evidenz

Der Audit-Trail ist eines der Signale, auf das ein Compliance-Pack für einen signierten Readiness-Report zurückgreift. Reports sind Ed25519-signiert und öffentlich verifizierbar.
Greifen Sie nicht zum Audit-Log, um „war dieser Request blockiert?” zu beantworten — das lebt in den Durchsetzungs-Feeds, nicht hier. Das Audit-Log beantwortet „wurde diese Policy geändert, und von wem?”. Sie sind bewusst separate Stores mit verschiedener Retention und verschiedenen Zugriffspfaden. Siehe Warum wurde das blockiert? für die Laufzeitseite.

​
5. Wohin als Nächstes

Firewall-Observability

Die Events-, Runs- und Discovered-tools-Feeds — der Laufzeit-Durchsetzungs- datensatz, der diesen Konfigurations-Trail ergänzt.

Verdikt-Glossar

Jedes Firewall-Verdikt und jede Guardrail-Aktion, auf die der Trail verweist, mit HTTP-Status und Kontingentauswirkung.

Compliance-API

Verwandeln Sie den Trail in einen signierten, auditor-teilbaren Readiness-Report.

Scope, Keys & Policies

Wie Workspace-Scoping begrenzt, was eine einzelne Audit-Zeile je exponieren kann.