Databricks : la présomption d’innocence jusqu’à ce qu’une politique combinée bloque le risque agentique au point de jonction

Databricks a publié un nouveau schéma de sécurité Omnigent qui ne bloque un agent qu’après que trois capacités, ordinaires prises individuellement, ont formé une chaîne dangereuse. L’approche de Databricks, innocent jusqu’à combinaison, cible le moment où des données privées, du contenu non fiable et une communication externe deviennent disponibles au sein d’une même session.

Cette combinaison est connue sous le nom de trifecta létale. Un agent peut lire sans risque un fichier interne, examiner une page web publique ou envoyer un message lorsque chacune de ces actions se produit isolément. Réunissez ces trois capacités dans un même chemin d’exécution, et une instruction injectée peut transformer un accès légitime en vol de données.

L’évolution importante n’est pas un nouvel avertissement sur l’injection de prompts. Databricks déplace la décision d’application des règles hors du modèle et vers Omnigent, son méta-harnais open source destiné à exécuter et gouverner les agents. La couche de politique mémorise ce qu’une session a rencontré, puis modifie la manière dont elle traite les actions ultérieures.

Les autorisations statiques demandent si un agent peut appeler un outil. Les politiques contextuelles demandent aussi ce qui s’est produit avant cet appel. Cette différence met sous pression les équipes qui utilisent un accès large et persistant aux outils via des agents de codage, des agents de navigateur et des intégrations Model Context Protocol.

Ce que Databricks a modifié dans Omnigent

Databricks considère l’historique d’un agent comme faisant partie de son ensemble effectif d’autorisations.

L’étude de cas de sécurité de l’entreprise prolonge une série d’articles consacrés aux politiques contextuelles dans Omnigent. Les exemples précédents portaient sur l’état de session, les attaques progressives et les autorisations liées à l’intention initiale de l’utilisateur.

Le dernier exemple applique ce modèle à la trifecta létale. Le chercheur en sécurité Simon Willison a défini ce schéma en juin 2025 comme l’accès à des données privées, l’exposition à du contenu non fiable et un canal de communication externe. Son modèle de menace avertit que la combinaison des trois offre aux instructions injectées une voie pour dérober des informations.

Omnigent se place au-dessus d’un harnais d’agent, c’est-à-dire l’environnement d’exécution qui gère le modèle, les outils et la boucle d’exécution. Le projet prend en charge des environnements établis d’agents de codage ainsi que des agents personnalisés, ce qui permet à une couche de politique commune d’observer leur activité.

Cette position importe, car la politique n’a pas besoin que le modèle sous-jacent reconnaisse chaque formulation malveillante. Elle peut gouverner l’usage des outils à partir de faits consignés pendant la session.

Prenons un agent chargé d’examiner un document interne sur un produit. La lecture de ce document est attendue. L’envoi d’un résumé approuvé vers un canal d’entreprise peut également être attendu.

Supposons maintenant que l’agent visite un ticket public, une page web ou un dépôt contenant des instructions cachées. Une requête sortante ultérieure prend alors une signification de sécurité différente, car la session a franchi une autre frontière de confiance.

Une liste d’autorisation conventionnelle voit les mêmes outils approuvés tout au long du flux de travail. Une politique contextuelle voit une séquence dont le risque a évolué au fil du temps.

Les politiques Omnigent peuvent renvoyer une décision d’autorisation, de demande ou de refus. L’autorisation permet l’action, la demande la transmet à une personne et le refus la bloque. La réponse peut donc devenir plus stricte à mesure que la session accumule des accès sensibles ou des événements risqués.

Ce modèle d’application ne nécessite pas que chaque source, outil ou action soit dangereux en soi. La politique surveille plutôt les combinaisons qui créent un chemin de données non sûr.

