L’autorisation des utilisateurs de Databricks Apps est désormais disponible en GA, mais les frontières d’identité restent essentielles

Databricks a rendu l’autorisation des utilisateurs de Databricks Apps généralement disponible le 7 octobre, après plus de 18 mois de préversion publique. Cette fonctionnalité permet à une application d’appeler des services de plateforme pris en charge en utilisant l’identité de l’utilisateur connecté. Elle modifie une décision de sécurité centrale pour les applications de données et les agents d’IA : quelles autorisations régissent chaque requête ?

Jusqu’à présent, les développeurs s’appuyaient souvent sur le principal de service d’une application, une identité non humaine attribuée à une instance d’application. Chaque utilisateur pouvait recevoir des résultats via cette identité partagée, sauf si les développeurs recréaient dans l’application des règles d’accès au niveau de l’utilisateur. Le nouveau modèle permet aux politiques Unity Catalog existantes d’accompagner un utilisateur dans une requête d’application.

Cette promesse s’accompagne d’une réserve importante. L’autorisation au nom de l’utilisateur, ou OBO, ne rend pas une application sûre par défaut. Les développeurs doivent séparer les actions déclenchées par l’utilisateur du travail en arrière-plan, demander des portées restreintes, protéger les jetons transmis et rejeter les requêtes lorsque l’identité attendue est absente.

Cette annonce place Databricks dans une concurrence plus large entre l’autorisation gérée par la plateforme et la logique d’autorisations gérée par l’application. Microsoft prend en charge l’identité déléguée via son propre flux OBO, tandis que d’autres plateformes cloud proposent des composants distincts d’identité et de politiques. Databricks relie directement ce modèle aux données d’entreprise gouvernées, aux entrepôts SQL, aux agents et aux applications exécutées sur sa plateforme.

L’autorisation des utilisateurs de Databricks Apps change l’identité qui régit chaque requête

La disponibilité générale offre aux développeurs un moyen pris en charge de préserver les autorisations de données existantes d’un utilisateur tout au long d’une requête d’application.

Databricks Apps héberge des applications de données, des outils opérationnels, des tableaux de bord et des agents personnalisés sur une infrastructure serverless. Chaque application déployée reçoit un principal de service dédié, qui peut accéder aux ressources accordées à cette application. Cette autorisation d’application reste disponible et convient toujours aux opérations partagées ou automatisées.

L’autorisation utilisateur ajoute un second chemin d’identité. Lorsqu’une personne connectée initie une action prise en charge, Databricks transmet un jeton d’accès à l’environnement d’exécution de l’application. L’application peut alors appeler une API Databricks approuvée sous l’identité et les autorisations de cette personne.

Le modèle d’autorisation de la plateforme utilise OAuth 2.0, le protocole standard d’accès délégué. Il distingue l’autorisation utilisateur-machine de l’autorisation machine-machine. La première représente un utilisateur interactif, tandis que la seconde représente une application ou une charge de travail automatisée.

Unity Catalog évalue ensuite les autorisations existantes de l’utilisateur lorsque l’application accède à des données gouvernées. Les filtres de lignes peuvent restreindre les enregistrements affichés, tandis que les masques de colonnes peuvent masquer ou transformer des champs sensibles. Les autorisations de l’entrepôt déterminent également si l’utilisateur peut exécuter la requête demandée.

Le résultat dépend de la personne à l’origine de la requête. Un responsable commercial régional peut recevoir les données d’un seul territoire, tandis qu’un dirigeant national voit toutes les régions. Les deux personnes peuvent utiliser la même application et le même chemin de requête sans recevoir un accès identique.

Ce comportement est important, car l’application n’a pas besoin d’une copie distincte de chaque règle de gouvernance. Lorsqu’un administrateur modifie une politique Unity Catalog, les requêtes ultérieures de l’application sont évaluées selon la politique mise à jour. Les développeurs évitent ainsi de maintenir un système d’autorisation parallèle susceptible de s’écarter des contrôles de la plateforme.

