Databricks innocente finché la policy combinata non blocca il rischio degli agenti nel punto di combinazione

Databricks ha pubblicato un nuovo schema di sicurezza Omnigent che blocca un agente solo dopo che tre capacità, singolarmente ordinarie, formano una catena pericolosa. L’approccio Databricks innocent until combined prende di mira il momento in cui dati privati, contenuti non attendibili e comunicazioni esterne diventano disponibili nella stessa sessione.

Questa combinazione è nota come trifecta letale. Un agente può leggere in sicurezza un file interno, analizzare una pagina web pubblica o inviare un messaggio quando ciascuna azione avviene isolatamente. Riunendo tutte e tre le capacità in un unico percorso di esecuzione, un’istruzione iniettata può trasformare un accesso legittimo in furto di dati.

Il cambiamento importante non è un altro avvertimento sulla prompt injection. Databricks sta spostando la decisione di enforcement fuori dal modello e dentro Omnigent, il suo meta-harness open source per l’esecuzione e la governance degli agenti. Il livello di policy ricorda ciò che una sessione ha incontrato e modifica quindi il modo in cui tratta le azioni successive.

I permessi statici chiedono se un agente possa chiamare uno strumento. Le policy contestuali chiedono anche cosa sia avvenuto prima di quella chiamata. Questa differenza mette sotto pressione i team che usano un accesso ampio e persistente agli strumenti tramite coding agent, browser agent e integrazioni Model Context Protocol.

Cosa ha cambiato Databricks in Omnigent

Databricks considera la cronologia di un agente come parte del suo set effettivo di permessi.

Il case study sulla sicurezza dell’azienda amplia una serie di post sulle policy contestuali in Omnigent. Gli esempi precedenti si concentravano sullo stato della sessione, sugli attacchi a combustione lenta e sull’autorizzazione legata all’intento originale dell’utente.

L’ultimo esempio applica questo modello alla trifecta letale. Il ricercatore di sicurezza Simon Willison ha definito il pattern nel giugno 2025 come accesso a dati privati, esposizione a contenuti non attendibili e un canale di comunicazione esterno. Il suo modello di minaccia avverte che combinare tutti e tre offre alle istruzioni iniettate una via per sottrarre informazioni.

Omnigent si colloca sopra un agent harness, ovvero il runtime che gestisce il modello, gli strumenti e il ciclo di esecuzione. Il progetto supporta ambienti consolidati per coding agent e agenti personalizzati, consentendo a un livello di policy comune di osservarne l’attività.

Questa posizione è importante perché la policy non richiede che il modello sottostante riconosca ogni frase dannosa. Può governare l’uso degli strumenti in base ai fatti registrati durante la sessione.

Si consideri un agente incaricato di esaminare un documento interno di prodotto. La lettura di quel documento è prevista. Anche l’invio di un riepilogo approvato a un canale aziendale potrebbe esserlo.

Ora si supponga che l’agente visiti un issue pubblico, una pagina web o un repository contenente istruzioni nascoste. Una successiva richiesta in uscita assume un significato di sicurezza diverso perché la sessione ha attraversato un altro confine di fiducia.

Una allowlist convenzionale vede gli stessi strumenti approvati durante tutto il flusso di lavoro. Una policy contestuale vede una sequenza il cui rischio è cambiato nel tempo.

Le policy Omnigent possono restituire una decisione di allow, ask o deny. Allow consente l’azione, ask la inoltra a una persona e deny la blocca. La risposta può quindi diventare più restrittiva man mano che la sessione accumula accessi sensibili o eventi rischiosi.

Questo modello di enforcement non richiede che ogni fonte, strumento o azione sia pericoloso di per sé. La policy osserva invece le combinazioni che creano un percorso dati non sicuro.

Databricks offre inoltre Omnigent come beta gestita, connessa all’identità del workspace e ai servizi per modelli. Il suo deployment gestito supporta attualmente handler integrati per policy contestuali, mentre le funzioni di policy personalizzate arbitrarie rimangono indisponibili.

