Come ho sviluppato valutazioni di sicurezza basate su agenti su Databricks

Avevamo già automatizzato alcune parti del nostro processo di revisione della sicurezza. Era utile, ma non riduceva abbastanza il lavoro manuale.

Continuavo a notare lo stesso pattern nella coda: un'integrazione di routine che utilizzava un design familiare poteva trovarsi accanto a un'architettura davvero inedita e ad alto rischio, entrambe in attesa della stessa risorsa limitata, ovvero un revisore esperto.

Il problema non era il fallimento della nostra automazione esistente. Aveva semplicemente raggiunto i suoi limiti. Continuavamo a dedicare il tempo degli esperti a un lavoro prevedibile, lasciando meno spazio alle decisioni che richiedevano davvero un giudizio specialistico.

Così ho creato un livello basato su agenti per estendere ciò che già avevamo. L'obiettivo non era sostituire il processo o le persone che lo gestivano, ma aiutare il sistema a comprendere una richiesta, applicare i nostri standard, richiedere le informazioni mancanti e riconoscere quando era necessario l'intervento di una persona.

La prima versione basata su agenti si concentrava su un unico percorso di revisione. Il mio team ha colto il pattern più ampio e lo ha esteso a un insieme di agenti che ora supportano altre parti del nostro processo di ricezione e revisione della sicurezza. Ho sviluppato quella prima versione interamente su Databricks, la stessa piattaforma utilizzata dai nostri clienti.

Perché la piattaforma è stata fondamentale

Ho potuto muovermi rapidamente perché i componenti principali erano già disponibili in un unico ambiente.

Unity Catalog ha fornito uno spazio governato per i nostri standard di sicurezza, i dati delle richieste, le prove di supporto, le decisioni e gli output del sistema. I modelli di base ospitati su Databricks hanno fornito il livello di modello per la classificazione e il ragionamento. Lakeflow Jobs ha orchestrato i flussi di lavoro basati su notebook su calcolo serverless. Databricks Apps ha offerto l'esperienza di ricezione e la dashboard esecutiva.

Come si integrano i vari elementi

A livello generale, una richiesta fluisce attraverso la piattaforma in un unico percorso continuo, in cui ogni passaggio legge e scrive sulle stesse tabelle governate:

1. Ricezione - Un'app conversazionale basata su Databricks Apps trasforma una descrizione in linguaggio naturale in una richiesta strutturata e allega gli eventuali documenti di progettazione di supporto.
2. Ragionamento - I modelli di base ospitati su Databricks (Claude Haiku, Sonnet e Opus) classificano la richiesta, valutano il rischio e redigono i requisiti, sempre basandosi sui nostri standard di sicurezza. Haiku gestisce la classificazione leggera, Sonnet si occupa della maggior parte del lavoro di revisione e Opus è riservato al ragionamento più complesso.
3. Orchestrazione - Lakeflow Jobs esegue gli agenti di revisione su calcolo serverless, spostando ogni richiesta attraverso le varie fasi secondo una pianificazione.
4. Sistema di registrazione - Unity Catalog conserva gli standard, i dati delle richieste, le prove, gli output dei modelli e le decisioni sotto forma di tabelle governate, con un unico modello di autorizzazione e lineage per tutti gli elementi.
5. Osservabilità - Una seconda Databricks App legge le stesse tabelle per generare report su volumi, tipologie di rischio, tasso di automazione e tempo risparmiato.

Questo ci ha fornito un modello operativo e di governance coerente per dati, modelli, flussi di lavoro e applicazioni. Invece di assemblare servizi separati con autorizzazioni, log e percorsi di dati differenti, ho potuto concentrarmi sulla logica di revisione e sull'esperienza utente.

La differenza pratica è stata la velocità. Ho ottenuto un sistema funzionante in meno di due ore. Fare la stessa cosa collegando servizi separati avrebbe richiesto settimane.

Non tutte le revisioni richiedono lo stesso percorso

La maggior parte delle code di sicurezza contiene sia richieste prevedibili che vere e proprie eccezioni.

Un'integrazione che utilizza un pattern di autenticazione approvato e non gestisce dati sensibili non comporta la stessa decisione di un servizio esposto a Internet che elabora informazioni sensibili con un ampio accesso amministrativo. Eppure, una coda tradizionale può indirizzare entrambi attraverso lo stesso percorso manuale.