Databricks propose également Omnigent sous la forme d’une bêta gérée, connectée à l’identité de l’espace de travail et aux services de modèles. Son déploiement géré prend actuellement en charge des gestionnaires de politiques contextuelles intégrés, tandis que les fonctions de politique personnalisées arbitraires y restent indisponibles.

Cette limitation distingue la conception open source du produit géré. Les équipes qui évaluent cette annonce doivent distinguer un modèle de politique démontré des contrôles disponibles dans le déploiement qu’elles ont choisi.

Néanmoins, le changement central est clair. L’autorisation des agents devient dépendante de la session, plutôt que fixe à la connexion ou lors de l’enregistrement d’un outil.

Pourquoi l’approche de Databricks, innocent jusqu’à combinaison, redéfinit la frontière de sécurité

L’objet risqué n’est plus un seul appel d’outil ; c’est le chemin qui relie plusieurs appels autorisés.

Le contrôle d’accès traditionnel évalue les identités, les ressources et les actions. Un compte de service peut lire une base de données, écrire dans un bucket ou appeler une API. Ces règles restent nécessaires, car les agents continuent d’opérer avec des identifiants ordinaires.

Elles ne suffisent pas lorsque du langage non fiable influence la manière dont ces identifiants sont utilisés. Un attaquant peut ne jamais avoir besoin de voler un jeton ni d’exploiter du code applicatif. Il lui suffit que du contenu malveillant atteigne un modèle capable d’accéder à des données et d’agir à l’extérieur.

Le premier élément est constitué des données privées. Cette catégorie comprend les documents internes, le code source, les identifiants, les dossiers clients, les e-mails, les résultats de bases de données et toute information hors du périmètre d’autorisation de l’attaquant.

Le deuxième élément est le contenu non fiable. Une page web, un ticket de support, une pull request, un e-mail, un fichier partagé, une réponse d’outil ou une image peuvent contenir des instructions contrôlées par une personne extérieure à la frontière de confiance de l’agent.

Le troisième élément est la communication externe. Les e-mails et les requêtes HTTP en sont des exemples évidents, mais cette catégorie est plus vaste. Publier un commentaire, pousser du code, charger une ressource distante ou écrire dans un système partagé peut créer un canal sortant.

Aucune de ces capacités n’a d’inhabituel. C’est précisément leur utilité qui explique pourquoi cette combinaison apparaît dans tant de conceptions d’agents.

Un agent de recherche a besoin de sources externes et de contexte interne. Un agent de codage peut lire un dépôt privé, consulter une documentation publique et pousser une branche. Un assistant e-mail lit des messages non fiables, recherche dans une correspondance privée et envoie des réponses.

Supprimer définitivement une capacité peut rendre l’agent nettement moins utile. Les demandes d’approbation constantes créent un autre problème : les utilisateurs peuvent s’habituer à accepter les requêtes routinières.

Le cadrage de Databricks, innocent jusqu’à combinaison, offre une autre option. Laisser les opérations à faible risque se poursuivre, mais escalader lorsque l’état de la session complète une combinaison interdite.

Cela déplace la frontière de sécurité du connecteur individuel vers le flux de travail. Un navigateur n’est pas simplement fiable ou non fiable. Sa pertinence dépend du fait que la même session détient aussi des informations sensibles et une voie sortante.

Ce modèle ressemble au contrôle des flux d’information, dans lequel un système suit la manière dont les données circulent entre des niveaux de confiance. Une fois qu’une information confidentielle entre dans un contexte, les écritures ultérieures vers une destination moins protégée font l’objet d’un traitement plus strict.

Le catalogue de politiques publié par Omnigent inclut déjà un contrôle Google Drive associé. Lorsqu’une session lit un fichier déclaré confidentiel, la politique peut empêcher les écritures en dehors de l’ensemble confidentiel.

Le catalogue inclut également une politique de score de risque. Elle accumule des points à partir des appels d’outils et des étiquettes de données sensibles, puis renforce le contrôle des outils protégés après un seuil configuré.