Questa limitazione separa il design open source dal prodotto gestito. I team che valutano l’annuncio devono distinguere tra un pattern di policy dimostrato e i controlli disponibili nel deployment scelto.

Resta comunque chiaro il cambiamento centrale. L’autorizzazione degli agenti sta diventando dipendente dalla sessione anziché fissa al login o alla registrazione dello strumento.

Perché Databricks innocent until combined cambia il confine di sicurezza

L’oggetto rischioso non è più una singola chiamata a uno strumento; è il percorso che collega più chiamate consentite.

Il controllo degli accessi tradizionale valuta identità, risorse e azioni. Un account di servizio può leggere un database, scrivere in un bucket o chiamare un’API. Queste regole restano necessarie perché gli agenti operano comunque tramite credenziali ordinarie.

Non sono sufficienti quando un linguaggio non attendibile influenza il modo in cui tali credenziali vengono utilizzate. Un attaccante potrebbe non dover mai rubare un token né sfruttare codice applicativo. Gli basta far arrivare contenuti dannosi a un modello che possa accedere ai dati e agire verso l’esterno.

Il primo elemento sono i dati privati. Questa categoria include documenti interni, codice sorgente, credenziali, record dei clienti, email, risultati di database e qualsiasi informazione al di fuori dell’autorizzazione dell’attaccante.

Il secondo elemento sono i contenuti non attendibili. Una pagina web, un ticket di supporto, una pull request, un’email, un file condiviso, una risposta di uno strumento o un’immagine possono contenere istruzioni controllate da qualcuno esterno al confine di fiducia dell’agente.

Il terzo elemento è la comunicazione esterna. Email e richieste HTTP sono esempi evidenti, ma la categoria è più ampia. Pubblicare un commento, effettuare push di codice, caricare una risorsa remota o scrivere in un sistema condiviso può creare un canale in uscita.

Nessuna di queste capacità è insolita. La loro utilità è proprio il motivo per cui la combinazione compare in così tanti progetti di agenti.

Un agente di ricerca ha bisogno di fonti esterne e contesto interno. Un coding agent può leggere un repository privato, consultare documentazione pubblica ed effettuare push di un branch. Un assistente email legge messaggi non attendibili, cerca nella corrispondenza privata e invia risposte.

Rimuovere permanentemente una qualsiasi capacità può rendere l’agente sensibilmente meno utile. Le richieste di approvazione costanti creano un problema diverso, perché gli utenti possono abituarsi ad accettare richieste di routine.

L’impostazione Databricks innocent until combined offre un’altra opzione. Consente alle operazioni a basso rischio di procedere, ma impone un’escalation quando lo stato della sessione completa una combinazione proibita.

Questo sposta il confine di sicurezza dal singolo connettore al flusso di lavoro. Un browser non è semplicemente attendibile o non attendibile. La sua rilevanza dipende dal fatto che la stessa sessione detenga anche informazioni sensibili e una via di uscita.

Questo modello richiama il controllo del flusso delle informazioni, in cui un sistema traccia il modo in cui i dati si muovono tra livelli di fiducia. Una volta che informazioni riservate entrano in un contesto, le scritture successive verso una destinazione meno protetta ricevono un trattamento più restrittivo.

Il catalogo delle policy pubblicato da Omnigent include già un controllo correlato per Google Drive. Dopo che una sessione legge un file dichiarato riservato, la policy può impedire scritture al di fuori dell’insieme riservato.

Il catalogo include anche una policy di punteggio del rischio. Accumula punti dalle chiamate agli strumenti e dalle etichette di dati sensibili, quindi intensifica i controlli sugli strumenti protetti dopo una soglia configurata.

Questi esempi mostrano perché lo stato è centrale. Una richiesta di scrittura non cambia la propria forma API dopo che l’agente ha letto un documento sensibile. Cambia il suo significato a causa della cronologia della sessione.