Non miravo ad automatizzare ogni singola revisione. Ho automatizzato le parti ripetibili e preservato il giudizio umano laddove il rischio o l'incertezza erano maggiori.

Questo ha portato a una regola semplice: automazione per i casi ben compresi che rientrano in criteri espliciti; intervento umano per decisioni inedite, ad alto rischio o ambigue.

Un punto di accesso migliore

La qualità della revisione dipende dalle informazioni disponibili all'inizio.

I moduli statici presuppongono che i richiedenti sappiano di quale revisione hanno bisogno, comprendano la terminologia di sicurezza e prevedano le prove che un revisore richiederà. Quando ciò non accade, la richiesta arriva incompleta e la revisione inizia con un'altra serie di domande.

Ho creato un'applicazione di ricezione conversazionale con Databricks Apps. Il richiedente descrive ciò che sta cercando di fare in linguaggio naturale. L'applicazione identifica il percorso di revisione più probabile, pone domande di follow-up basate sul contesto e può utilizzare un documento di progettazione integrato come contesto di supporto. Evidenzia le informazioni mancanti e fornisce un'indicazione preliminare del rischio prima che venga creata una richiesta formale.

Una volta ottenuto un contesto sufficiente, crea una richiesta strutturata per il team di sicurezza.

L'applicazione dispone anche di una modalità di consultazione basata sui nostri standard di sicurezza. Non tutte le domande devono trasformarsi in un ticket. I team possono ricevere indicazioni mentre stanno ancora definendo un progetto e aprire una revisione formale solo quando è effettivamente necessario.

Questa è diventata una delle parti più utili del sistema. Consente alle persone di fare progressi più rapidamente, invece di considerare la coda come l'unico modo per interfacciarsi con la sicurezza.

Come funzionano gli agenti

Dietro l'applicazione di ricezione c'è un insieme di agenti specializzati implementati in Databricks Notebooks e orchestrati con Lakeflow Jobs.

Ho evitato deliberatamente di creare un unico agente con un'ampia autorità per agire come revisore della sicurezza. Ogni agente ha una responsabilità limitata: raccogliere il contesto, valutare il rischio, mappare la richiesta rispetto agli standard pertinenti, redigere i requisiti, gestire i follow-up o preparare il passaggio di consegne a una persona.

Sette agenti specializzati, ciascuno con un unico compito

Si tratta di un insieme di agenti specializzati (non un unico agente generico e nemmeno un singolo script), ciascuno con un compito ben definito, orchestrati come processi pianificati dietro l'applicazione di ricezione:

• Agente di ricezione - Gestisce il punto di accesso conversazionale: identifica il percorso di revisione, pone domande basate sul contesto e assembla una richiesta strutturata.
• Agente di valutazione del rischio - Assegna un livello di rischio con le relative prove di supporto e, per impostazione predefinita, passa a un livello superiore quando il quadro è incompleto.
• Agente dei requisiti - Mappa una richiesta rispetto agli standard pertinenti e redige requisiti specifici per l'implementazione nei casi ben compresi.
• Agenti di revisione specializzati - Gestiscono tipi di richieste che richiedono una logica dedicata, come la modellazione delle minacce delle estensioni del browser e la valutazione dei fornitori terzi.
• Agente di convalida - Crea una checklist di convalida elemento per elemento per le richieste a rischio più elevato prima della chiusura di qualsiasi attività.
• Agente del flusso di lavoro - Gestisce le attività di follow-up: chiarimenti, promemoria, tracciamento delle conferme e escalation a una persona.
• Agente di apprendimento - Confronta periodicamente le modifiche apportate dai revisori con l'output originale per individuare miglioramenti da apportare ai prompt e agli standard.

Ogni agente ha una responsabilità limitata, in modo che il suo comportamento rimanga ispezionabile e testabile, e una modifica a uno di essi non influisca silenziosamente su un altro.

Il sistema valuta innanzitutto il rischio della richiesta e registra le prove a supporto di tale valutazione. Un'etichetta di rischio da sola non è sufficiente.

Quando le informazioni sono mancanti o contraddittorie, il sistema richiede chiarimenti o indirizza la richiesta a un revisore. Non ricorre a deduzioni arbitrarie per concedere l'approvazione.