Ces exemples montrent pourquoi l’état est central. Une requête d’écriture ne change pas de forme d’API après que l’agent a lu un document sensible. Sa signification change en raison de l’historique de la session.

Le même principe s’applique à la trifecta létale. La politique recherche une composition dangereuse, et non une opération universellement interdite.

Cette distinction devrait intéresser davantage les équipes de plateforme qu’un filtre de prompts supplémentaire. Les filtres tentent de déterminer si un texte semble malveillant. L’application contextuelle peut tout de même bloquer une action dangereuse lorsque le modèle ou le filtre ne parvient pas à identifier l’injection.

Les autorisations statiques perdent la séquence

Une liste d’autorisation statique peut décrire les capacités disponibles, mais elle ne peut pas expliquer comment l’agent est arrivé à une action.

Supposons qu’un développeur autorise un agent à lire un dépôt privé, parcourir de la documentation et ouvrir des pull requests. Chaque autorisation soutient un flux de travail de codage normal.

Un attaquant place ensuite une instruction dans un ticket, un document de dépendance ou une page web récupérée. L’instruction demande à l’agent de collecter un secret et de l’inclure dans la description d’une pull request publique.

La lecture du dépôt est autorisée. La récupération web est autorisée. L’ouverture d’une pull request est autorisée. Un contrôle qui évalue chaque requête indépendamment peut approuver l’ensemble de la chaîne.

Un filtre de contenu peut détecter l’instruction. Il peut aussi manquer une requête indirecte, des données encodées, une langue peu familière ou une charge utile conçue pour contourner le modèle ciblé.

Les recherches invitent à la prudence quant à une dépendance au seul comportement du modèle. Le benchmark WASP a testé des attaques réalistes par injection de prompts contre des systèmes d’agents web utilisant plusieurs modèles et cadres d’exécution.

Ses chercheurs ont constaté que les agents commençaient à exécuter des instructions adverses dans 16 à 86 % des cas selon les configurations testées. Le succès de l’attaquant de bout en bout était plus faible, allant de zéro à 17 %.

Cet écart est encourageant, mais pas rassurant. Les agents actuels échouent souvent avant d’achever une attaque complexe ; toutefois, l’amélioration de leur fiabilité peut aussi faciliter l’aboutissement de flux de travail malveillants.

Un système ne devrait pas compter sur le fait qu’un agent se trompe au bon moment. Il a besoin d’un contrôle qui reste efficace à mesure que les modèles progressent dans l’exécution en plusieurs étapes.

Les autorisations statiques gèrent également mal les attaques différées. L’instruction injectée peut ne pas déclencher une action sortante immédiate. Elle peut influencer un plan ultérieur, une tâche déléguée, un fichier généré ou un appel d’outil.

Une politique consciente de la session peut conserver les faits pertinents pour la sécurité pendant ce délai. Elle n’a pas besoin que chaque événement suspect se trouve à côté de l’action finale dans le contexte actif du modèle.

Cette persistance répond à une faiblesse pratique des agents de longue durée. L’historique des conversations peut être compressé, résumé ou réparti entre des workers. Un modèle peut oublier une contrainte antérieure alors que ses outils et ses identifiants restent disponibles.

L’état de la politique devrait donc résider hors de la fenêtre de texte. La couche d’application a besoin de son propre registre durable des lectures sensibles, des entrées non fiables, des destinations, des approbations et des changements de risque.

Cette architecture réduit également la dépendance à l’auto-déclaration de l’agent. Demander au modèle s’il a rencontré du contenu non fiable est moins robuste que d’enregistrer quel connecteur a fourni ce contenu.

Les signaux les plus forts proviennent de l’infrastructure. Un système documentaire connaît la classification d’un fichier. Une passerelle réseau connaît la destination. Une couche d’identité connaît l’utilisateur et l’espace de travail. Un courtier d’outils connaît l’opération demandée.

Omnigent peut combiner ces signaux parce qu’il encapsule l’environnement d’exécution. L’agent propose une action, mais la politique décide si cette action reste acceptable au regard du contexte enregistré.

C’est le point de pression pour les plateformes d’agents concurrentes. Les approbations au niveau des outils sont plus faciles à expliquer et à mettre en œuvre. Elles deviennent moins crédibles lorsque les agents exécutent des sessions plus longues sur davantage de connecteurs.

Les fournisseurs devront montrer si leurs contrôles suivent les données et les transitions de confiance entre les outils. Une longue liste d’autorisations ne répond plus à la question centrale de sécurité.

Les politiques contextuelles brisent la chaîne avant que les données ne sortent

Le point de contrôle utile est la transition qui complète le chemin d’attaque, généralement une lecture sensible ou une action sortante.

Une politique contextuelle commence par des événements observables. Il peut s’agir de l’appel d’un outil, du résultat d’un outil, d’une étiquette de données, d’une destination, d’une requête adressée à un modèle ou d’une approbation utilisateur.

La politique stocke certains faits sélectionnés dans l’état de la session. Elle peut enregistrer que l’agent a consommé du contenu non fiable, accédé à un objet confidentiel ou tenté de communiquer au-delà d’une limite approuvée.

Les événements ultérieurs sont évalués à l’aune de cet état. Si l’opération suivante achève une combinaison interdite, la politique peut exiger une approbation ou refuser la requête.

L’ordre peut varier. Un agent peut lire des données privées avant de visiter une page non fiable. Il peut aussi rencontrer d’abord le contenu injecté, puis demander l’accès à un fichier interne.

Une implémentation robuste doit détecter les deux parcours. Le risque vient de la connexion entre les capacités, et non d’un ordre fixe.

L’application des règles peut également intervenir à plusieurs étapes. Une politique peut bloquer la lecture sensible après l’entrée de contenu non fiable dans la session. Une autre approche peut autoriser l’analyse, mais empêcher toute communication externe ultérieure.

Bloquer la sortie de données préserve souvent davantage l’utilité locale. L’agent peut continuer à lire et à rédiger sans disposer d’un moyen d’exposer des informations. Toutefois, les contrôles de sortie doivent couvrir davantage que les fonctions d’envoi évidentes.

Un lien généré peut encoder des données. Une requête d’image distante peut transmettre des paramètres de requête. Un push de contrôle de version, un commentaire d’issue, un appel analytique ou une écriture dans un document partagé peuvent franchir la limite de confiance.

Le contexte de destination compte également. Envoyer un résumé vers un canal interne approuvé diffère d’une publication dans un dépôt public. Traiter toutes les écritures de la même façon créerait des interruptions inutiles.

L’approbation humaine est précieuse lorsque le contexte et la destination sont clairs. Une invite utile doit expliquer que la session a lu des données confidentielles, consommé ultérieurement du contenu non fiable et souhaite maintenant contacter un endpoint externe particulier.

Un message générique du type « autoriser cet outil » masque la raison de l’escalade. Il encourage la fatigue liée aux approbations, car l’examinateur doit reconstituer manuellement le flux de travail.

Un refus catégorique convient aux combinaisons qu’une organisation n’accepte jamais. Par exemple, une politique peut empêcher toute session exposée à du contenu public d’envoyer des informations issues d’un ensemble de données restreint en dehors de son compartiment.

Le moteur de politiques doit échouer de manière sûre lorsque le contexte requis manque. Une étiquette de données absente, un outil non pris en charge ou un chemin réseau non observé peuvent créer un angle mort.

L’approche plus large d’Omnigent combine des politiques avec du sandboxing. Un sandbox restreint l’accès au système de fichiers et au réseau à la frontière du système d’exploitation, réduisant ce qu’un agent peut atteindre même si le modèle le demande.

Ces couches remplissent des fonctions différentes. Le sandbox limite la capacité brute. La politique contextuelle ajuste les autorisations selon l’état accumulé de la session.