Lo stesso principio si applica alla trifecta letale. La policy cerca una composizione pericolosa, non un’operazione universalmente vietata.

Questa distinzione dovrebbe interessare i team di piattaforma più di un altro filtro per prompt. I filtri tentano di decidere se il testo sembri dannoso. L’enforcement contestuale può comunque bloccare un’azione non sicura quando il modello o il filtro non riesce a identificare l’iniezione.

I permessi statici perdono la sequenza

Una allowlist statica può descrivere le capacità disponibili, ma non può spiegare come l’agente sia arrivato a un’azione.

Si supponga che uno sviluppatore autorizzi un agente a leggere un repository privato, navigare nella documentazione e aprire pull request. Ogni permesso supporta un normale flusso di lavoro di sviluppo.

Un attaccante inserisce quindi un’istruzione in un issue, in un documento di dipendenza o in una pagina web recuperata. L’istruzione dice all’agente di raccogliere un segreto e includerlo nella descrizione di una pull request pubblica.

La lettura del repository è consentita. Il recupero web è consentito. L’apertura di una pull request è consentita. Un controllo che valuta ogni richiesta in modo indipendente può approvare l’intera catena.

Un filtro dei contenuti potrebbe rilevare l’istruzione. Potrebbe anche non cogliere una richiesta indiretta, dati codificati, una lingua poco familiare o un payload progettato attorno al modello bersaglio.

Le ricerche suggeriscono cautela nel fare affidamento esclusivamente sul comportamento del modello. Il benchmark WASP ha testato attacchi realistici di prompt injection contro sistemi di web agent che utilizzavano diversi modelli e scaffold.

I ricercatori hanno rilevato che gli agenti hanno iniziato a eseguire istruzioni avversarie tra il 16 e l’86 per cento delle volte nelle configurazioni testate. Il successo end-to-end degli attaccanti è stato inferiore, variando da zero al 17 per cento.

Questo divario è incoraggiante ma non rassicurante. Gli agenti attuali spesso falliscono prima di completare un attacco complesso, ma una maggiore affidabilità degli agenti può anche rendere più facili da portare a termine i flussi di lavoro dannosi.

Un sistema non dovrebbe contare sul fatto che un agente si confonda al momento giusto. Ha bisogno di un controllo che resti efficace man mano che i modelli migliorano nell’esecuzione in più passaggi.

I permessi statici faticano anche con gli attacchi ritardati. L’istruzione iniettata potrebbe non attivare un’azione immediata in uscita. Può influenzare un piano successivo, un’attività delegata, un file generato o una chiamata a uno strumento.

Una policy consapevole della sessione può mantenere fatti rilevanti per la sicurezza durante tale ritardo. Non richiede che ogni evento sospetto si trovi accanto all’azione finale nel contesto attivo del modello.

Questa persistenza affronta una debolezza pratica degli agenti a lunga esecuzione. La cronologia della conversazione può essere compressa, riassunta o suddivisa tra worker. Un modello potrebbe dimenticare un vincolo precedente mentre i suoi strumenti e le sue credenziali rimangono disponibili.

Lo stato della policy dovrebbe quindi risiedere fuori dalla finestra di testo. Il livello di enforcement necessita di un proprio resoconto durevole delle letture sensibili, degli input non attendibili, delle destinazioni, delle approvazioni e delle variazioni di rischio.

Questa architettura riduce inoltre la dipendenza dall’auto-segnalazione dell’agente. Chiedere al modello se abbia incontrato contenuti non attendibili è più debole rispetto a registrare quale connettore abbia fornito il contenuto.

I segnali più solidi provengono dall’infrastruttura. Un sistema documentale conosce la classificazione di un file. Un gateway di rete conosce la destinazione. Un livello di identità conosce l’utente e il workspace. Un tool broker conosce quale operazione sia stata richiesta.