Per le richieste di routine, gli agenti generano requisiti basati sull'architettura effettiva e sugli standard applicabili, anziché restituire un modello generico. Il richiedente prende atto di tali requisiti e fornisce le prove necessarie. Le richieste idonee a basso e medio rischio possono essere completate tramite il percorso automatizzato una volta soddisfatti i criteri e le convalide definiti.

Un esempio

Prendiamo un caso comune: un'integrazione interna che utilizza un pattern di single-sign-on approvato e non gestisce dati sensibili. Invece di un modello generico, l'agente dei requisiti produce elementi specifici e verificabili legati a quell'architettura, ad esempio:

• Eseguire l'autenticazione tramite l'identity provider approvato e disabilitare qualsiasi credenziale locale o condivisa.
• Limitare l'integrazione agli ambiti di accesso (scope) minimi necessari e documentarli.
• Inviare i log dell'applicazione e degli accessi alla pipeline di logging centrale.
• Confermare il livello di classificazione dei dati ed eseguire una nuova revisione prima di introdurre dati sensibili.

Il richiedente prende atto di questi elementi e allega le prove. Se tutto risulta corretto e il caso soddisfa i criteri di idoneità, può essere completato tramite il percorso automatizzato.

Le richieste ad alto rischio, critiche, insolite o ambigue vengono indirizzate a una persona. A quel punto, il revisore riceve un riepilogo strutturato, le prove di supporto, gli standard applicabili e le eventuali questioni rimaste aperte.

Gli agenti gestiscono anche gran parte del lavoro amministrativo relativo a una revisione: raccolta dei dettagli mancanti, invio di promemoria, tracciamento delle conferme e escalation quando qualcuno chiede aiuto. Un revisore viene coinvolto quando una richiesta diventa ambigua o richiede una valutazione discrezionale.

L'automazione opera all'interno di regole da noi definite. Le persone mantengono il controllo sulle eccezioni e sulle decisioni consequenziali.

Rendere il sistema affidabile

La parte più difficile non è stata far produrre una risposta a un modello. È stata rendere tale risposta vincolata, verificabile e idonea all'azione.

Gli agenti sono ancorati ai nostri standard di sicurezza. Le valutazioni del rischio devono includere prove di supporto. La mancanza di contesto attiva un approfondimento o un'escalation, non un'ipotesi ottimistica. Il completamento automatico è limitato a classi di richiesta e criteri predefiniti. Il flusso di lavoro registra gli input, gli output, le prove e le decisioni associate a ciascuna richiesta.

Cosa significa questo all'atto pratico

Tre elementi rendono sicura l'applicazione di una decisione automatizzata:

• Classi di richiesta predefinite. Solo le categorie ben comprese e a basso rischio sono idonee per il completamento automatico, ad esempio un'integrazione interna di routine su un modello approvato che non gestisce dati sensibili. Qualsiasi elemento al di fuori di queste classi viene indirizzato a una persona per impostazione predefinita.
• Prove accettabili. Una decisione è valida solo quanto ciò che la supporta. Per prove si intendono elementi concreti e verificabili: un documento di progettazione collegato, un livello di classificazione dei dati dichiarato o configurazioni e riferimenti che dimostrano l'esistenza di un controllo approvato. Un'affermazione priva di prove viene trattata come informazione mancante.
• Una valutazione rifiutata o incerta. Quando le prove sono mancanti o contraddittorie, il sistema non tira a indovinare. Passa per impostazione predefinita alla fascia di rischio più prudente, pubblica una richiesta di chiarimento specifica o affida la richiesta a un revisore con le domande aperte allegate. Non arriva in alcun modo all'approvazione.

Il feedback dei revisori ci aiuta a identificare le lacune e a migliorare il sistema nel tempo. Utilizziamo queste correzioni per perfezionare i nostri standard, i prompt e la logica del flusso di lavoro, anziché consentire agli agenti di modificare autonomamente il comportamento in produzione.

Questi controlli contano più del modello stesso. Un modello forte può migliorare il ragionamento, ma la fiducia deriva dal sistema che lo circonda: un ambito chiaro, prove esplicite, un'escalation prudente e l'autorità umana che attribuisce al rischio un peso reale.