Aucune ne remplace les contrôles d’identité ordinaires, l’autorisation des connecteurs, la journalisation ou la prévention des fuites de données. L’annonce est surtout utile lorsqu’elle est interprétée comme une couche de contrôle parmi cet ensemble.

Le rapport sur la sécurité agentique d’OWASP identifie l’injection de prompts comme une technique d’attaque majeure contre les systèmes d’IA. Son message plus large est que la sécurité des agents exige des contrôles autour de l’exécution, des outils, de l’identité et des mouvements de données.

Cela soutient l’orientation architecturale de Databricks. Un modèle probabiliste peut suggérer une action, mais une frontière déterministe doit décider si cette action est autorisée.

Ce que la politique de Databricks ne tranche pas

L’application contextuelle réduit le chemin d’attaque, mais sa fiabilité dépend d’une visibilité complète et d’une classification digne de confiance.

La première question non résolue est la couverture. Une politique ne peut pas bloquer un canal qu’elle n’observe pas.

Un agent peut communiquer via un connecteur, une commande shell, une requête de navigateur, une ressource intégrée ou un artefact généré. Chaque voie permettant de déplacer des données au-delà de la limite doit être représentée dans le modèle de politique ou contrainte ailleurs.

La deuxième question est la classification. Le système doit savoir quel contenu est non fiable et quelles données sont sensibles.

Des règles simples peuvent classer les pages web publiques comme non fiables et les documents nommés comme confidentiels. Les environnements d’entreprise comportent des cas plus difficiles, notamment les disques partagés, les comptes de prestataires, le texte copié, les fichiers générés et les données assemblées à partir de plusieurs sources peu sensibles.

Les faux négatifs laissent la combinaison dangereuse passer inaperçue. Les faux positifs interrompent le travail ordinaire et peuvent apprendre aux utilisateurs à approuver les avertissements sans les examiner.

La troisième question est la portée de l’état. Une session constitue une unité pratique, mais les informations peuvent circuler entre les sessions via des fichiers, des magasins de mémoire, des caches, des sous-agents et des résumés copiés.

Si un worker lit des données confidentielles et qu’un autre envoie le résultat, le suivi par session peut manquer le flux combiné. Les systèmes multi-agents ont besoin de règles de propagation qui préservent les étiquettes pertinentes à travers la délégation.

La quatrième question est l’intégrité des politiques. La couche d’application, la configuration et le flux d’événements deviennent une infrastructure critique pour la sécurité. Les attaquants peuvent cibler les lacunes des politiques, des métadonnées d’outils malformées, des destinations ambiguës ou un comportement qui échoue en laissant passer.

Les équipes doivent tester la frontière réelle des politiques, et pas seulement le modèle. Les évaluations adversariales doivent inclure des voies alternatives de sortie, des actions différées, des transferts inter-agents et des métadonnées incomplètes.

La cinquième question est l’utilisabilité. Un contrôle qui demande trop souvent une approbation peut reproduire la faiblesse qu’il était censé résoudre.

L’escalade fondée sur le risque exige des seuils soigneusement choisis et des invites informatives. Les équipes de sécurité devraient mesurer la fréquence des approbations, la précision des refus, les taux de dérogation et les raisons pour lesquelles les utilisateurs acceptent des exceptions.

La bêta gérée d’Omnigent introduit une autre contrainte pratique. Databricks documente actuellement la prise en charge de gestionnaires intégrés, et non de code de politique personnalisé arbitraire, dans l’environnement géré.

Les organisations disposant de classifications spécialisées ou de connecteurs propriétaires doivent vérifier si les politiques disponibles exposent suffisamment de contexte. La flexibilité open source ne se traduit pas automatiquement par une parité avec le service géré.

Il n’existe pas non plus, à ce stade, de raison de considérer une démonstration comme une validation universelle. L’article de Databricks explique un modèle de sécurité et une approche d’implémentation. Il n’établit pas que chaque configuration d’Omnigent bloque chaque technique d’injection de prompts.

L’affirmation correcte est plus limitée. Une application tenant compte de la session peut rompre un parcours de la triade létale, même lorsque chaque outil individuel reste légitime.

Cela reste important. L’architecture de sécurité réussit souvent en supprimant une condition nécessaire à une attaque, et non en apprenant à l’application à reconnaître chaque message d’attaquant.

Les déploiements les plus solides combineront une politique contextuelle avec des identifiants restreints, des listes d’autorisation de destinations, du sandboxing, des journaux d’audit et des tests indépendants. Ils traiteront également les définitions de politiques comme du code de sécurité versionné.

Trois signaux indiqueront si le modèle tient

Le prochain test consiste à savoir si la politique contextuelle devient une infrastructure mesurable plutôt qu’une démonstration convaincante.

Le premier signal est une couverture plus large des outils et des harnais d’agents. Databricks doit montrer que les étiquettes de sécurité et l’état de session survivent aux flux de travail courants impliquant des navigateurs, des dépôts de code, des systèmes documentaires, des shells et des agents délégués.

La prise en charge dans une liste de fonctionnalités ne suffit pas. Les équipes ont besoin de preuves que des actions équivalentes reçoivent une application équivalente à travers différents harnais et implémentations de connecteurs.

Une couverture cohérente renforcerait l’argument en faveur d’un méta-harnais partagé. Des différences substantielles entre les environnements d’exécution affaibliraient la promesse d’une couche de gouvernance unique pour les agents.

Le deuxième signal est l’évaluation adversariale. Omnigent a besoin de tests reproductibles qui tentent l’exfiltration différée, la sortie indirecte, le transfert inter-session et la manipulation des métadonnées.

Les résultats utiles doivent distinguer la détection, l’approbation, le refus et le déplacement effectif de données. Ils doivent aussi indiquer le taux d’achèvement des tâches bénignes, car une politique qui bloque chaque flux de travail est sûre mais inutilisable.

Des jeux de test publics permettraient aux équipes de sécurité de reproduire les résultats avec leur propre configuration. Une évaluation indépendante aurait plus de poids qu’un scénario sélectionné par un fournisseur.

Le troisième signal est l’adoption opérationnelle au sein des environnements Databricks gérés. Il faut surveiller l’élargissement de la prise en charge des politiques, une télémétrie plus claire, des contrôles d’administration et des intégrations documentées avec les classifications de données d’entreprise.

L’adoption doit produire des résultats mesurables. Les équipes doivent savoir à quelle fréquence les politiques se déclenchent, quelles combinaisons de capacités provoquent une escalade, et si les examinateurs annulent ou approuvent la décision.

Ces signaux comptent parce que le problème de sécurité sous-jacent grandira avec l’utilité des agents. De meilleurs agents réaliseront des tâches plus longues, utiliseront davantage d’outils et franchiront davantage de limites de confiance sans supervision constante.

L’approche de Databricks, innocente jusqu’à combinaison, propose un principe de conception crédible : autoriser les composants utiles tout en bloquant leur composition dangereuse. Elle déplace l’attention de la question de savoir si un modèle comprend une attaque vers celle de savoir si le système environnant permet à l’attaque d’aller jusqu’à son terme.

Les développeurs doivent cartographier quelles sessions peuvent accéder à des données privées, ingérer du contenu contrôlé par un attaquant et communiquer à l’extérieur. Les acheteurs en entreprise doivent demander si une plateforme suit ces conditions dans le temps, à travers les outils et entre les workers délégués.

Si les trois restent disponibles sans application contextuelle, un écran d’approbation soigné ne résout pas le problème. La prochaine étape pratique consiste à identifier où la troisième capacité entre dans chaque flux de travail, puis à placer une politique testable à cette frontière.