Omnigent può combinare questi segnali perché avvolge l’ambiente di esecuzione. L’agente propone un’azione, ma la policy decide se quell’azione resti accettabile nel contesto registrato.

Questo è il punto di pressione per le piattaforme concorrenti di agenti. Le approvazioni a livello di strumento sono più facili da spiegare e implementare. Diventano meno credibili quando gli agenti eseguono sessioni più lunghe attraverso più connettori.

I vendor dovranno mostrare se i loro controlli seguono i dati e le transizioni di fiducia tra gli strumenti. Un lungo elenco di permessi non risponde più alla domanda centrale sulla sicurezza.

Le policy contestuali spezzano la catena prima che i dati escano

Il punto di controllo utile è la transizione che completa il percorso d’attacco, di solito una lettura sensibile o un’azione in uscita.

Una policy contestuale inizia con eventi osservabili. Questi possono includere l’invocazione di uno strumento, il risultato di uno strumento, un’etichetta dei dati, una destinazione, una richiesta al modello o un’approvazione dell’utente.

La policy memorizza fatti selezionati nello stato della sessione. Potrebbe registrare che l’agente ha elaborato contenuti non attendibili, ha avuto accesso a un oggetto riservato o ha tentato una comunicazione oltre un confine approvato.

Gli eventi successivi vengono valutati alla luce di quello stato. Se l’operazione seguente completa una combinazione vietata, la policy può richiedere un’approvazione o negare la richiesta.

L’ordine può variare. Un agente potrebbe leggere dati privati prima di visitare una pagina non attendibile. Potrebbe incontrare prima il contenuto iniettato e poi richiedere l’accesso a un file interno.

Un’implementazione solida deve rilevare entrambi i percorsi. Il pericolo deriva dalla connessione tra le capacità, non da un ordine fisso.

L’applicazione delle regole può avvenire anche in più punti. Una policy potrebbe bloccare la lettura sensibile dopo che contenuti non attendibili sono entrati nella sessione. Un altro approccio potrebbe consentire l’analisi ma impedire le successive comunicazioni esterne.

Bloccare l’egress spesso preserva una maggiore utilità locale. L’agente può continuare a leggere e redigere senza acquisire una via per esporre informazioni. Tuttavia, i controlli sull’egress devono coprire più delle evidenti funzioni di invio.

Un link generato può codificare dati. Una richiesta di immagine remota può trasmettere parametri di query. Un push nel controllo di versione, un commento a una issue, una chiamata di analytics o una scrittura in un documento condiviso possono oltrepassare il confine di fiducia.

Anche il contesto della destinazione è importante. Inviare un riepilogo a un canale interno approvato è diverso dal pubblicarlo in un repository pubblico. Trattare tutte le scritture allo stesso modo creerebbe interruzioni inutili.

L’approvazione umana è preziosa quando contesto e destinazione sono chiari. Un prompt utile dovrebbe spiegare che la sessione ha letto dati riservati, ha successivamente elaborato contenuti non attendibili e ora vuole contattare uno specifico endpoint esterno.

Un messaggio generico del tipo “consenti questo strumento” nasconde il motivo dell’escalation. Favorisce l’affaticamento da approvazioni perché il revisore deve ricostruire manualmente il flusso di lavoro.

Il rifiuto netto è adatto alle combinazioni che un’organizzazione non accetta mai. Ad esempio, una policy può impedire a qualsiasi sessione esposta a contenuti pubblici di inviare informazioni da un set di dati ristretto al di fuori del suo compartimento.

Il motore delle policy deve fallire in sicurezza quando manca il contesto richiesto. Un’etichetta dei dati assente, uno strumento non supportato o un percorso di rete non osservato possono creare un punto cieco.

L’approccio più ampio di Omnigent combina le policy con il sandboxing. Un sandbox limita l’accesso a filesystem e rete al confine del sistema operativo, riducendo ciò che un agente può raggiungere anche se il modello lo richiede.

