L'autorizzazione utenti di Databricks Apps è ora GA, ma i confini dell'identità restano importanti
Databricks ha reso generalmente disponibile l'autorizzazione utenti di Databricks Apps il 7 ottobre, dopo oltre 18 mesi di anteprima pubblica. La funzionalità consente a un'applicazione di chiamare servizi della piattaforma supportati utilizzando l'identità dell'utente che ha effettuato l'accesso. Questo modifica una decisione di sicurezza centrale per le applicazioni dati e gli agenti AI: quali autorizzazioni regolano ogni richiesta?
Finora, gli sviluppatori hanno spesso fatto affidamento sul service principal di un'applicazione, un'identità non umana assegnata a una singola istanza dell'app. Ogni utente poteva ricevere risultati tramite quell'identità condivisa, a meno che gli sviluppatori non ricreassero nell'applicazione regole di accesso a livello utente. Il nuovo modello consente alle policy esistenti di Unity Catalog di seguire un utente nella richiesta a un'app.
Questa promessa comporta un'importante precisazione. L'autorizzazione on-behalf-of-user, o OBO, non rende un'applicazione sicura per impostazione predefinita. Gli sviluppatori devono separare le azioni avviate dagli utenti dal lavoro in background, richiedere ambiti ristretti, proteggere i token inoltrati e rifiutare le richieste quando manca l'identità prevista.
L'annuncio colloca Databricks in una più ampia competizione tra autorizzazione gestita dalla piattaforma e logica delle autorizzazioni gestita dall'applicazione. Microsoft supporta l'identità delegata tramite il proprio flusso OBO, mentre altre piattaforme cloud offrono componenti distinti per identità e policy. Databricks collega direttamente questo modello a dati aziendali governati, SQL warehouse, agenti e applicazioni in esecuzione sulla propria piattaforma.
L'autorizzazione utenti di Databricks Apps cambia chi governa ogni richiesta
La versione GA offre agli sviluppatori un modo supportato per preservare le autorizzazioni dati esistenti di un utente lungo l'intera richiesta dell'applicazione.
Databricks Apps ospita applicazioni dati, strumenti operativi, dashboard e agenti personalizzati su infrastruttura serverless. Ogni app distribuita riceve un service principal dedicato che può accedere alle risorse concesse a quell'applicazione. Questa autorizzazione dell'app resta disponibile e continua a essere adatta alle operazioni condivise o automatizzate.
L'autorizzazione utenti aggiunge un secondo percorso di identità. Quando una persona autenticata avvia un'azione supportata, Databricks inoltra un token di accesso al runtime dell'applicazione. L'app può quindi chiamare un'API Databricks approvata con l'identità e le autorizzazioni di quella persona.
Il modello di autorizzazione della piattaforma usa OAuth 2.0, il protocollo standard per l'accesso delegato. Distingue l'autorizzazione utente-macchina dall'autorizzazione macchina-macchina. La prima rappresenta un utente interattivo, mentre la seconda rappresenta un'applicazione o un carico di lavoro automatizzato.
Unity Catalog valuta quindi le autorizzazioni esistenti dell'utente quando l'app accede a dati governati. I filtri di riga possono limitare i record visualizzati, mentre le maschere di colonna possono nascondere o trasformare campi sensibili. Le autorizzazioni del warehouse determinano inoltre se l'utente può eseguire la query richiesta.
Il risultato dipende dalla persona che effettua la richiesta. Un responsabile vendite regionale potrebbe ricevere dati per un solo territorio, mentre un dirigente nazionale vede tutte le regioni. Entrambe le persone possono utilizzare la stessa applicazione e lo stesso percorso di richiesta senza ricevere un accesso identico.
Questo comportamento è importante perché l'app non necessita di una copia separata di ogni regola di governance. Quando un amministratore modifica una policy di Unity Catalog, le richieste successive dell'app vengono valutate rispetto alla policy aggiornata. Gli sviluppatori evitano di mantenere un sistema di autorizzazione parallelo che può divergere dai controlli della piattaforma.
Databricks ha introdotto per la prima volta l'autorizzazione OBO per Apps in anteprima pubblica il 26 marzo 2025. La versione di anteprima copriva risorse quali tabelle Unity Catalog ed endpoint di model serving. La disponibilità generale segnala che Databricks ora considera il modello pronto per l'adozione in produzione entro i limiti documentati.
La GA non elimina l'autorizzazione dell'app. Databricks presenta esplicitamente i due modelli come complementari. Un'applicazione può utilizzare la propria identità per configurazione condivisa, telemetria o manutenzione ordinaria, quindi usare l'identità della persona corrente per una query governata.
Si consideri un assistente per analisi delle vendite che risponde a domande sulle prestazioni degli account. La sua identità dell'app potrebbe leggere configurazioni comuni e registrare metriche operative. Il percorso dell'identità utente interrogherebbe i record di clienti e vendite disponibili per il dipendente richiedente.
Questa divisione è il fondamento della release. L'app conserva un'identità, ma tale identità non deve più diventare un gateway universale per ogni azione interattiva. Gli sviluppatori possono decidere quale principal governa ciascuna operazione.
Il cambiamento riguarda quindi più del semplice accesso. L'autenticazione stabilisce chi è presente, mentre l'autorizzazione determina cosa può fare quell'identità. L'autorizzazione utenti di Databricks Apps porta la seconda decisione nelle chiamate a valle verso dati e servizi.
La vera pressione ricade sul controllo degli accessi gestito dall'applicazione
Databricks mette in discussione la pratica di ricostruire le autorizzazioni sui dati aziendali all'interno di ogni applicazione.
Un'app che utilizza solo un service principal condiviso spesso vede un unico insieme coerente di autorizzazioni. Gli sviluppatori devono quindi decidere quali risultati ogni dipendente può ricevere. Ciò richiede di solito ruoli personalizzati, mappature di policy, logica di filtraggio o un altro servizio di autorizzazione.
Questi controlli possono funzionare, ma introducono una seconda fonte di verità. Un team di governance potrebbe aggiornare una concessione in Unity Catalog mentre la mappatura dei ruoli locali dell'applicazione rimane invariata. La discrepanza risultante può esporre informazioni o negare un accesso legittimo.
L'autorizzazione utenti riduce tale duplicazione per le risorse Databricks supportate. Le autorizzazioni consolidate della persona richiedente diventano parte del contesto di esecuzione. Il codice dell'applicazione può concentrarsi sull'attività richiesta mentre la piattaforma valuta l'accesso governato.
Questo è sempre più importante per gli agenti AI. Una dashboard convenzionale espone viste e query predefinite. Un agente può interpretare linguaggio aperto, scegliere strumenti, assemblare query e recuperare informazioni attraverso diversi passaggi.
Questa flessibilità amplia il numero di percorsi attraverso cui è possibile raggiungere dati protetti. Uno sviluppatore non può prevedere in modo affidabile ogni domanda che un dipendente potrebbe porre. Preservare il contesto di autorizzazione del dipendente offre alla piattaforma a valle un ulteriore confine di applicazione delle policy.
La pressione è particolarmente evidente quando le organizzazioni portano i prototipi in produzione. Le prime dimostrazioni funzionano spesso con una credenziale di sviluppatore o un account di servizio con autorizzazioni ampie. Questa scorciatoia diventa difficile da difendere quando un'app raggiunge dipendenti con ruoli, territori e requisiti di riservatezza differenti.
Una singola applicazione può servire vendite, finanza, operazioni e dirigenti. Questi gruppi non dovrebbero ereditare automaticamente la stessa visualizzazione di dettagli sui clienti, previsioni o informazioni sui dipendenti. Le policy centrali acquistano maggiore valore man mano che il pubblico si espande.
Databricks sta inoltre riducendo l'attrito tra amministratori della governance e team applicativi. I team di sicurezza possono continuare a gestire i privilegi sui dati tramite Unity Catalog. Gli sviluppatori non devono tradurre ogni policy in middleware specifico del framework.
Ciò non elimina il lavoro di sviluppo. I team devono comunque decidere se una particolare operazione appartiene all'utente o all'app. Devono inoltre capire quali API Databricks supportano OBO e quali ambiti di autorizzazione richiede ciascuna azione.
Le piattaforme alternative non sono prive di identità delegata. Il flusso OBO di Microsoft trasferisce l'identità di un utente e le autorizzazioni delegate da un'API a monte a un'API a valle. Google Cloud fornisce accesso alle applicazioni basato sull'identità, mentre AWS offre componenti di autorizzazione granulari per applicazioni personalizzate.
Databricks si differenzia attraverso l'integrazione con il proprio ambiente di data governance. La decisione di autorizzazione è collegata alle autorizzazioni di Unity Catalog, all'accesso SQL e ai servizi della piattaforma supportati. Questo può ridurre il lavoro di integrazione per applicazioni i cui dati risiedono già in Databricks.
Il compromesso è una maggiore dipendenza dalla piattaforma. Le applicazioni costruite attorno alle regole di Unity Catalog e agli ambiti specifici di Databricks ereditano controlli utili, ma diventano anche strettamente allineate al modello di identità di una sola piattaforma. I team multicloud potrebbero comunque aver bisogno di un altro livello di autorizzazione per le risorse esterne a Databricks.
Per gli acquirenti aziendali, la domanda quindi non è se l'identità delegata esista altrove. È se Databricks possa rendere lo sviluppo di applicazioni governate abbastanza più semplice da mantenere più dati e carichi di lavoro AI all'interno della propria piattaforma.
Come l'autorizzazione on-behalf-of-user crea due confini delle autorizzazioni
Una richiesta OBO ha successo solo entro le autorizzazioni sia dell'utente sia dell'ambito API approvato dell'applicazione.
Il primo confine riguarda dati e risorse. Un utente non può raggiungere una tabella Unity Catalog, un SQL warehouse o un servizio supportato semplicemente perché un'app lo richiede. La persona deve già disporre delle autorizzazioni necessarie.
Il secondo confine riguarda l'applicazione. Gli sviluppatori dichiarano ambiti API che definiscono le classi di operazioni che un'app può eseguire per un utente. Un ambito non concede alla persona un nuovo accesso ai dati, ma limita il modo in cui l'applicazione può esercitare l'accesso esistente.
Per l'analisi SQL in sola lettura, Databricks documenta un ambito sql:restricted-query. L'app può inviare query limitate come utente corrente senza ricevere ampia autorità per gestire warehouse o svolgere attività amministrative non correlate.
Questi confini intersecati supportano il principio del privilegio minimo, la pratica di concedere solo l'accesso richiesto per una specifica attività. Un utente con privilegi elevati potrebbe raggiungere direttamente molti dataset. Un'app con ambiti ristretti dovrebbe comunque non essere in grado di esercitare ogni privilegio posseduto da quell'utente.
Gli amministratori del workspace controllano un ulteriore limite superiore. Possono determinare quali ambiti di autorizzazione utenti gli sviluppatori possono aggiungere alle app nel workspace. La allowlist può includere tutte le API supportate, ambiti selezionati oppure nessuna autorizzazione utenti.
Questa struttura divide la responsabilità. Lo sviluppatore richiede le capacità minime necessarie al prodotto. L'amministratore decide quali capacità gli sviluppatori di applicazioni possono richiedere nel workspace.
Tuttavia, un amministratore non può fare affidamento solo sulla configurazione. Databricks afferma che gli amministratori dell'account possono aggiungere ambiti anche quando una allowlist del workspace li esclude. Le app esistenti possono inoltre continuare a funzionare dopo la rimozione di un ambito consentito.
Secondo l'annuncio, un'app interessata non può successivamente avviarsi, essere distribuita o aggiornata finché l'ambito non consentito non viene rimosso. Questo comportamento evita un'interruzione immediata, ma crea un periodo in cui l'esecuzione corrente e la policy corrente non coincidono pienamente.
I team dovrebbero quindi trattare le modifiche agli ambiti come eventi operativi governati. Gli amministratori hanno bisogno di un inventario delle app distribuite, degli ambiti richiesti, dei responsabili e delle dipendenze aziendali. Rimuovere una capacità senza questo contesto può ritardare la correzione o bloccare un'applicazione durante la distribuzione successiva.
Anche il codice dell'applicazione deve mantenere separate le due identità. Un client con ambito utente dovrebbe gestire operazioni interattive governate. Un client con ambito app dovrebbe gestire configurazione condivisa, metriche e lavoro che deve continuare senza una sessione utente.
Questa è più di una preferenza di denominazione. Un client generico può nascondere quale identità stia eseguendo un percorso sensibile. Dipendenze, test e gestori delle richieste separati rendono più semplice rilevare un uso involontario delle credenziali.
La regola più rigorosa riguarda i token utente mancanti. Se una route richiede l'autorizzazione dell'utente ma non è presente alcun token inoltrato, l'applicazione dovrebbe fallire in modo sicuro. Dovrebbe rifiutare la richiesta invece di passare silenziosamente al proprio service principal.
Un fallback potrebbe produrre una risposta tecnicamente valida con autorizzazioni del tutto diverse. L'utente avrebbe poche ragioni per sospettare che l'app abbia effettuato l'accesso a informazioni più ampie o più ristrette del previsto. Questo rende particolarmente pericolosi i cambiamenti silenziosi di identità.
Il token inoltrato dovrebbe esistere soltanto per la richiesta attiva. Databricks consiglia agli sviluppatori di non stamparlo, registrarlo nei log o conservarlo mai. I job in background dovrebbero usare l'autorizzazione dell'app invece di trattenere il token di un utente dopo la fine della sessione interattiva.
Per i team che sviluppano strumenti di AI interni, questa separazione delle identità si affianca ad altri controlli ingegneristici. Una base di conoscenza tecnica consultabile può conservare decisioni di autorizzazione, modelli di minaccia e prove di revisione accanto alla documentazione di implementazione.
Gli agenti AI rendono più difficile mantenere il confine tra le identità
Gli agenti traggono vantaggio dai permessi specifici per utente, ma il loro comportamento in più passaggi rende gli errori di identità più rilevanti.
Databricks afferma che gli agenti personalizzati distribuiti tramite Apps possono usare lo stesso modello di autorizzazione. Il client workspace con ambito utente deve essere inizializzato all'interno del gestore invoke o stream attivo. Il token inoltrato è disponibile soltanto durante l'esecuzione della richiesta.
Questo vincolo temporale impedisce agli sviluppatori di trattare l'identità utente come stato globale dell'applicazione. Un processo agente può servire molte persone e l'avvio dell'applicazione non appartiene a un singolo utente. Creare un client con ambito utente troppo presto rischia di perdere o mescolare il contesto della richiesta.
I flussi di lavoro degli agenti combinano inoltre diversi tipi di attività. Un passaggio potrebbe recuperare istruzioni condivise tramite l'identità dell'app. Un altro potrebbe interrogare dati finanziari soggetti a governance come utente. Un terzo potrebbe scrivere telemetria generale senza trattenere la credenziale dell'utente.
Ogni transizione comporta una decisione di autorizzazione. Gli sviluppatori devono identificare il principal, l'ambito, la risorsa e la modalità di errore prevista per ogni chiamata a uno strumento. Un singolo client agente generico può rendere sfumate queste distinzioni.
La sfida cresce quando un agente chiama un altro servizio. OBO può preservare il contesto dell'utente soltanto quando l'integrazione downstream supporta quel modello. Le API esterne possono richiedere credenziali, consenso, ambiti e controlli di audit separati.
L'agente non deve presumere che l'autorizzazione venga trasferita automaticamente lungo l'intera catena di strumenti. Un token viene emesso per un pubblico e uno scopo specifici. Le linee guida OBO di Microsoft mettono analogamente in guardia dal ritrasmettere token di livello intermedio a destinatari non previsti.
Ciò significa che l'autorizzazione utente non dovrebbe essere descritta come impersonificazione generalizzata. L'applicazione agisce per conto dell'utente soltanto entro gli ambiti configurati e i percorsi di richiesta supportati. Questa formulazione è importante perché "agire come l'utente" potrebbe altrimenti suggerire un accesso senza restrizioni.
Il prompt injection offre un ulteriore motivo di cautela. Un aggressore potrebbe inserire istruzioni nel contenuto recuperato da un agente, incoraggiandolo a chiamare strumenti o divulgare informazioni. OBO limita i dati accessibili all'utente corrente, ma non stabilisce se un'azione richiesta sia sensata.
Anche i permessi dell'utente stesso possono essere estesi. Un dirigente, amministratore o analista potrebbe avere accesso a dataset sensibili in molte funzioni aziendali. Un'app compromessa che utilizza l'identità valida di quella persona rappresenta comunque un rischio serio.
Gli ambiti forniscono un importante secondo confine in questa situazione. Un ambito di interrogazione in sola lettura può impedire attività amministrative non correlate, ma non può decidere se ogni query consentita risponda all'intenzione dell'utente. Le applicazioni necessitano comunque di gestione degli input, vincoli sugli strumenti, controlli sugli output e monitoraggio.
Anche il consenso merita attenzione. Gli utenti possono approvare le autorizzazioni richieste senza comprendere come un agente combinerà i servizi o elaborerà i risultati. Nomi di ambito chiari aiutano, ma il consenso non sostituisce la revisione amministrativa e un comportamento applicativo vincolato.
La verificabilità tramite audit diventa essenziale. I team di sicurezza devono distinguere le azioni eseguite dall'identità dell'app da quelle eseguite per conto di una persona. I log dovrebbero identificare il principal e l'operazione pertinenti senza registrare token bearer o contenuti sensibili delle risposte.
I test devono coinvolgere utenti con autorizzazioni differenti. Un test svolto soltanto con un account amministratore può nascondere errori, perché tale account incontra raramente dinieghi di accesso. Databricks consiglia di ripetere i test dopo le modifiche alle policy di governance.
Casi di test utili includono un utente con accesso regionale, un utente con accesso più ampio e una persona che non dispone affatto della tabella interrogata. I team dovrebbero verificare sia i dati restituiti sia il comportamento di rifiuto. Dovrebbero inoltre confermare che i token mancanti non attivino mai un fallback all'identità dell'app.
La limitazione centrale è quindi chiara. L'autorizzazione utente di Databricks Apps può applicare i permessi di piattaforma esistenti, ma non può correggere concessioni eccessivamente ampie. Le organizzazioni devono comunque mantenere accurati gruppi, privilegi del catalogo, accesso ai warehouse, filtri a livello di riga e maschere di colonna.
La promessa di sicurezza dipende dalla disciplina operativa
La parte più solida del progetto è il modello di controllo a livelli, mentre la parte più debole resta l'implementazione e la governance che lo circondano.
Databricks può inoltrare l'identità appropriata e applicare gli ambiti dichiarati. Non può garantire che ogni team di sviluppo assegni l'identità corretta a ogni percorso di codice. Tale decisione rimane nell'architettura dell'applicazione.
Un team potrebbe usare correttamente OBO per una query SQL ma impiegare accidentalmente l'identità dell'app per una richiesta di file correlata. L'interfaccia utente potrebbe combinare entrambe le risposte senza rivelare i diversi contesti di autorizzazione.
L'elaborazione in background rappresenta un altro confine. Un utente potrebbe avviare un'attività di lunga durata che prosegue dopo la fine della richiesta. Poiché il token inoltrato appartiene a una richiesta attiva, gli sviluppatori non possono semplicemente conservarlo per l'esecuzione successiva.
Il progetto più sicuro consiste nello stabilire se il lavoro differito appartenga all'applicazione o richieda un altro modello delegato supportato. Se appartiene all'app, il service principal deve disporre di autorizzazioni accuratamente limitate. Se richiede il contesto utente, gli sviluppatori devono seguire il comportamento documentato della piattaforma invece di trattenere il token.
Anche la disponibilità nei vari ambienti richiede conferma. La documentazione Databricks cambia con l'espansione dei servizi e delle configurazioni di conformità. I team dovrebbero verificare il supporto per cloud, regione, workspace e profilo di sicurezza prima di considerare la disponibilità generale universale.
Le Apps non possono essere applicazioni pubbliche anonime. Databricks afferma che gli utenti devono autenticarsi e che i collaboratori esterni richiedono l'onboarding tramite federazione delle identità supportata. Ciò rende il modello più naturale per scenari di forza lavoro e partner con identità gestite.
La separazione tra permessi dell'app e autorizzazione ai dati può confondere i revisori. CAN USE e CAN MANAGE stabiliscono chi può eseguire o amministrare un'app. Non determinano quali tabelle o record una persona possa accedere tramite essa.
Una persona potrebbe disporre dell'autorizzazione a usare un'app ma non di quella per interrogare i suoi dati sottostanti. Tale richiesta dovrebbe fallire o restituire risultati limitati. Al contrario, l'accesso ai dati da solo non concede necessariamente il permesso di aprire l'applicazione.
I livelli di autorizzazione documentati richiedono pertanto revisioni separate dalle concessioni di Unity Catalog. Trattarli come un unico controllo può creare una falsa sicurezza durante gli audit.
Le allowlist degli ambiti amministrativi introducono un ulteriore compito di governance. Secondo l'annuncio, l'impostazione predefinita può includere tutte le API supportate. Le organizzazioni attente alla sicurezza dovrebbero decidere se tale impostazione predefinita sia coerente con il proprio modello di sviluppo prima di adottare ampiamente le applicazioni.
Restringere l'allowlist può ridurre il rischio, ma può anche bloccare prodotti legittimi. Il processo corretto combina una base vincolata con un percorso di eccezione documentato. In caso contrario, i team potrebbero cercare identità app più ampie per evitare restrizioni sugli ambiti.
Esiste anche una sfida di rilevamento. Un'app può richiedere soltanto ambiti approvati e tuttavia comportarsi in modo errato al loro interno. Il monitoraggio runtime dovrebbe esaminare pattern di query insoliti, dinieghi ripetuti, volumi di dati inattesi e cambiamenti nel comportamento dell'applicazione.
Attualmente nessun benchmark indipendente stabilisce quanto tempo di sviluppo faccia risparmiare la funzionalità o con quale efficacia le imprese evitino difetti nei permessi. L'annuncio GA spiega il meccanismo e le pratiche raccomandate, ma i risultati dell'adozione restano da dimostrare.
Databricks ha inoltre un incentivo a rendere il proprio livello di governance la base predefinita per applicazioni e agenti interni. Gli acquirenti dovrebbero valutare questo vantaggio strategico insieme a portabilità, impegno di integrazione e maturità dei propri sistemi di autorizzazione esistenti.
Il confronto pertinente non è una semplice gara Databricks contro Microsoft. Il modello di identità delegata di Microsoft è maturo e ampiamente applicabile alle API. Databricks sta confezionando un principio correlato attorno ai propri dati, calcolo, governance e runtime applicativo.
L'accesso basato sull'identità di Google si concentra sul controllo dell'accesso alle applicazioni ospitate e alle policy contestuali. AWS offre componenti di autorizzazione che gli sviluppatori possono combinare con provider di identità e risorse applicative. Ogni approccio assegna attività diverse alla piattaforma e al team applicativo.
Le organizzazioni dovrebbero confrontare dove risiedono le policy, quali risorse coprono, come le identità attraversano i confini tra servizi e come i dinieghi vengono mostrati agli utenti. Dovrebbero inoltre verificare se i record di audit colleghino chiaramente un'azione sia all'applicazione sia alla persona che l'ha avviata.
L'etichetta GA abbassa una barriera all'adozione, ma non risolve queste questioni architetturali. La funzionalità è più convincente quando la governance dei dati risiede già in Unity Catalog e l'applicazione chiama principalmente servizi Databricks supportati.
Tre segnali mostreranno se il rilascio GA mantiene le promesse
Il prossimo test è se le imprese riusciranno ad adottare applicazioni consapevoli dell'utente senza ampliare il rischio legato ai token, la complessità delle policy o il lock-in della piattaforma.
Il primo segnale è l'adozione in produzione tra agenti interni e applicazioni operative. Databricks ha descritto un chiaro scenario di analisi delle vendite, ma le distribuzioni reali coinvolgeranno combinazioni più complesse di SQL, modelli, file, dashboard e servizi esterni.
Le prove di un'adozione matura includerebbero pattern architetturali ripetibili, implementazioni di riferimento e flussi di audit chiari. Includerebbero inoltre applicazioni che servono utenti con autorizzazioni significativamente differenti senza duplicare tali regole nel codice.
Un'adozione debole suggerirebbe che gli ambiti supportati, i servizi downstream o i processi organizzativi restano troppo limitati. I team potrebbero continuare a utilizzare service principal con permessi ampi o prodotti di autorizzazione separati nonostante l'opzione GA.
Il secondo segnale è l'espansione e il perfezionamento degli ambiti API supportati. Ambiti ristretti semplificano la progettazione secondo il principio del privilegio minimo, perché gli sviluppatori possono richiedere una capacità senza ricevere autorità non correlata.
Ambiti più ampi ma grossolani indebolirebbero il secondo confine delle autorizzazioni. Ambiti più granulari, migliori controlli amministrativi ed esperienze di consenso più chiare rafforzerebbero l'affermazione di Databricks secondo cui le app possono agire per gli utenti senza oltrepassare i limiti.
Anche le modifiche al supporto dei profili di conformità sono rilevanti. Databricks ha indicato che l'autorizzazione degli utenti avrebbe raggiunto i workspace con il profilo di sicurezza per la conformità alla fine di settembre 2026. I clienti dovrebbero confermare disponibilità e limitazioni nei propri ambienti.
Il terzo segnale riguarda il modo in cui i concorrenti integrano l'identità delegata nelle proprie piattaforme di agenti. Microsoft documenta già OBO per le API convenzionali e per gli scenari più recenti di agenti ospitati. Anche altre piattaforme stanno collegando l'identità utente, l'uso degli strumenti, i motori di policy e i runtime gestiti delle applicazioni.
Se queste alternative richiedono una notevole integrazione personalizzata, Databricks ottiene un vantaggio per le applicazioni costruite attorno a dati aziendali governati. Se i concorrenti offrono un'eredità delle policy altrettanto diretta tra dati e strumenti degli agenti, gli acquirenti si concentreranno maggiormente su portabilità e ampiezza dell'ecosistema.
Gli sviluppatori dovrebbero osservare le evidenze operative, anziché il linguaggio degli annunci. Incidenti nella gestione dei token, flussi di consenso confusi, proliferazione degli ambiti e bug nei fallback dell'identità indebolirebbero questa tesi. Audit chiari e una minore manutenzione delle autorizzazioni la sosterrebbero.
Il compito ingegneristico immediato è semplice da enunciare, anche se richiede disciplina nell'esecuzione. Mappate ogni operazione dell'applicazione all'identità dell'app o all'identità dell'utente corrente. Assegnate l'ambito più ristretto, rifiutate le credenziali mancanti e testate con utenti realmente diversi.
I team dovrebbero inoltre riesaminare i permessi esistenti di Unity Catalog prima di esporli tramite un agente. OBO applica fedelmente tali permessi, compresi quelli già più ampi del previsto. La delega non può migliorare una policy di origine debole.
L'autorizzazione utente di Databricks Apps è quindi significativa perché avvicina la governance consapevole dell'identità ai dati e al runtime applicativo. Sostituisce parte della logica delle autorizzazioni duplicata con l'applicazione delle policy da parte della piattaforma, preservando al contempo un'identità dell'app per il lavoro condiviso.
Il suo successo dipenderà dal fatto che gli sviluppatori mantengano questo confine quando le applicazioni diventano complesse. Prima di distribuire il prossimo assistente interno, ponetevi una domanda per ogni percorso di richiesta: questa operazione deve essere eseguita come applicazione o come persona che la utilizza?