Databricks a introduit pour la première fois l’autorisation OBO pour Apps en préversion publique le 26 mars 2025. La version de préversion couvrait des ressources telles que les tables Unity Catalog et les points de terminaison de model serving. La disponibilité générale indique que Databricks considère désormais ce modèle comme prêt pour une adoption en production dans les limites documentées.

La GA n’élimine pas l’autorisation d’application. Databricks présente explicitement les deux modèles comme complémentaires. Une application peut utiliser sa propre identité pour la configuration partagée, la télémétrie ou la maintenance courante, puis utiliser l’identité de la personne actuelle pour une requête gouvernée.

Prenons l’exemple d’un assistant d’analyse commerciale qui répond à des questions sur la performance des comptes. Son identité d’application peut lire la configuration commune et enregistrer des métriques opérationnelles. Son chemin d’identité utilisateur interrogerait les dossiers clients et commerciaux accessibles à l’employé demandeur.

Cette séparation constitue le fondement de la version. L’application conserve une identité, mais cette identité n’a plus besoin de devenir une passerelle universelle pour chaque action interactive. Les développeurs peuvent décider quel principal régit chaque opération.

Ce changement concerne donc davantage que la connexion. L’authentification établit qui est présent, tandis que l’autorisation détermine ce que cette identité peut faire. L’autorisation des utilisateurs de Databricks Apps prolonge cette seconde décision aux appels de données et de services en aval.

La véritable pression s’exerce sur le contrôle d’accès géré par l’application

Databricks remet en cause la pratique consistant à reconstruire les autorisations de données d’entreprise dans chaque application.

Une application qui utilise uniquement un principal de service partagé dispose souvent d’un ensemble d’autorisations cohérent. Les développeurs doivent ensuite décider quels résultats chaque employé peut recevoir. Cela exige généralement des rôles personnalisés, des mappages de politiques, une logique de filtrage ou un autre service d’autorisation.

Ces contrôles peuvent fonctionner, mais ils introduisent une deuxième source de vérité. Une équipe de gouvernance peut mettre à jour une autorisation Unity Catalog alors que le mappage de rôles local d’une application reste inchangé. L’écart qui en résulte peut exposer des informations ou refuser un accès légitime.

L’autorisation utilisateur réduit cette duplication pour les ressources Databricks prises en charge. Les autorisations établies de la personne demandeuse font partie du contexte d’exécution. Le code de l’application peut se concentrer sur la tâche demandée pendant que la plateforme évalue l’accès gouverné.

Cela devient de plus en plus important pour les agents d’IA. Un tableau de bord conventionnel expose des vues et des requêtes prédéfinies. Un agent peut interpréter un langage ouvert, choisir des outils, assembler des requêtes et récupérer des informations en plusieurs étapes.

Cette flexibilité augmente le nombre de chemins par lesquels des données protégées peuvent être atteintes. Un développeur ne peut pas anticiper de manière fiable toutes les questions qu’un employé pourrait poser. Préserver le contexte d’autorisation de l’employé donne à la plateforme en aval une frontière d’application supplémentaire.

La pression est particulièrement nette lorsque les organisations font passer des prototypes en production. Les premières démonstrations s’exécutent souvent avec les identifiants d’un développeur ou un compte de service largement autorisé. Ce raccourci devient difficile à justifier lorsqu’une application atteint des employés ayant des rôles, des territoires et des exigences de confidentialité différents.

Une seule application peut servir les ventes, la finance, les opérations et les dirigeants. Ces groupes ne devraient pas automatiquement hériter de la même vue des détails clients, des prévisions ou des informations sur les employés. Les politiques centralisées gagnent en valeur à mesure que l’audience s’élargit.

Databricks réduit également les frictions entre les administrateurs de la gouvernance et les équipes applicatives. Les équipes de sécurité peuvent continuer à gérer les privilèges de données via Unity Catalog. Les développeurs n’ont pas besoin de traduire chaque politique en middleware spécifique à un framework.

Cela ne supprime pas le travail de développement. Les équipes doivent toujours déterminer si une opération particulière relève de l’utilisateur ou de l’application. Elles doivent également comprendre quelles API Databricks prennent en charge OBO et quelles portées d’autorisation chaque action exige.

