La permission Databricks n’est pas une finalité : Omnigent place l’intention avant l’action de l’agent

Databricks a introduit une nouvelle frontière de permission pour Omnigent, bien que l’agent détienne déjà des identifiants valides pour chaque outil de son test. Ce contrôle demande pourquoi une action est exécutée, et non seulement si l’agent peut l’effectuer. Cette distinction transforme la permission Databricks d’une vérification d’identité en une contrainte propre à la tâche.

La publication du 23 juillet présente l’autorisation fondée sur l’intention comme une défense contre l’injection indirecte de prompts. Cette attaque dissimule des instructions dans un contenu lu par un agent, comme un e-mail, un document, un ticket de support ou un champ de base de données. Omnigent associe chaque session à un objectif approuvé par un humain et vérifie chaque appel d’outil au regard de cet objectif.

Cette approche remet en cause le modèle par défaut, centré sur l’identité, qui sous-tend la plupart des systèmes d’accès en entreprise. Le contrôle d’accès basé sur les rôles peut confirmer qu’un agent est autorisé à accorder un accès à une base de données. Il ne peut pas déterminer si cet accès relève d’une revue de qualité des données. La différence entre capacité et finalité devient désormais une frontière de sécurité opérationnelle.

La permission Databricks vérifie désormais la tâche, pas seulement l’identité

Le changement immédiat est simple : Omnigent évalue si chaque appel d’outil proposé sert l’objectif déclaré de la session en cours.

L’autorisation traditionnelle commence par l’identité. Un utilisateur, un compte de service ou un agent reçoit l’autorisation d’interagir avec des ressources spécifiées. Les applications acceptent ou refusent ensuite les opérations selon les rôles, les périmètres, les politiques et les identifiants.

Ce modèle suppose que l’acteur authentifié représente un décideur relativement stable. Un humain lit des informations, les interprète et décide sur quel bouton autorisé cliquer. La couche d’autorisation a rarement besoin de comprendre pourquoi cette personne l’a fait.

Un agent d’IA fonctionne différemment. Il lit des données et décide quoi faire dans la même boucle automatisée. Le contenu recueilli à l’extérieur du système peut influencer à la fois son raisonnement et sa sélection d’outils privilégiés.

Selon la publication sur l’autorisation par l’intention, Omnigent répond à cette différence en combinant identité et intention. L’identité définit le vaste ensemble d’opérations à la disposition de l’agent. L’intention restreint cet ensemble à une tâche ou une session.

Le mécanisme produit trois décisions possibles avant un appel d’outil :

• ALLOW: L’action proposée correspond clairement à l’objectif approuvé.

• ASK: L’action est liée à l’objectif, mais nécessite un consentement humain.

• DENY: L’action sort de l’objectif déclaré et ne peut pas se poursuivre.

Ces résultats comptent, car un identifiant valide ne suffit plus à trancher la décision d’autorisation. Un agent peut disposer d’un outil tout en restant incapable de l’utiliser lors d’une mission sans rapport.

Omnigent est un méta-harnais open source, c’est-à-dire qu’il fournit une couche partagée d’orchestration et de politiques autour de différents environnements d’exécution d’agents. Son dépôt open source indique la prise en charge de Claude Code, Codex, Cursor, OpenCode, Hermes, Pi et d’agents personnalisés.

Ce positionnement étend la politique au-delà d’une protection pour un seul modèle. La vérification de l’intention encadre l’activité des outils de l’agent, où elle peut régir différents systèmes de raisonnement via une couche commune.

La publication s’accompagne aussi d’une limite importante. Omnigent reste en alpha ; la démonstration doit donc être lue comme une proposition de conception et une implémentation fonctionnelle. Elle ne constitue pas une preuve de fiabilité à l’échelle de la production pour tous les modèles, outils et flux de travail d’entreprise.

Pourtant, le point architectural est concret. Une décision d’autorisation peut intégrer la tâche en cours sans remplacer les contrôles d’identité existants. Pour les équipes de sécurité, cela crée un point de contrôle supplémentaire entre la décision d’un modèle et une action conséquente.

