Vai al contenuto principale
Quando un revisore di compliance chiede “chi ha cambiato questa policy del firewall, e quando?”, la risposta è una riga nel tuo audit log del workspace. Ogni mutazione che tocca una risorsa governata — una policy del firewall, una regola, un guardrail, un prompt, una decisione di approvazione, il ruolo di un membro — scrive una riga di audit immutabile timbrata con l’attore, il target, il timestamp e un verbo di azione stabile. Questa pagina è la tabella di lookup per quei verbi: l’insieme completo delle azioni dell’audit log, raggruppate per la risorsa che descrivono, così puoi filtrare la traccia esattamente sugli eventi che ti servono.
Una riga di audit registra chi ha fatto cosa a quale risorsa. Non porta mai valori segreti, plaintext di chiavi gateway, blob di regole o corpi di prompt — il payload è solo metadata sicuri (id, nomi, verdetto, fase, is_default). Per la traccia di applicazione di cosa una policy ha fatto al traffico live — chiamate a tool negate, PII mascherate — vedi i feed Eventi del firewall e Match dei guardrail, che sono uno store separato da questo audit log.

​
1. Cosa copre il catalogo delle azioni dell’audit log

Due cose scrivono nella traccia di audit, e aiuta tenerle distinte:
  • Audit log — questa pagina. Un record append-only di modifiche di configurazione e governance: una policy modificata, un membro invitato, un’approvazione risolta. Timbrato con il verbo di azione, l’attore e il momento in cui ha fatto commit, dopo che la modifica ha avuto successo.
  • Feed di applicazione — i feed Eventi del firewall e Match dei guardrail. Il record di ogni decisione a runtime che il gateway ha preso su una richiesta. Volume più alto, store diverso.
I verbi di azione qui sotto sono stringhe stabili in lower-snake-case. Sopravvivono alle rinominazioni nella console, fanno grep in modo pulito in un export e sono ciò su cui filtri quando affetti la traccia per tipo di evento.
Ogni scrittura governata emette la sua riga di audit nella stessa transazione della modifica, quindi la traccia non può mai divergere dalla realtà — non c’è una finestra “la modifica ha fatto commit ma la riga di audit no”.

​
2. Le azioni dell’audit log, raggruppate per risorsa

OrcaRouter fornisce un catalogo fisso di verbi di azione. Quelli che crei giorno per giorno rientrano nei gruppi qui sotto.
Ogni create / update / delete su una policy del firewall o una delle sue regole, più i cambi di impostazioni a livello di workspace:firewall_policy_create · firewall_policy_update · firewall_policy_delete · firewall_rule_create · firewall_rule_update · firewall_rule_delete · firewall_settings_updateI payload delle policy portano {id, name, is_default, default_verdict, enabled}; i payload delle regole portano {id, policy_id, verdict, stage, tool_name_glob, priority}. Mai il blob completo della regola.
Il selettore di autonomia a un clic (tight / balanced / permissive) scrive una riga quando applicato e una quando annullato:firewall_autonomy_applied · firewall_autonomy_undoneLa riga applied porta lo snapshot di undo pre-apply nel suo payload, che è esattamente ciò da cui l’undo a un clic ricostruisce.
Quando un revisore risolve una chiamata a tool in attesa (un verdetto pending_approval), la decisione viene registrata:firewall_approval_approve · firewall_approval_rejectIl payload nota se la decisione è arrivata tramite la console o un callback webhook fuori banda — mai gli argomenti del tool.
Azioni sul set di tool governato di un MCP server registrato — quando il suo set di tool live risulta differire dal set approvato, quando un admin ri-approva il set corrente, e quando un admin mette in quarantena un server:firewall_mcp_schema_changed · firewall_mcp_schema_approved · firewall_mcp_schema_quarantinedIl payload è {mcp_server_id, name, tool_count} — mai argomenti del tool o credenziali.
Traccia forense per il registro dei prompt — create, edit, soft-delete (Trash), hard-delete (Purge), restore, spostamento di label, rollback di versione e import da un provider connesso:prompt_created · prompt_updated · prompt_deleted · prompt_purged · prompt_restored · prompt_label_moved · prompt_rollback · prompt_importedI payload serializzano solo metadata sicuri (id, name, kind, tags) — mai il contenuto o i messaggi del prompt.
Eventi di ciclo di vita e membership sul workspace stesso — creazione, archiviazione, inviti, cambi di ruolo, rimozioni, top-up del wallet e cambi di seat / gruppo / stato: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
Le modifiche ai guardrail mantengono la propria cronologia delle versioni per-guardrail — una traccia di diff-e-revert attaccata a ciascuna policy — in aggiunta all’audit log. Quando hai bisogno di tornare indietro su una modifica di content-policy, quella cronologia è la superficie da usare.