Les plateformes alternatives ne sont pas dépourvues d’identité déléguée. Le flux OBO de Microsoft transmet l’identité et les autorisations déléguées d’un utilisateur d’une API en amont vers une API en aval. Google Cloud fournit un accès applicatif tenant compte de l’identité, tandis qu’AWS propose des composants d’autorisation granulaires pour les applications personnalisées.

Databricks se différencie par son intégration à son environnement de gouvernance des données. La décision d’autorisation est associée aux autorisations Unity Catalog, à l’accès SQL et aux services de plateforme pris en charge. Cela peut réduire le travail d’intégration pour les applications dont les données résident déjà dans Databricks.

La contrepartie est une dépendance accrue à la plateforme. Les applications construites autour des règles Unity Catalog et des portées spécifiques à Databricks héritent de contrôles utiles, mais elles s’alignent également étroitement sur le modèle d’identité d’une seule plateforme. Les équipes multicloud peuvent encore avoir besoin d’une autre couche d’autorisation pour les ressources hors de Databricks.

Pour les acheteurs d’entreprise, la question n’est donc pas de savoir si l’identité déléguée existe ailleurs. Elle est de savoir si Databricks peut suffisamment simplifier le développement d’applications gouvernées pour conserver davantage de données et de charges de travail d’IA au sein de sa plateforme.

Comment l’autorisation au nom de l’utilisateur crée deux frontières d’autorisations

Une requête OBO ne réussit que dans les limites à la fois des autorisations de l’utilisateur et de la portée d’API approuvée de l’application.

La première frontière concerne les données et les ressources. Un utilisateur ne peut pas atteindre une table Unity Catalog, un entrepôt SQL ou un service pris en charge simplement parce qu’une application le demande. La personne doit déjà disposer des autorisations nécessaires.

La seconde frontière concerne l’application. Les développeurs déclarent des portées d’API, qui définissent les catégories d’opérations qu’une application peut effectuer pour un utilisateur. Une portée n’accorde pas à la personne un nouvel accès aux données, mais elle limite la manière dont l’application peut exercer l’accès existant.

Pour l’analyse SQL en lecture seule, Databricks documente une portée sql:restricted-query. L’application peut soumettre des requêtes restreintes en tant qu’utilisateur actuel sans recevoir une autorité étendue pour gérer des entrepôts ou effectuer un travail administratif non lié.

Ces frontières qui se croisent soutiennent le principe du moindre privilège, qui consiste à n’accorder que l’accès nécessaire à une tâche donnée. Un utilisateur fortement privilégié peut accéder directement à de nombreux jeux de données. Une application à portée restreinte devrait néanmoins être incapable d’exercer tous les privilèges de cet utilisateur.

Les administrateurs d’espace de travail contrôlent une limite supérieure supplémentaire. Ils peuvent déterminer quelles portées d’autorisation utilisateur les développeurs peuvent ajouter aux applications de l’espace de travail. La liste d’autorisation peut inclure toutes les API prises en charge, certaines portées sélectionnées ou aucune autorisation utilisateur.

Cette structure répartit les responsabilités. Le développeur demande les capacités minimales nécessaires au produit. L’administrateur décide quelles capacités les développeurs d’applications peuvent demander dans l’espace de travail.

Un administrateur ne peut toutefois pas s’appuyer uniquement sur la configuration. Databricks indique que les administrateurs de compte peuvent ajouter des portées même lorsqu’une liste d’autorisation d’espace de travail les exclut. Les applications existantes peuvent également continuer à s’exécuter après la suppression d’une portée autorisée.

Selon l’annonce, une application concernée ne peut ensuite ni démarrer, ni être déployée, ni être mise à jour tant que la portée non autorisée n’est pas supprimée. Ce comportement évite une interruption immédiate, mais il crée une période durant laquelle l’exécution actuelle et la politique actuelle ne correspondent pas entièrement.

Les équipes devraient donc traiter les changements de portée comme des événements opérationnels gouvernés. Les administrateurs ont besoin d’un inventaire des applications déployées, des portées demandées, des propriétaires responsables et des dépendances métier. Supprimer une capacité sans ce contexte peut retarder la remédiation ou bloquer une application lors de son prochain déploiement.

Le code de l’application doit également garder les deux identités séparées. Un client à portée utilisateur doit gérer les opérations interactives gouvernées. Un client à portée d’application doit gérer la configuration partagée, les métriques et le travail qui doit se poursuivre sans session utilisateur.

Ce n’est pas qu’une préférence de nommage. Un client générique peut masquer quelle identité exécute un chemin sensible. Des dépendances, tests et gestionnaires de requêtes distincts facilitent la détection d’une utilisation involontaire d’identifiants.

La règle la plus stricte concerne l’absence de jetons utilisateur. Si une route requiert une autorisation utilisateur mais qu’aucun jeton transféré n’est présent, l’application doit échouer de manière sécurisée. Elle doit rejeter la requête au lieu de basculer silencieusement vers son principal de service.

Un mécanisme de repli peut produire une réponse techniquement valide avec des autorisations entièrement différentes. L’utilisateur aurait peu de raisons de soupçonner que l’application a accédé à des informations plus larges ou plus restreintes que prévu. Les changements silencieux d’identité sont donc particulièrement dangereux.

Le jeton transféré ne doit exister que pendant la requête active. Databricks conseille aux développeurs de ne jamais l’afficher, l’enregistrer dans les journaux ou le conserver. Les tâches d’arrière-plan doivent utiliser l’autorisation de l’application plutôt que de conserver le jeton d’un utilisateur après la fin de la session interactive.

Pour les équipes qui développent des outils d’IA internes, cette séparation des identités doit s’ajouter aux autres contrôles d’ingénierie. Une base de connaissances techniques consultable peut conserver les décisions d’autorisation, les modèles de menace et les preuves de revue à côté de la documentation d’implémentation.

Les agents d’IA compliquent le maintien de la frontière d’identité

Les agents tirent parti des autorisations propres à chaque utilisateur, mais leur comportement en plusieurs étapes rend les erreurs d’identité plus lourdes de conséquences.

Databricks indique que les agents personnalisés déployés via Apps peuvent utiliser le même modèle d’autorisation. Le client d’espace de travail limité à l’utilisateur doit être initialisé dans le gestionnaire invoke ou stream actif. Le jeton transféré n’est disponible que pendant l’exécution de la requête.

Cette contrainte temporelle empêche les développeurs de traiter l’identité utilisateur comme un état global de l’application. Un processus d’agent peut servir de nombreuses personnes, et le démarrage de l’application n’appartient à aucun utilisateur en particulier. Créer un client limité à l’utilisateur trop tôt risque d’omettre ou de mélanger le contexte de la requête.

Les flux de travail d’un agent combinent également différents types de tâches. Une étape peut récupérer des instructions partagées via l’identité de l’application. Une autre peut interroger des données financières gouvernées au nom de l’utilisateur. Une troisième peut écrire de la télémétrie générale sans conserver l’identifiant de l’utilisateur.

Chaque transition crée une décision d’autorisation. Les développeurs doivent identifier le principal, la portée, la ressource et le mode d’échec attendu pour chaque appel d’outil. Un unique client d’agent générique peut brouiller ces distinctions.

La difficulté augmente lorsqu’un agent appelle un autre service. OBO ne peut préserver le contexte utilisateur que lorsque l’intégration en aval prend en charge ce modèle. Les API externes peuvent exiger des identifiants, un consentement, des portées et des contrôles d’audit distincts.

L’agent ne doit pas présumer que l’autorisation se transfère automatiquement à travers toute la chaîne d’outils. Un jeton est émis pour une audience et un objectif précis. Les recommandations OBO de Microsoft avertissent de même contre la transmission de jetons de niveau intermédiaire à des destinataires non prévus.

Cela signifie que l’autorisation utilisateur ne doit pas être décrite comme une usurpation d’identité générale. L’application agit pour l’utilisateur uniquement dans les portées configurées et les chemins de requête pris en charge. Cette formulation importe, car « agir en tant qu’utilisateur » pourrait autrement suggérer un accès sans restriction.

L’injection de prompt constitue une autre raison de faire preuve de prudence. Un attaquant pourrait placer des instructions dans un contenu récupéré par un agent, afin de l’encourager à appeler des outils ou à divulguer des informations. OBO limite les données accessibles à l’utilisateur actuel, mais ne détermine pas si une action demandée est judicieuse.

Les autorisations de l’utilisateur lui-même peuvent aussi être étendues. Un dirigeant, administrateur ou analyste peut avoir accès à des jeux de données sensibles couvrant de nombreuses fonctions métier. Une application compromise utilisant l’identité valide de cette personne présente toujours un risque sérieux.

Les portées fournissent une importante deuxième frontière dans cette situation. Une portée de requête en lecture seule peut empêcher une administration non liée, mais elle ne peut déterminer si chaque requête autorisée répond à l’intention de l’utilisateur. Les applications ont toujours besoin d’un traitement des entrées, de contraintes sur les outils, de contrôles des sorties et d’une surveillance.

Le consentement mérite également un examen attentif. Les utilisateurs peuvent approuver les autorisations demandées sans comprendre comment un agent combinera les services ou traitera les résultats. Des noms de portées clairs aident, mais le consentement ne remplace pas une revue administrative ni un comportement applicatif contraint.

L’auditabilité devient essentielle. Les équipes de sécurité doivent distinguer les actions réalisées par l’identité de l’application de celles effectuées pour une personne. Les journaux doivent identifier le principal et l’opération concernés sans enregistrer de jetons porteurs ni de contenu de réponse sensible.

Les tests doivent impliquer des utilisateurs dotés d’autorisations différentes. Un test réalisé uniquement avec un compte administrateur peut masquer des erreurs, car ce compte rencontre rarement des refus d’accès. Databricks recommande de répéter les tests après tout changement de politique de gouvernance.

Parmi les cas de test utiles figurent un utilisateur disposant d’un accès régional, un utilisateur doté d’un accès plus large et une personne n’ayant aucun accès à la table interrogée. Les équipes doivent vérifier à la fois les données renvoyées et le comportement de rejet. Elles doivent aussi confirmer que des jetons manquants ne déclenchent jamais un repli vers l’identité de l’application.

La limite centrale est donc claire. L’autorisation utilisateur de Databricks Apps peut appliquer les autorisations de plateforme existantes, mais elle ne peut pas corriger des droits trop larges. Les organisations doivent toujours maintenir des groupes exacts, des privilèges de catalogue, des accès aux entrepôts, des filtres de lignes et des masques de colonnes.

La promesse de sécurité dépend de la discipline opérationnelle

La partie la plus solide de cette conception réside dans son modèle de contrôle en couches, tandis que son point le plus faible reste l’implémentation et la gouvernance qui l’entourent.

Databricks peut transférer l’identité appropriée et appliquer les portées déclarées. Il ne peut pas garantir que chaque équipe de développement attribue la bonne identité à chaque chemin de code. Cette décision reste du ressort de l’architecture applicative.

Une équipe peut utiliser correctement OBO pour une requête SQL, mais employer par erreur l’identité de l’application pour une requête de fichier associée. L’interface utilisateur pourrait combiner les deux réponses sans révéler les différents contextes d’autorisation.

Le traitement en arrière-plan présente une autre frontière. Un utilisateur peut lancer une tâche de longue durée qui se poursuit après la fin de la requête. Comme le jeton transféré appartient à une requête active, les développeurs ne peuvent pas simplement le conserver pour une exécution ultérieure.

La conception la plus sûre consiste à déterminer si le travail différé appartient à l’application ou nécessite un autre modèle délégué pris en charge. S’il appartient à l’application, le principal de service doit disposer d’autorisations soigneusement limitées. S’il exige le contexte utilisateur, les développeurs doivent suivre le comportement documenté de la plateforme plutôt que de conserver le jeton.