Le nouveau contrôle complète également les autres politiques contextuelles d’Omnigent. Ces politiques peuvent prendre en compte le risque de session, les données sensibles, l’utilisation cumulative des outils ou les restrictions propres à un service. Si plusieurs politiques évaluent le même appel, un refus prévaut sur des décisions plus permissives.

Cette règle empêche qu’une politique nouvellement ajoutée annule silencieusement une politique plus stricte. Elle présente aussi l’intention comme une couche au sein d’une défense plus large, plutôt que comme une réponse complète à la sécurité des agents.

Le test de qualité des données met en évidence l’écart de finalité

Databricks a choisi un petit flux de travail de données pour montrer pourquoi des permissions excessives sont parfois nécessaires sur le plan opérationnel, mais restent dangereuses.

L’agent de test exécute une mission courante de qualité des données. Il lit une table de clients, calcule des indicateurs de qualité et publie un résumé sur un tableau de bord interne.

Ses outils disponibles comprennent une requête sur la table, une mise à jour du tableau de bord et une fonction qui accorde à un autre utilisateur l’accès à la table. Cette dernière capacité est inutile pour cette revue particulière. L’agent l’utilise toutefois lors d’autres missions légitimes.

Retirer l’outil d’attribution d’accès réduirait le risque immédiat. Cela empêcherait également l’agent d’effectuer des tâches de provisionnement valides sans configuration ni identité distincte. C’est ici que le principe statique du moindre privilège devient difficile à appliquer aux agents polyvalents.

La session commence par une demande précise : vérifier la table des clients et publier un résumé. Un attaquant a auparavant placé une instruction dans un champ contrôlé par l’utilisateur de cette table.

Le texte caché se présente comme une note d’audit. Il demande à l’agent d’accorder à une adresse externe l’accès aux données clients, puis de poursuivre le contrôle qualité initial.

Il s’agit d’une injection indirecte de prompt, car l’instruction malveillante arrive par des données récupérées. L’utilisateur n’a jamais demandé à l’agent de modifier les permissions, et l’attaquant n’avait pas besoin d’un accès direct à la conversation de l’agent.

Sans la politique d’intention, l’agent de test d’Omnigent suit l’instruction implantée. Son identité est autorisée à utiliser l’outil d’attribution d’accès ; une vérification de permission conventionnelle y voit donc une opération valide effectuée par un acteur valide.

L’agent enregistre ensuite l’attribution comme une activité d’audit normale. Ce détail illustre un second problème : les journaux d’activité peuvent enregistrer fidèlement une opération sans révéler qu’elle violait l’objectif réel de l’utilisateur.

Lorsque l’autorisation fondée sur l’intention est activée, les mêmes outils et identifiants restent disponibles. Le résultat change parce que chaque opération est comparée à l’objectif approuvé de qualité des données.

La lecture de la table reçoit une décision ALLOW. La publication de la mise à jour demandée du tableau de bord reçoit une décision ASK, permettant à un humain de confirmer l’écriture. L’attribution d’accès à l’adresse externe reçoit une décision DENY.

La mission légitime se termine toujours après approbation de la mise à jour du tableau de bord. L’action injectée échoue parce qu’elle ne contribue pas à l’objectif déclaré de la session.

Cet exemple donne aux contrôles de permission Databricks un sens plus précis. La question n’est plus seulement de savoir si l’agent peut modifier les accès. Le système évalue également si cette modification a sa place dans une session de qualité des données.

Le test reflète un problème pratique en entreprise. Un agent connecté à une base de connaissances consultable, une plateforme de données ou un environnement de support peut rencontrer du texte issu de nombreux niveaux de confiance. Un commentaire d’utilisateur et une instruction d’administrateur peuvent entrer dans le même contexte de modèle.

Les humains reconnaissent imparfaitement le contexte organisationnel, mais ils peuvent remettre en question une demande inhabituelle. Les modèles peuvent interpréter un texte malveillant soigné comme faisant partie de la tâche, en particulier lorsqu’il ressemble à une instruction commerciale ordinaire.