Dove lo ha portato il mio team

Ho creato la prima versione basata su agenti per migliorare un percorso di revisione. Il mio team ha capito che lo stesso modello poteva supportare molto di più.

Hanno esteso l'architettura ad altri tipi di richiesta, rafforzato i flussi di lavoro, migliorato il modo in cui gli agenti applicano i nostri standard e aggiunto i controlli necessari per l'uso quotidiano. Quello che era iniziato come un singolo flusso di lavoro basato su agenti è diventato un sistema condiviso che il team continua a sviluppare.

Io l'ho avviato, ma il sistema è diventato prezioso perché il team lo ha reso operativo e lo ha fatto proprio.

Come sviluppatore, sono orgoglioso che la prima versione abbia funzionato. Come leader, sono ancora più orgoglioso che il team abbia visto una base che valeva la pena estendere.

Misurare i risultati

Le affermazioni sull'efficienza sono facili da fare e difficili da credere senza prove.

Ho creato una dashboard direzionale come un'altra Databricks App. Legge dagli stessi dati di Unity Catalog prodotti dai flussi di lavoro di revisione e traccia il volume delle richieste, la distribuzione del rischio, il completamento automatico, l'escalation umana, il tempo di ciclo e il tempo stimato risparmiato dai revisori.

Poiché le metriche provengono da record operativi, possiamo risalire alle richieste e alle decisioni che le hanno generate, anziché riconciliare manualmente le esportazioni da sistemi separati.

Questo ha cambiato il dialogo con la leadership. Abbiamo potuto mostrare dove l'automazione ha ridotto lo sforzo manuale, dove i revisori sono rimasti coinvolti e come questo mix è cambiato nel tempo.

I numeri

La dashboard traccia un insieme coerente di misure, tutte derivate dagli stessi record operativi.

Cosa è cambiato

Le richieste di routine idonee che un tempo attendevano in coda per giorni ora possono essere completate in pochi minuti. I team possono ricevere indicazioni prima di aprire un ticket e le richieste che raggiungono un revisore arrivano con un contesto migliore.

I nostri ingegneri della sicurezza possono dedicare più tempo a progetti innovativi, rischi significativi e decisioni che richiedono esperienza. Anche il primo passaggio è più coerente perché le richieste vengono valutate in base agli stessi standard e requisiti di prova. Quando il sistema è incerto, attiva un'escalation.

Questa non è sicurezza senza persone. È un sistema progettato per impiegare l'attenzione degli esperti laddove ha il valore maggiore.

Cosa ho imparato da questa esperienza

Aggiungere revisori può aumentare la capacità, ma non elimina il lavoro ripetitivo.

Il primo passo consiste nel separare il processo dalla valutazione discrezionale. Automatizza i passaggi ripetibili solo quando i criteri sono espliciti, il sistema è ancorato a standard reali, sono richieste prove, l'incertezza viene gestita tramite escalation e i risultati possono essere misurati.

Non automatizzare una decisione semplicemente perché un modello può produrre una risposta. Automatizzala solo quando il processo definisce come si presenta una risposta accettabile, quali prove la supportano e cosa succede quando il sistema è incerto.

Mantieni le persone al controllo delle decisioni consequenziali e delle eccezioni.

La mia intenzione non era quella di escludere gli esseri umani dalla revisione della sicurezza. Volevo ridurre il tempo che dedicano a un lavoro che un sistema controllato può gestire in modo coerente. Sviluppare su Databricks ci ha fornito la base della piattaforma per farlo. Vedere il mio team prendere la prima versione, potenziarla e farla propria è stata la parte migliore.

Inizia con la guida multi-agente di Databricks, quindi adatta il modello di questo post (dati governati in Unity Catalog, agenti mirati su Lakeflow Jobs e una Databricks App come porta d'accesso) nel tuo flusso di lavoro di revisione ripetibile e basato su prove.

Crea un sistema multi-agente su Databricks Apps

Inizia con la guida multi-agente di Databricks, quindi adatta il modello di questo post (dati governati in Unity Catalog, agenti mirati su Lakeflow Jobs e una Databricks App come porta d'accesso) nel tuo flusso di lavoro di revisione ripetibile e basato su prove.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale