Esecuzioni e proposte degli agenti
La scheda Agents → Executions è disponibile ai ruoli operativi partner_owner, partner_admin, tenant_admin, tenant_analyst e agli amministratori di piattaforma, entro il perimetro autorizzato. La configurazione dei modelli resta nella scheda amministrativa Models.
Aprire la lavorazione corretta
Per l'amministratore il percorso è Amministrazione → Impostazioni globali → Agents → Executions. La route della scheda è /agents?tab=executions; i controlli effettivamente disponibili dipendono dal profilo. Se devi avviare raccomandazioni, ottimizzazione o audit, seleziona prima il tenant e verifica che esistano dati della sorgente pertinente.
| Esigenza | Attività e azione | Risultato atteso |
|---|---|---|
| Capire come è stato analizzato un alert | Triage alert, ricerca ID e dettaglio run | Evidenze di esecuzione e applicazione, senza accodare una nuova analisi. |
| Proporre una nuova detection dai dati del tenant | Raccomandazioni policy → New run | Candidati da revisionare; Accept draft crea una bozza, non una regola già attiva. |
| Analizzare rumore o opportunità nei log | Ottimizzazione log → New run | Finding e candidati di tipo noise reduction o detection policy. |
| Ripetere periodicamente l'ottimizzazione | Schedule del tenant | Elaborazioni future secondo intervallo e lookback; lo switch non sostituisce la run manuale. |
| Verificare la normalizzazione dei log | Audit parser → New audit | Report sullo scope richiesto/effettivo; eventuale candidato scaffold. |
| Diagnosticare una catena Blog | Catene editoriali → Dettagli | Stato, policy acquisita, contatori e diagnosi del contenuto; riservato a platform admin. |
Filtri e indicatori
| Controllo | Valori | Effetto |
|---|---|---|
| Attività | Triage alert, raccomandazioni policy, ottimizzazione log, audit parser; catene editoriali per platform admin | Cambia il tipo di esecuzione osservato. |
| Stato esecuzione | Insieme specifico dell'attività | Filtra le run; non lo stato degli alert collegati. |
| Periodo riepilogo | Ultime 24 ore / ultimi 7 giorni | Aggiorna i riepiloghi. Non filtra per data gli elenchi, che mantengono la propria paginazione. |
| Provider, nel triage | Provider presenti nelle metriche | Restringe le run del triage. |
| Trigger, nel triage | alert_ingested, manual_rerun | Distingue attivazione da ingestione e rilancio manuale. |
| Ricerca run/alert ID | Identificativo | Ricerca tecnica della run o del relativo alert. |
Il triage mostra conteggi in coda, in esecuzione, da revisionare, falliti nella finestra, retry pendenti e azioni applicate. Il dettaglio della run distingue stato, tentativi, modello/provider, tempi, output, errori e applicazioni delle azioni. Un output generato non prova che l'azione sia stata applicata.
| Stato | Lettura |
|---|---|
queued | In coda, elaborazione non ancora iniziata. |
running | Elaborazione in corso. |
awaiting_review | Risultato da revisionare. |
completed | Triage completato. |
no_recommendation | Il processo non ha prodotto una raccomandazione; disponibile per policy, ottimizzazione e audit. |
needs_more_data | Dati insufficienti per ottimizzazione/audit. |
failed | Run fallita: esaminare errore e tentativi. |
cancelled | Run annullata. |
Le catene editoriali hanno una vista dedicata senza filtro stato server e senza il selettore del periodo di riepilogo.
Raccomandazioni di policy
New run richiede un tenant selezionato e accoda una richiesta manuale. Apri la run, poi il candidato; confronta motivazione, sintesi evidenze, segnale atteso, confidenza, evidence score e rischi prima della revisione.
| Campo candidato | Vincolo / uso |
|---|---|
| Title | Obbligatorio; titolo della proposta. |
| Severity | low, med, high, critical. |
| Category | auth, malware, network, backup, other. |
| Tags | Elenco separato da virgole; spazi esterni ed elementi vuoti rimossi. |
| Policy id | Identificativo obbligatorio della policy proposta. |
| Spec JSON | JSON sintatticamente valido, obbligatorio; struttura della specifica della policy da revisionare. Conserva il tipo di policy e i parametri coerenti con il candidato. |
| Review note | Nota facoltativa della revisione, normalizzata eliminando gli spazi esterni. |
Save changes aggiorna il candidato. Accept draft invia anche gli override del form e crea una bozza di Detection policy: non è una pubblicazione automatica in produzione. Reject registra il rifiuto, con la nota se presente.
Sono revisionabili i candidati awaiting_review, accepted o edited. I candidati rejected, superseded o già applicati a una bozza non possono essere accettati come nuova bozza. Il collegamento alla policy creata evita di trattare un risultato già utilizzato come un candidato nuovo.
Dalla run alla bozza di policy
- Seleziona il tenant, apri Raccomandazioni policy e controlla le run esistenti per non duplicare una lavorazione già in corso.
- Premi New run. Attendi il passaggio dalla coda a un esito leggibile; usa l'ID della run per seguirla.
- Se l'esito è
awaiting_review, apri il candidato. Se èno_recommendation, consulta il dettaglio: non aspettarti una bozza inesistente. - Leggi motivazione, evidenze e segnale atteso; confronta i parametri JSON con il comportamento desiderato. Modifica i campi necessari e premi Save edits se vuoi conservare la revisione senza accettarla.
- Premi Accept draft per creare la bozza oppure Reject per rifiutare, compilando la nota quando serve a motivare la scelta.
- Usa Open draft sul candidato accettato e verifica la policy in Detection. Il lavoro è concluso quando la bozza corretta è raggiungibile; la sua attivazione segue il flusso Detection.
Ottimizzazione log
Il workspace distingue Finding di ottimizzazione e candidati di azione. I filtri dei candidati includono stato (awaiting_review, accepted, edited, rejected, superseded, applied_to_draft) e tipo:
| Tipo | Azione disponibile | Effetto |
|---|---|---|
noise_reduction | Accept review | Accetta la revisione della proposta di riduzione del rumore. Non equivale da solo a installare una modifica al parser o al Data Plane. |
detection_policy | Spawn policy run | Avvia una run figlia di raccomandazione policy e rende disponibile il collegamento. Un candidato con run figlia già presente non ne crea una seconda dallo stesso controllo. |
Il form ha Title, Severity, Category, Proposed action JSON obbligatorio e sintatticamente valido, Review note facoltativa. Le severità e categorie sono quelle della tabella precedente. Prima di accettare confronta impatto previsto, rischio e prove della run. Sono modificabili/azionabili i candidati awaiting_review o edited.
Pianificazione dell'ottimizzazione
La tabella delle schedule espone attivazione, intervallo, lookback e prossima esecuzione. Lo switch abilita/disabilita la schedule del tenant preservando i parametri esistenti. Quando crea una configurazione mancante, la UI propone:
- intervallo 1.440 minuti (24 ore);
- lookback 1.440 minuti;
- prossima run circa un minuto dopo la richiesta;
- versione attesa della schedule, quando già esistente.
Questa schermata espone lo switch; non presenta un editor libero per tutte le durate. La run manuale New run resta separata dalla pianificazione.
Per predisporre una schedule, seleziona il tenant e apri Ottimizzazione log. Se manca, premi Create schedule: il comando crea la configurazione disabilitata con i valori iniziali sopra. Controlla intervallo, lookback e prossima esecuzione nella riga, quindi abilita lo switch se vuoi attivarla. Dopo la risposta rileggi lo stato: la creazione della riga non significa che la pianificazione sia già accesa.
Audit parser
L'audit cerca problemi di normalizzazione sui log del tenant. I suoi controlli sono:
| Campo | Valori |
|---|---|
| Source family | windows_sysmon, windows_endpoint, acronis, ubiquiti, qnap, generic_syslog, generic_http_json. |
| Lookback | 1, 3, 6, 12, 24 o 72 ore. |
| New audit | Crea una nuova run manuale per la combinazione scelta. |
| Create parser candidate | Genera un artefatto candidato soltanto quando lo scope delle evidenze è adeguato. |
| Export debug data | Scarica un JSON della run selezionata. Il file può contenere evidenze: anonimizzalo prima di condividerlo fuori dal perimetro autorizzato. |
Nel dettaglio confronta scope richiesto e scope effettivo. Un report partial_scope può essere consultabile ma non applicare tutti i filtri richiesti; questo può avvenire su indici precedenti ai campi log.* usati dall'audit. Riduci il lookback ai log acquisiti dopo il deployment del parser pertinente. La generazione del candidato resta bloccata finché lo scope non è esatto.
Il candidato parser della fase corrente è uno scaffold con metadati delle evidenze e attività di revisione: non modifica i parser runtime. Il dettaglio contiene tipo, recommendation kind, severità, confidenza, evidence score, motivazione, artefatto JSON, impatto e rischio. La UI consente il rifiuto di un candidato awaiting_review; non espone qui una distribuzione automatica del parser.
Eseguire e verificare un audit
- Seleziona tenant e attività Audit parser.
- Scegli Source family e Lookback in base ai log da esaminare; per verificare una nuova versione del parser usa una finestra che contenga dati acquisiti con quella versione.
- Premi New audit, apri la run e attendi l'esito.
- Confronta scope richiesto, scope effettivo e Finding di audit. Se il report è parziale o richiede più dati, correggi la finestra o risolvi la copertura prima di creare un candidato.
- Quando disponibile, usa Create parser candidate e controlla artefatto, evidenze, impatto e rischio. Un candidato generato non è un parser distribuito.
- Se occorre una diagnosi esterna, esporta i dati della run e anonimizzali prima della condivisione. Conserva ID run, famiglia, finestra ed esito per riprodurre il controllo.
Errori ricorrenti
- Tenant non selezionato: scegli un tenant prima di creare una run; il contesto aggregato non basta per queste operazioni.
- Candidato non azionabile: verifica stato, eventuale sostituzione e collegamento alla bozza/run figlia già creata.
- JSON non valido: correggi la sintassi prima di salvare. Il superamento del parser JSON non sostituisce la validazione semantica server della proposta.
- Servono altri dati: controlla finestra, sorgente e copertura; ripetere immediatamente con lo stesso input non aggiunge evidenze.
- Run fallita: conserva ID run, fase e categoria errore. Distingui il fallimento del modello dall'eventuale fase di applicazione.
Verifica sorgente: workspace Agents ed Executions, trasformazioni dei form e controlli di azionabilità; snapshot del 10 novembre 2026.