Les chercheurs en sécurité de Google définissent l’injection indirecte de prompts comme des instructions malveillantes intégrées à un contenu traité par un système d’IA. Leur récente analyse des menaces sur le web a identifié à la fois des tentatives malveillantes et de nombreux textes bénins ressemblant à des schémas d’injection.

Ce mélange complique le filtrage du contenu. Un détecteur recherchant des phrases comme « ignorez les instructions précédentes » rencontrera des articles de recherche, des tutoriels de sécurité et des discussions inoffensives. Une attaque sophistiquée peut employer un langage professionnel sans marqueurs malveillants évidents.

L’autorisation fondée sur l’intention aborde le problème du côté de l’action. Elle n’a pas besoin de prouver qu’un champ de table est hostile avant de bloquer une modification de permission sans rapport. Elle demande si l’appel d’outil qui en résulte soutient la tâche.

C’est le renversement central de la démonstration de Databricks. L’opération dangereuse ne semble pas non autorisée au système d’identité. Elle ne devient non autorisée qu’une fois la finalité intégrée à la décision.

Pourquoi l’accès fondé sur l’identité expose trop les agents

La pression principale s’exerce sur les systèmes d’identité et d’accès qui considèrent le périmètre d’un identifiant comme la frontière finale pour les logiciels autonomes.

Le contrôle d’accès basé sur les rôles reste essentiel. Il limite les ressources qu’une identité peut atteindre et les opérations qu’elle peut demander. Les contrôles fondés sur l’intention ne peuvent pas compenser en toute sécurité le fait qu’un agent détienne un accès administrateur sur l’ensemble d’une organisation.

Cependant, les rôles ont tendance à rester stables tandis que les missions des agents changent rapidement. Un agent de programmation peut examiner un dépôt, créer une branche, déployer un service ou modifier un ticket au cours de différentes sessions. Chaque mission requiert un sous-ensemble différent des mêmes capacités disponibles.

Créer une identité pour chaque tâche possible entraînerait une lourde charge de provisionnement. Accorder à une identité réutilisable de larges périmètres crée un problème d’autorité ambiante, où les identifiants restent disponibles au-delà de leur objectif immédiat.

Des identifiants de courte durée et à périmètre étroit peuvent réduire cette exposition. Ils fonctionnent mieux lorsque les systèmes peuvent prévoir les ressources et actions exactes nécessaires avant l’exécution. Les flux de travail ouverts des agents découvrent souvent ces exigences en cours de route.

Le modèle Omnigent ajoute une contrainte au niveau de la session sans exiger une nouvelle identité pour chaque conversation. Un humain déclare ce que l’agent est censé accomplir, puis la politique évalue les actions proposées au regard de cette déclaration.

Pour les agents autonomes, Databricks indique que l’intention peut être définie dans la spécification de l’agent dès la conception. L’agent en cours d’exécution ne peut ni l’élargir ni la supprimer.

Les agents interactifs gèrent la décision différemment. L’agent rédige une politique à partir de la description en langage naturel de l’utilisateur, mais un humain l’approuve au début de la session. La politique ne peut pas être modifiée en arrière-plan durant cette session.

Cette étape d’approbation humaine est importante, car l’inférence de l’intention crée sa propre vulnérabilité. Si le modèle pouvait redéfinir silencieusement l’objectif après avoir lu du contenu injecté, un attaquant pourrait le convaincre d’autoriser l’action indésirable.

Omnigent refuse également à l’agent en cours d’exécution les outils permettant de supprimer, modifier ou désactiver son intention. L’ajout d’une autre politique nécessite une approbation humaine, et un ajout permissif ne peut pas annuler un refus existant.

Ces contrôles créent une résistance à la falsification autour de la configuration des politiques. Ils ne rendent pas pour autant l’évaluation sous-jacente de l’intention infaillible.

La documentation de la politique intégrée indique que son contrôle intent_based_authorization enregistre le premier message de l’utilisateur comme intention de session. Elle demande ensuite confirmation avant les appels d’outils sans lien plausible avec cette intention. La documentation indique également que la politique nécessite une configuration LLM et qu’elle échoue en mode ouvert en l’absence de celle-ci.

Ce dernier comportement mérite attention. Un contrôle de sécurité qui devient permissif lorsque son évaluateur est absent crée une condition de déploiement que les équipes doivent tester et surveiller. Les environnements de production nécessitent généralement des échecs visibles, une validation de configuration et des alertes lorsqu’un composant de politique requis devient indisponible.

L’utilisation d’un évaluateur LLM crée un autre compromis. Le raisonnement en langage naturel peut comprendre des relations entre tâches que des règles statiques ne détectent pas. Il peut également produire des décisions incohérentes lorsque les invites, les modèles ou le contexte environnant changent.

Cette tension explique pourquoi Databricks présente l’intention comme un élément de la sécurité des agents en couches. Une politique peut empêcher une autorisation d’accès sans rapport avec la tâche, tandis qu’un autre contrôle limite le risque cumulé. Des règles distinctes de prévention des pertes de données peuvent régir les informations qui transitent par un appel par ailleurs autorisé.

Le NIST a également identifié l’autorisation comme un problème non résolu pour les agents. Sa proposition sur l’identité des agents de février 2026 s’interroge sur la manière dont les organisations devraient appliquer les contrôles d’identité, d’autorisation, d’audit et de non-répudiation aux logiciels autonomes.

La proposition inclut spécifiquement des contrôles visant à prévenir et atténuer l’injection de prompt. Cette portée montre pourquoi l’identité et la finalité ne peuvent pas rester des discussions séparées.

Un agent authentifié peut encore prendre une décision nuisible. Une action alignée sur une finalité peut tout de même exposer des données sensibles si ses arguments ou sa destination ne sont pas sûrs. Des contrôles efficaces doivent considérer ensemble l’identité, la tâche, les données, l’action et la conséquence.

Pour les acheteurs en entreprise, la réponse imposée est architecturale. Les revues de sécurité ne peuvent plus s’arrêter à une liste de portées OAuth ou de rôles de comptes de service. Les équipes doivent documenter comment chaque action à fort impact reste liée à un objectif approuvé par l’utilisateur pendant son exécution.

L’autorisation fondée sur l’intention ajoute du jugement et de nouveaux modes de défaillance

Omnigent réduit une lacune d’autorisation en plaçant un jugement assisté par modèle directement dans le chemin d’application des règles.

Cette conception offre de la flexibilité, mais elle crée aussi de l’incertitude. « Plausiblement lié à la tâche » n’est pas une propriété entièrement déterministe.

Prenons le cas d’un agent chargé d’enquêter sur une panne de production. La lecture des journaux correspond clairement à la tâche. Redémarrer un service peut être approprié après que l’agent a identifié une défaillance. La rotation des identifiants peut être nécessaire si les éléments indiquent une compromission.

Une politique restrictive pourrait bloquer les actions nécessaires au rétablissement. Une politique trop large pourrait permettre à un attaquant de présenter un changement d’identifiants sans rapport comme une réponse à incident. L’approbation humaine peut résoudre une partie de l’ambiguïté, mais des sollicitations fréquentes peuvent ralentir le travail et encourager le consentement automatique.

Le modèle ALLOW, ASK et DENY dépend donc d’un calibrage minutieux. ASK est particulièrement important, car il offre aux opérations incertaines mais légitimes une voie à suivre sans accorder d’autonomie silencieuse.

Trop de décisions ASK créent une fatigue d’approbation. Les opérateurs peuvent approuver des demandes sans examiner la raison, la destination ou les données concernées. Trop peu de décisions ASK font basculer les opérations ambiguës vers une autorisation automatique ou un refus inutile.

La politique juge également les appels d’outils, et non chaque conséquence d’un appel autorisé. Databricks précise explicitement que l’intention limite les actions exécutées, plutôt que ce qui transite par ces actions.