​
3. Un esempio concreto: tracciare una modifica a una policy del firewall

Diciamo che un collega ha allentato una regola di deny la settimana scorsa e devi sapere esattamente cosa è cambiato. Apri il drawer di audit del workspace nella console e filtra per l’azione firewall_rule_update. Ogni riga corrispondente ti dà la stessa forma:
CampoCosa ti dice
Actionfirewall_rule_update — il verbo su cui hai filtrato.
ActorIl membro che ha fatto la modifica.
TargetIl {id, policy_id} della regola e i suoi nuovi verdict, stage, tool_name_glob, priority.
Questo è abbastanza per ricostruire il prima/dopo della regola senza mai esporre le sue clausole di match complete. Se la modifica era invece uno switch di livello di autonomia, filtra su firewall_autonomy_applied e la riga porta lo snapshot da cui l’ undo a un clic ripristina.
Filtrare per un singolo verbo di azione è il modo più veloce per rispondere a una domanda point-in-time (“quando abbiamo attivato l’auto-approve?”, “chi ha eliminato quella policy?”). I verbi sono stringhe stabili, quindi un filtro salvato continua a funzionare attraverso le riprogettazioni della console.

​
4. Scope, retention ed erasure

Workspace-scoped

Ogni riga di audit appartiene a esattamente un workspace ed è leggibile solo al suo interno — nulla attraversa il confine di tenant. L’attore, il target e il payload sono tutti con scope su quel workspace. Vedi Scope, chiavi e policy.

Retention

Le righe di audit sono conservate fino a 180 giorni, poi scartate da una pulizia in background. I tuoi log delle richieste sono uno store separato con la propria retention — un default di 30 giorni, clampato lato server a un massimo rigido di 180 giorni.

Diritto all'oblio

Su una cancellazione del workspace o una richiesta esplicita di erasure, OrcaRouter concede una finestra di grazia di 30 giorni, poi cancella i PII dai log e dai record di audit per quel workspace. Vedi il glossario.

Evidenza di compliance

La traccia di audit è uno dei segnali su cui un compliance pack si basa per un report di readiness firmato. I report sono firmati Ed25519 e verificabili pubblicamente.
Non ricorrere all’audit log per rispondere “questa richiesta è stata bloccata?” — quello vive nei feed di applicazione, non qui. L’audit log risponde “questa policy è stata cambiata, e da chi?”. Sono store deliberatamente separati con retention diversa e percorsi d’accesso diversi. Vedi Perché è stato bloccato? per il lato runtime.

​
5. Dove andare dopo

Osservabilità del firewall

I feed events, runs e discovered-tools — il record di applicazione a runtime che completa questa traccia di configurazione.

Glossario dei verdetti

Ogni verdetto del firewall e azione del guardrail a cui la traccia fa riferimento, con stato HTTP e impatto sulla quota.

API Compliance

Trasforma la traccia in un report di readiness firmato e condivisibile con un auditor.

Scope, chiavi e policy

Come lo scoping del workspace limita ciò che una singola riga di audit può mai esporre.