Questi livelli hanno finalità diverse. Il sandbox limita la capacità grezza. La policy contestuale adatta i permessi in base allo stato accumulato della sessione.

Nessuno dei due sostituisce i normali controlli di identità, l’autorizzazione dei connettori, la registrazione delle attività o la prevenzione della perdita di dati. L’annuncio è più utile se interpretato come uno strato di enforcement all’interno di tale stack.

Il report sulla sicurezza agentica di OWASP identifica la prompt injection come una delle principali tecniche di attacco contro i sistemi di IA. Il suo messaggio più ampio è che la sicurezza degli agenti richiede controlli sull’esecuzione, sugli strumenti, sull’identità e sul movimento dei dati.

Ciò supporta la direzione architetturale di Databricks. Un modello probabilistico può suggerire un’azione, ma un confine deterministico dovrebbe decidere se l’azione è consentita.

Cosa non risolve la policy di Databricks

L’enforcement contestuale restringe il percorso d’attacco, ma la sua affidabilità dipende da una visibilità completa e da una classificazione affidabile.

La prima questione irrisolta è la copertura. Una policy non può bloccare un canale che non osserva.

Un agente può comunicare tramite un connettore, un comando shell, una richiesta del browser, una risorsa incorporata o un artefatto generato. Ogni percorso in grado di spostare dati oltre il confine deve essere rappresentato nel modello di policy o vincolato altrove.

La seconda questione è la classificazione. Il sistema deve sapere quali contenuti non sono attendibili e quali dati sono sensibili.

Regole semplici possono classificare le pagine web pubbliche come non attendibili e i documenti nominati come riservati. Gli ambienti enterprise presentano casi più complessi, inclusi drive condivisi, account di appaltatori, testo copiato, file generati e dati assemblati da diverse fonti a bassa sensibilità.

I falsi negativi lasciano inosservata la combinazione pericolosa. I falsi positivi interrompono il lavoro ordinario e possono abituare gli utenti ad approvare gli avvisi senza esaminarli.

La terza questione è l’ambito dello stato. Una sessione è un’unità pratica, ma le informazioni possono spostarsi tra sessioni attraverso file, archivi di memoria, cache, subagenti e riepiloghi copiati.

Se un worker legge dati riservati e un altro invia il risultato, il tracciamento per sessione potrebbe non rilevare il flusso combinato. I sistemi multi-agente necessitano di regole di propagazione che preservino le etichette pertinenti tra le deleghe.

La quarta questione è l’integrità della policy. Il livello di enforcement, la configurazione e il flusso di eventi diventano infrastruttura critica per la sicurezza. Gli attaccanti potrebbero prendere di mira lacune nelle policy, metadati degli strumenti malformati, destinazioni ambigue o comportamenti fail-open.

I team dovrebbero testare il vero confine della policy, non solo il modello. Le valutazioni avversariali devono includere percorsi alternativi di egress, azioni ritardate, trasferimenti tra agenti e metadati incompleti.

La quinta questione è l’usabilità. Un controllo che richiede approvazione troppo spesso può riprodurre la debolezza che era pensato per risolvere.

L’escalation basata sul rischio richiede soglie scelte con cura e prompt informativi. I team di sicurezza dovrebbero misurare frequenza delle approvazioni, accuratezza dei rifiuti, tassi di override e motivi per cui gli utenti accettano eccezioni.

La beta gestita di Omnigent introduce un altro vincolo pratico. Databricks documenta attualmente il supporto per handler integrati, non per codice di policy personalizzato arbitrario, nell’ambiente gestito.

Le organizzazioni con classificazioni specializzate o connettori proprietari dovrebbero verificare se le policy disponibili espongono un contesto sufficiente. La flessibilità open source non si traduce automaticamente nella parità con il servizio gestito.