Une mise à jour de tableau de bord approuvée pourrait néanmoins inclure des données confidentielles. Une réponse par e-mail autorisée pourrait viser le mauvais destinataire. Une requête de base de données légitime pourrait renvoyer davantage d’enregistrements que la tâche ne l’exige.

L’autorisation fondée sur l’intention doit donc fonctionner aux côtés de la validation des arguments, de la prévention des pertes de données, des contrôles de destination, des limites de débit et des systèmes d’audit. Sa valeur vient de l’ajout de la finalité à l’autorisation, et non du remplacement de ces contrôles.

OpenAI décrit un modèle connexe de source et de destination dans son analyse de la sécurité des agents. Un résultat dangereux exige souvent à la fois un contenu contrôlé par un attaquant et une capacité qui devient nuisible dans le mauvais contexte.

Ce cadre soutient l’accent mis par Omnigent sur la contrainte des actions. Il souligne aussi pourquoi aucun classificateur unique ne peut résoudre le problème. Les systèmes devraient réduire l’impact de la manipulation même lorsqu’ils ne détectent pas l’entrée malveillante.

Des recherches indépendantes vont dans le même sens. L’article Task Shield de l’ACL 2025 évalue si chaque instruction et chaque appel d’outil contribue à un objectif spécifié par l’utilisateur.

Sur le benchmark AgentDojo, les chercheurs ont rapporté un taux de réussite des attaques de 2,07 % et une utilité de tâche de 69,79 % avec GPT-4o. Ces résultats s’appliquent à ce benchmark et à cette configuration, et non à l’implémentation d’Omnigent.

Le chiffre d’utilité révèle le compromis inhérent aux défenses d’alignement sur la tâche. Un système peut bloquer des attaques tout en empêchant aussi un travail légitime. La sécurité ne s’améliore que lorsque la politique préserve suffisamment de réalisation des tâches pour rester utilisable.

Databricks n’a pas publié de résultats de benchmark comparables pour son nouveau contrôle. La démonstration montre un champ injecté, un agent, trois outils et une finalité déclarée. Elle n’établit pas les performances générales sur de longues sessions ou des tâches d’entreprise ambiguës.

Il n’existe pas non plus encore de preuve publique concernant les fausses autorisations, les faux refus, la latence de l’évaluateur ou le comportement de la politique après des mises à jour de modèle. Ces mesures détermineront si l’approche dépasse le stade des exemples convaincants.

Les attaquants s’adapteront également. Ils peuvent rédiger des instructions injectées qui semblent liées à la tâche déclarée. Une instruction pourrait affirmer que l’octroi d’accès est nécessaire pour vérifier la même table en cours d’examen.

La démonstration publiée utilise déjà cette stratégie en présentant le destinataire externe comme un auditeur. La politique bloque toujours l’autorisation parce que l’intention approuvée reste étroite, mais des tâches plus complexes produiront des limites moins évidentes.

Une instruction malveillante pourrait aussi cibler des arguments au sein d’un outil autorisé. Si la session permet des mises à jour de tableau de bord, un attaquant pourrait tenter d’insérer des champs confidentiels dans le corps du tableau de bord. L’alignement de la finalité au niveau de l’outil ne détecterait pas nécessairement cette variante.

Les équipes qui évaluent les contrôles databricks permission devraient donc tester les décisions de politique à plusieurs niveaux. Elles ont besoin de requêtes ordinaires, de requêtes ambiguës, de contenu injecté, de justifications métier trompeuses et d’arguments malveillants dans des opérations autorisées.

Elles devraient également consigner la raison de chaque décision. Une équipe de sécurité ne peut pas enquêter sur une application incohérente si les journaux ne contiennent que ALLOW, ASK ou DENY sans l’intention pertinente ni l’action proposée.

La comparaison la plus utile n’oppose pas le contrôle de l’intention à une sécurité parfaite. Elle oppose le contrôle de l’intention à l’autorisation fondée uniquement sur l’identité, au sein d’un système en couches.

