Mancanza di attribuzione e forense

Quando qualcosa va storto con un agent, la prima domanda è sempre la stessa: cosa ha effettivamente fatto, e chi ha cambiato la policy che gliel’ha permesso? Senza una traccia non puoi rispondere a nessuna delle due. Non puoi mostrare a un auditor che un controllo era in vigore nel giorno in questione, non puoi distinguere un vero attacco da un rumoroso falso positivo, e non puoi ricostruire la run che ha fatto trapelare la riga. OrcaRouter registra la risposta strada facendo. Ogni prompt filtrato, ogni chiamata a tool, ogni approvazione e ogni modifica di policy finisce in un record interrogabile con scope a livello di workspace — correlato alla run e alla sessione dell’agent che lo ha prodotto. Questa pagina mostra come usare quel record come traccia di audit dell’agent AI: da una singola run sospetta a un report firmato che consegni a un auditor.

​

1. I quattro record dietro una traccia di audit dell’agent AI

L’attribuzione viene da quattro stream indipendenti, ciascuno correlato alla stessa run e sessione così puoi fare pivot tra di essi: Il tessuto connettivo è l’id di run dell’agent e di sessione. Un match di guardrail e un evento del firewall dalla stessa conversazione portano la stessa lineage di run, così “questa run ha mascherato un’email, poi ha provato un fetch che abbiamo negato, poi è stata approvata per una scrittura” si legge come un’unica storia invece di tre log scollegati.

​

2. Matches dei guardrail — cosa è stato filtrato (Member)

Ogni volta che una regola di guardrail scatta, il gateway scrive un match. Il feed vive sulla pagina Guardrails (tab Matches) ed è leggibile da ogni membro del workspace. Ogni match registra il tipo di regola, l’azione intrapresa (block / mask / flag / annotate / spotlight), lo stage (input / output), una stringa di dettaglio e la lineage di run della richiesta che lo ha attivato. Elencalo, raggruppalo per guardrail o tipo di regola, filtra per azione, entra nel dettaglio di un match o esporta il feed in CSV. Una regola rumorosa fa parte anch’essa della traccia. Marca un match come falso positivo con POST /api/guardrail/match/:id/mark-fp (Admin) così il tuo segnale resta pulito e i tuoi report non sovra-contano.

​

3. Events & Runs del firewall — cosa ha fatto l’agent (Developer+)

Dove i Matches coprono il testo, gli Events del firewall coprono le azioni. Ogni valutazione di chiamata a tool è loggata con il suo verdetto, la superficie, il nome del tool e — soprattutto — la run e la sessione dell’agent a cui appartiene. Le letture su Events, sul rollup Runs/sessions e sulla trace per run richiedono Developer+; i feed più leggeri Discovered-tools e anomalie sono aperti a ogni Member. La vista Runs & sessions è il cavallo da lavoro forense: aggrega gli eventi per run dell’agent in una ripartizione dei verdetti, i tool e i modelli distinti che la run ha toccato e i timestamp di primo/ultimo visto — la risposta “cosa ha effettivamente fatto questo agent” in una sola schermata. Oltre ai verdetti statici, il feed delle anomalie segnala le deviazioni dalla baseline ora-della-settimana appresa di ciascun workspace (una media mobile a 14 giorni) — picchi di rate e di costo, retry_loop e transizioni novel_path — così un pattern consentito-ma-anomalo emerge comunque nel record.

​

4. Decisioni di approvazione — chi ha detto sì (azione di audit)

Quando una regola si risolve in pending_approval, la chiamata trattenuta diventa una revisione fuori banda (vedi il flusso HITL del Firewall). La decisione fa parte della traccia: approvare o rifiutare scrive una riga di audit del workspace — firewall_approval_approve o firewall_approval_reject — che nomina l’attore. Le decisioni sono first-writer-wins e idempotenti, e se la regola sottostante è cambiata dopo l’hold, l’arricchimento annota che il contesto si è spostato. Quindi una chiamata a tool trattenuta-poi-approvata è completamente attribuibile end to end: l’evento del firewall mostra l’hold, la riga di audit mostra chi l’ha rilasciata, ed entrambi correlano alla stessa run.

​

5. Audit delle modifiche alle policy — chi ha cambiato le regole

Una traccia del comportamento dell’agent è affidabile solo se puoi anche provare qual era la policy al momento — e chi l’ha cambiata. I Guardrails mantengono una storia completa delle versioni. Ogni create, update e delete scrive una riga di storia versionata nella stessa transazione della modifica. Apri History su un guardrail per vedere ogni versione con autore e timestamp, fare il diff di due qualsiasi e fare revert a una più vecchia (il revert è registrato come una nuova versione — la storia non viene mai mutata). Le modifiche a policy, regole e impostazioni del Firewall scrivono ciascuna una riga di audit del workspace dopo che la modifica viene committata — firewall_policy_update, firewall_rule_create, firewall_settings_update e così via — e le modifiche di livello di autonomia (firewall_autonomy_applied / firewall_autonomy_undone) catturano lo snapshot dello stato precedente che alimenta l’undo a un clic. Segreti e blob delle regole non vengono mai loggati.

​

6. Un esempio pratico: traccia una run sospetta

Supponiamo che una run venga segnalata per una chiamata in uscita inattesa. Dalla console, con una sessione Developer+: Una run, quattro record correlati, nessuna archeologia di log-grep. Per le difese di esfiltrazione stesse, vedi Esfiltrazione di dati e Chiamate a tool pericolose.

​

7. Report di compliance firmati — una traccia che un auditor può verificare

Per una prova esterna, la superficie Compliance trasforma questa traccia in un unico artefatto. Sfogliare il catalogo dei framework, i pack e la readiness è aperto a ogni Member ed è gratuito; installare un pack, generare un report, andare live e impostare la residenza dei dati sono azioni di Admin del workspace su un piano a pagamento (server-gated). Un report di compliance è firmato Ed25519 con un hash di contenuto SHA256 ed è pubblicamente verificabile — il destinatario lo controlla senza un account OrcaRouter: I report si esportano come CSV / JSON / PDF. I framework includono soc2, hipaa, gdpr, iso_27001, iso_42001, nist_ai_rmf, pci_dss, l’EU AI Act (eu_ai_act) e l’OWASP Top 10 for LLM Applications (owasp_llm), tra gli altri — installare un pack materializza i guardrail e le policy del firewall corrispondenti così i controlli su cui fai report sono i controlli effettivamente applicati.

​

8. Retention e diritto alla cancellazione

Un record forense è limitato, non per sempre. I log delle richieste hanno una retention di default di 30 giorni e sono server-clamped a un massimo netto di 180 giorni. Quando un utente si auto-cancella, si applica una finestra di grazia di 30 giorni, dopo la quale le sue PII vengono ripulite e la cascata purga i suoi match dei guardrail, i log delle richieste e gli eventi del firewall — soddisfacendo gli obblighi di diritto alla cancellazione / DSAR mantenendo intatta la storia di audit aggregata.

​

9. Dove andare dopo