La disponibilité selon les environnements exige également confirmation. La documentation Databricks évolue à mesure que les services et configurations de conformité s’étendent. Les équipes doivent vérifier la prise en charge du cloud, de la région, de l’espace de travail et du profil de sécurité avant de considérer la disponibilité générale comme universelle.

Les Apps ne peuvent pas être des applications publiques anonymes. Databricks indique que les utilisateurs doivent s’authentifier, et que les collaborateurs externes doivent être intégrés au moyen d’une fédération d’identité prise en charge. Le modèle est donc particulièrement adapté aux scénarios impliquant des employés et partenaires disposant d’identités gérées.

La séparation entre les autorisations de l’application et l’autorisation des données peut dérouter les réviseurs. CAN USE et CAN MANAGE déterminent qui peut exécuter ou administrer une application. Ils ne déterminent pas quelles tables ou quels enregistrements une personne peut consulter via celle-ci.

Une personne peut détenir l’autorisation d’utiliser une application tout en n’ayant pas le droit d’interroger ses données sous-jacentes. Cette requête doit échouer ou renvoyer des résultats limités. Inversement, l’accès aux données seul n’accorde pas nécessairement l’autorisation d’ouvrir l’application.

Les niveaux d’autorisation documentés doivent donc faire l’objet de revues distinctes des attributions Unity Catalog. Les traiter comme un seul contrôle peut créer un faux sentiment d’assurance lors des audits.

Les listes d’autorisations administratives par portée introduisent une autre tâche de gouvernance. Selon l’annonce, la valeur par défaut peut inclure toutes les API prises en charge. Les organisations soucieuses de la sécurité doivent déterminer si cette valeur par défaut correspond à leur modèle de développement avant d’adopter largement les applications.

Restreindre la liste d’autorisations peut réduire le risque, mais peut aussi bloquer des produits légitimes. Le bon processus associe une base de référence contrainte à un chemin d’exception documenté. Sans cela, les équipes peuvent chercher des identités d’application plus étendues afin d’éviter les restrictions de portée.

Un défi de détection existe également. Une application peut demander uniquement des portées approuvées et se comporter malgré tout de manière incorrecte dans celles-ci. La surveillance à l’exécution doit examiner les schémas de requêtes inhabituels, les refus répétés, les volumes de données inattendus et les changements de comportement de l’application.

Aucun benchmark indépendant n’établit actuellement le temps de développement que cette fonctionnalité permet d’économiser ni l’efficacité avec laquelle les entreprises évitent les défauts d’autorisation. L’annonce de disponibilité générale explique le mécanisme et les pratiques recommandées, mais les résultats d’adoption restent à démontrer.

Databricks a aussi intérêt à faire de sa couche de gouvernance la fondation par défaut des applications et agents internes. Les acheteurs doivent évaluer cet avantage stratégique au regard de la portabilité, de l’effort d’intégration et de la maturité de leurs systèmes d’autorisation existants.

La comparaison pertinente n’est pas un simple affrontement Databricks contre Microsoft. Le modèle d’identité déléguée de Microsoft est mature et largement applicable aux API. Databricks regroupe un principe apparenté autour de ses propres données, capacités de calcul, gouvernance et environnement d’exécution applicatif.

L’accès conscient de l’identité de Google vise à contrôler l’accès aux applications hébergées et aux politiques contextuelles. AWS propose des composants d’autorisation que les développeurs peuvent combiner avec des fournisseurs d’identité et des ressources applicatives. Chaque approche attribue une part différente du travail à la plateforme et à l’équipe applicative.

Les organisations doivent comparer l’emplacement des politiques, les ressources qu’elles couvrent, la manière dont les identités franchissent les frontières entre services et la façon dont les refus apparaissent aux utilisateurs. Elles doivent aussi vérifier si les enregistrements d’audit relient clairement une action à la fois à l’application et à la personne qui l’a initiée.

Le label GA abaisse un obstacle à l’adoption, mais ne résout pas ces questions architecturales. La fonctionnalité est la plus convaincante lorsque la gouvernance des données réside déjà dans Unity Catalog et que l’application appelle principalement des services Databricks pris en charge.