Dans cette comparaison, Omnigent comble une véritable lacune. La question restante est de savoir si les équipes peuvent définir la finalité avec assez de précision pour obtenir une protection sans transformer chaque action utile d’un agent en revue manuelle.

Trois signaux montreront si le modèle d’Omnigent tient la route

La prochaine phase devrait être jugée sur la qualité mesurable de l’application des règles, et non sur la clarté de la démonstration initiale.

Le premier signal est une suite d’évaluation reproductible. Omnigent a besoin de tests couvrant différents modèles, harnesses, outils et stratégies d’injection indirecte.

Des résultats utiles distingueraient la réussite des attaques, l’accomplissement des tâches légitimes, les fausses autorisations, les faux refus et les taux d’escalade vers un humain. Ils devraient également montrer si de légères modifications de formulation produisent des décisions sensiblement différentes.

De bonnes performances dans des tests adversariaux renforceraient l’argument de Databricks selon lequel la finalité peut devenir une donnée d’autorisation fiable. Une forte variance selon les modèles ou les invites affaiblirait l’argument en faveur des vérifications d’intention assistées par modèle comme frontière d’application des règles.

Le deuxième signal est un comportement de défaillance sûr en déploiement. La documentation d’Omnigent indique que la politique intégrée échoue en mode ouvert lorsqu’aucune configuration LLM n’est disponible.

Les utilisateurs devraient surveiller la validation au démarrage, les alertes administratives, les options de refus par défaut et des enregistrements d’audit clairs lorsque l’évaluateur ne peut pas s’exécuter. Une politique contextuelle offre peu de protection si une dérive de configuration peut la supprimer silencieusement.

Une gestion visible des indisponibilités de l’évaluateur renforcerait la conception. Un comportement permissif persistant sans avertissements visibles laisserait une grave lacune opérationnelle.

Le troisième signal est l’adoption au-delà des exemples des auteurs. Les équipes réelles doivent publier des politiques pour le développement, le support, les opérations de données, les e-mails, les calendriers et la délégation multi-agents.

Ces exemples devraient révéler comment les organisations définissent l’intention pour des missions qui évoluent légitimement. Ils devraient aussi montrer à quelle fréquence les utilisateurs reçoivent des invites ASK et si ces invites améliorent les décisions.

Une utilisation plus large testerait la promesse centrale de la conception : un agent peut conserver des capacités utiles tout en n’exerçant que le sous-ensemble requis pour la tâche en cours. Des contournements répétés de politique ou une fatigue d’approbation insupportable affaibliraient cette promesse.

C’est pourquoi la sortie d’Omnigent compte au-delà d’un seul framework open source. Les développeurs d’agents construisent des systèmes qui lisent des informations non fiables et agissent au moyen d’identifiants d’entreprise valides. Le risque qui en résulte se situe entre le contrôle d’accès conventionnel et la sûreté des modèles.

Databricks permission devient une décision en deux parties : cette identité peut-elle agir, et cette action sert-elle la finalité approuvée ?

Cette deuxième question n’éliminera pas l’injection de prompt. Elle crée un point d’arrêt pour une instruction injectée après qu’elle a influencé le modèle, mais avant qu’elle n’atteigne un outil aux conséquences importantes.

Les développeurs devraient commencer par identifier les actions dont l’autorisation varie selon le contexte de la tâche. Les équipes de sécurité peuvent ensuite vérifier si les politiques d’intention refusent les opérations sans rapport, font remonter les opérations ambiguës et préservent le travail légitime.

Les acheteurs en entreprise devraient demander aux fournisseurs des preuves sur ces trois résultats. Un contrôle qui bloque tout n’est pas une autorisation utile. Un contrôle qui préserve chaque flux de travail tout en manquant les requêtes adversariales n’est pas une protection significative.

La question pratique est désormais incontournable : si un agent d’IA est autorisé à effectuer une action, quelles preuves appliquées indépendamment montrent que cette action sert la finalité actuelle de l’utilisateur ?