Non vi sono inoltre ancora basi per considerare una singola dimostrazione una convalida universale. L’articolo di Databricks illustra un modello di sicurezza e un approccio implementativo. Non stabilisce che ogni configurazione di Omnigent blocchi ogni tecnica di prompt injection.

L’affermazione corretta è più circoscritta. L’enforcement consapevole della sessione può interrompere un percorso della trifecta letale anche quando ogni singolo strumento rimane legittimo.

Questo resta significativo. L’architettura di sicurezza spesso riesce rimuovendo una condizione necessaria da un attacco, non insegnando all’applicazione a riconoscere ogni messaggio dell’attaccante.

Le implementazioni più robuste combineranno la policy contestuale con credenziali limitate, allowlist delle destinazioni, sandboxing, log di audit e test indipendenti. Tratteranno inoltre le definizioni delle policy come codice di sicurezza versionato.

Tre segnali mostreranno se il modello regge

Il prossimo test consiste nel verificare se la policy contestuale diventa un’infrastruttura misurabile anziché una dimostrazione persuasiva.

Il primo segnale è una copertura più ampia tra strumenti e harness degli agenti. Databricks deve dimostrare che le etichette di sicurezza e lo stato della sessione sopravvivono ai flussi di lavoro comuni che coinvolgono browser, repository di codice, sistemi documentali, shell e agenti delegati.

Il supporto in un elenco di funzionalità non basta. I team hanno bisogno di prove che azioni equivalenti ricevano un enforcement equivalente tra diversi harness e implementazioni dei connettori.

Una copertura coerente rafforzerebbe la tesi di un meta-harness condiviso. Differenze sostanziali tra runtime indebolirebbero la promessa di un unico livello di governance tra gli agenti.

Il secondo segnale è la valutazione avversariale. Omnigent necessita di test ripetibili che tentino esfiltrazione ritardata, egress indiretto, trasferimento tra sessioni e manipolazione dei metadati.

Risultati utili dovrebbero distinguere tra rilevamento, approvazione, rifiuto e trasferimento riuscito dei dati. Dovrebbero inoltre riportare il completamento delle attività benigne, perché una policy che blocca ogni flusso di lavoro è sicura ma inutilizzabile.

Fixture di test pubbliche consentirebbero ai team di sicurezza di riprodurre i risultati sulla propria configurazione. Una valutazione indipendente avrebbe più peso di uno scenario selezionato dal fornitore.

Il terzo segnale è l’adozione operativa negli ambienti Databricks gestiti. Occorre osservare un supporto alle policy ampliato, telemetria più chiara, controlli amministrativi e integrazioni documentate con le classificazioni dei dati enterprise.

L’adozione dovrebbe produrre risultati misurabili. I team devono sapere quanto spesso le policy si attivano, quali combinazioni di capacità causano l’escalation e se i revisori annullano o approvano la decisione.

Questi segnali contano perché il problema di sicurezza sottostante crescerà con l’utilità degli agenti. Agenti migliori completeranno attività più lunghe, useranno più strumenti e attraverseranno più confini di fiducia senza supervisione costante.

L’approccio di Databricks, innocente finché non viene combinato, offre un principio di progettazione credibile: consentire componenti utili bloccando al contempo la composizione pericolosa. Sposta l’attenzione dal fatto che un modello comprenda un attacco al fatto che il sistema circostante consenta all’attacco di concludersi.

Gli sviluppatori dovrebbero mappare quali sessioni possono accedere a dati privati, acquisire contenuti controllati da un attaccante e comunicare esternamente. Gli acquirenti enterprise dovrebbero chiedere se una piattaforma traccia tali condizioni nel tempo, tra strumenti e worker delegati.

Se tutte e tre restano disponibili senza enforcement contestuale, una schermata di approvazione curata non risolve il problema. Il prossimo passo pratico è identificare dove la terza capacità entra in ogni flusso di lavoro, quindi collocare una policy testabile a quel confine.