Trois signaux montreront si la version GA tient ses promesses

Le prochain test consistera à voir si les entreprises peuvent adopter des applications conscientes de l’utilisateur sans accroître le risque lié aux jetons, la complexité des politiques ou l’enfermement propriétaire.

Le premier signal sera l’adoption en production par les agents internes et les applications opérationnelles. Databricks a décrit un scénario clair d’analyse des ventes, mais les déploiements réels impliqueront des combinaisons plus complexes de SQL, modèles, fichiers, tableaux de bord et services externes.

Les signes d’une adoption mature comprendraient des modèles d’architecture reproductibles, des implémentations de référence et des flux d’audit clairs. Ils incluraient également des applications qui servent des utilisateurs aux autorisations réellement différentes sans dupliquer ces règles dans le code.

Une adoption faible suggérerait que les portées prises en charge, les services en aval ou les processus organisationnels restent trop limités. Les équipes pourraient continuer à utiliser des principaux de service largement autorisés ou des produits d’autorisation distincts malgré l’option GA.

Le deuxième signal sera l’extension et le perfectionnement des portées d’API prises en charge. Des portées étroites facilitent une conception fondée sur le moindre privilège, car les développeurs peuvent demander une capacité sans obtenir d’autorité non liée.

Des portées plus larges mais grossières affaibliraient la deuxième frontière d’autorisation. Des portées plus granulaires, de meilleurs contrôles administratifs et des expériences de consentement plus claires renforceraient l’affirmation de Databricks selon laquelle les applications peuvent agir pour les utilisateurs sans outrepasser leurs droits.

Les changements apportés à la prise en charge des profils de conformité comptent également. Databricks a indiqué que l’autorisation des utilisateurs serait étendue aux espaces de travail dotés du profil de sécurité de conformité fin septembre 2026. Les clients doivent confirmer la disponibilité et les limites dans leurs propres environnements.

Le troisième signal concerne la manière dont les concurrents intègrent l’identité déléguée à leurs plateformes d’agents. Microsoft documente déjà l’OBO pour les API classiques et les scénarios plus récents d’agents hébergés. D’autres plateformes relient également l’identité utilisateur, l’usage d’outils, les moteurs de politiques et les environnements d’exécution d’applications gérés.

Si ces alternatives exigent une intégration sur mesure importante, Databricks bénéficie d’un avantage pour les applications conçues autour de données d’entreprise gouvernées. Si les concurrents offrent un héritage des politiques tout aussi direct entre les données et les outils d’agents, les acheteurs se concentreront davantage sur la portabilité et l’étendue de l’écosystème.

Les développeurs devraient surveiller les éléments opérationnels plutôt que le langage des annonces. Des incidents de gestion des jetons, des flux de consentement confus, une prolifération des périmètres et des bogues de repli d’identité affaibliraient cet argument. Des audits clairs et une maintenance réduite des autorisations le renforceraient.

La tâche d’ingénierie immédiate est simple à énoncer, même si son exécution exige de la rigueur. Associez chaque opération de l’application soit à l’identité de l’application, soit à l’identité de l’utilisateur actuel. Attribuez le périmètre le plus restreint, refusez les identifiants manquants et testez avec des utilisateurs réellement différents.

Les équipes devraient également examiner les autorisations Unity Catalog existantes avant de les exposer par l’intermédiaire d’un agent. L’OBO applique fidèlement ces autorisations, y compris celles qui sont déjà plus étendues que prévu. La délégation ne peut pas améliorer une politique source faible.

L’autorisation utilisateur de Databricks Apps est donc importante, car elle rapproche la gouvernance tenant compte de l’identité des données et du runtime applicatif. Elle remplace une partie de la logique d’autorisation dupliquée par une application des règles par la plateforme, tout en préservant une identité d’application pour les tâches partagées.

Son succès dépendra de la capacité des développeurs à maintenir cette frontière à mesure que les applications gagnent en complexité. Avant de déployer le prochain assistant interne, posez une question pour chaque chemin de requête : cette opération doit-elle s’exécuter au nom de l’application ou de la personne qui l’utilise ?