Thales Google Cloud AI Security ajoute des contrôles, mais l’autonomie augmente les enjeux

Thales a élargi son partenariat avec Google Cloud le 28 septembre, en ajoutant des contrôles de sécurité pour les agents d’IA malgré des questions non résolues sur la fiabilité avec laquelle les garde-fous peuvent contenir les systèmes autonomes. L’intégration de sécurité Thales Google Cloud AI relie Thales AI Security Fabric à Gemini Enterprise. Elle cible les interactions entre les utilisateurs, les agents, les modèles, les données d’entreprise et les outils externes.

Cette annonce reflète une évolution plus large de l’IA en entreprise. Les assistants généraient principalement des réponses que les personnes pouvaient examiner. Les agents peuvent désormais sélectionner des outils, récupérer des dossiers sensibles, appeler des API et modifier des systèmes métier. Une instruction malveillante ou une autorisation excessive peut donc provoquer un incident opérationnel, et non simplement une mauvaise réponse.

Google Cloud présente déjà Agent Gateway comme un point de contrôle pour les connexions entre les agents et les outils. Thales ajoute l’inspection, l’application des politiques et la détection des menaces autour de ces connexions. Le partenariat se retrouve ainsi sur le même terrain stratégique que Microsoft, Zscaler, Palo Alto Networks et d’autres fournisseurs qui cherchent à définir la couche de sécurité des agents d’entreprise.

La question centrale n’est plus de savoir si les agents d’IA nécessitent une protection supplémentaire. Les recommandations gouvernementales et la recherche indépendante en sécurité ont tranché ce point. La vraie question est de savoir si une couche d’exécution intégrée peut contraindre les agents de manière cohérente sans les rendre trop lents, coûteux ou limités pour justifier leur déploiement.

Ce que change l’intégration de sécurité Thales Google Cloud AI

Le partenariat rapproche la sécurité des agents du moment où un système d’IA lit des données, choisit un outil ou tente une action.

Selon l’annonce de sécurité, Thales AI Security Fabric s’intégrera à Google Cloud Gemini Enterprise. Thales affirme que le système combiné peut appliquer des politiques de visibilité, de gouvernance et de sécurité aux communications impliquant les utilisateurs, les agents, les modèles, les outils et les informations d’entreprise.

La couverture prévue comprend plusieurs étapes d’un flux de travail agentique. Le système peut inspecter le trafic entrant dans un agent, observer les échanges entre l’agent et son modèle, et surveiller les appels vers des outils externes. Il vise également à imposer des limites aux informations auxquelles un agent peut accéder et aux actions qu’il peut effectuer.

Ces distinctions comptent, car un agent n’est pas une session de modèle isolée. C’est une chaîne de décisions, d’identifiants, de sources de données et d’interfaces logicielles. Chaque transfert crée un nouvel endroit où un attaquant, une erreur de configuration ou une décision peu fiable du modèle peut modifier le résultat.

Thales identifie l’injection de prompts, la fuite de données, les sorties non sûres, les actions non autorisées et la communication entre agents comme des risques majeurs. L’injection de prompts se produit lorsque des instructions hostiles intégrées à un contenu manipulent le comportement d’un modèle. Un e-mail, un document, un site web ou la réponse d’un outil peuvent contenir ces instructions sans que l’utilisateur ne les remarque.

La réponse proposée par le partenariat est une couche d’application unifiée. Thales affirme que sa plateforme peut détecter les menaces spécifiques à l’IA, maintenir une visibilité sur le comportement des agents et bloquer les actions qui enfreignent la politique de l’organisation. L’entreprise présente également les enregistrements centralisés comme un soutien aux examens de conformité et aux enquêtes sur les incidents.

Prenons l’exemple de l’assurance fourni par Thales. Un agent autorisé à aider au règlement de sinistres pourrait exploiter des informations personnelles provenant de sources non approuvées. Même si le calcul de l’indemnisation semble raisonnable, le flux de travail peut engendrer des problèmes de confidentialité, d’équité et de conformité.

Un contrôle d’exécution pourrait examiner la source de données demandée, le rôle attribué à l’agent et l’action proposée avant d’autoriser la poursuite du flux de travail. Il pourrait refuser la requête, consigner la tentative d’accès ou exiger une approbation humaine. Il s’agit d’un modèle de sécurité différent du simple filtrage du prompt soumis par un utilisateur.

L’intégration s’appuie également sur l’architecture plus large de Google Cloud pour les agents. Son écosystème Agent Gateway offre une connectivité gouvernée pour le trafic utilisateur-agent, agent-agent et agent-outil. Google a décrit la passerelle comme un point de contrôle ouvert pouvant fonctionner avec plusieurs fournisseurs de sécurité.

Thales ne remplace donc pas les contrôles natifs de Google Cloud. Il fournit une couche spécialisée d’inspection et d’application au sein d’une architecture plus large. Sa valeur dépendra de la quantité de contexte supplémentaire qu’elle peut analyser et de la fiabilité avec laquelle elle peut intervenir avant qu’une activité risquée n’atteigne un système métier.

Pourquoi les agents d’IA ont besoin de contrôles allant au-delà des garde-fous des modèles

Une réponse sûre d’un modèle ne garantit pas un flux de travail sûr lorsque le système peut détenir des identifiants et agir sans examen humain immédiat.

La sécurité traditionnelle de l’IA générative se concentre souvent sur le contenu. Les organisations cherchent à prévenir les réponses nuisibles, l’exposition de données confidentielles ou les prompts inappropriés. Ces préoccupations restent importantes, mais les agents introduisent une autre catégorie de risques : des actions logicielles ayant des conséquences réelles.

Un agent peut recevoir une instruction, élaborer un plan, sélectionner un outil et exécuter une transaction. Il peut envoyer un message, modifier un dossier client, approuver un remboursement, modifier du code source ou lancer un changement d’infrastructure. Une erreur peut se propager avant qu’une personne ne voie le raisonnement intermédiaire.

Cette différence explique pourquoi l’autorisation à l’exécution devient centrale. Une politique devrait évaluer non seulement ce que dit l’agent, mais aussi l’identité qu’il utilise, la ressource qu’il demande et si cette action correspond à sa tâche attribuée. La décision peut devoir être prise à nouveau chaque fois que le flux de travail change de direction.

Le problème devient plus difficile lorsque les agents collaborent. Un agent peut recueillir des informations tandis qu’un autre formule une recommandation et qu’un troisième exécute une action. Un composant compromis peut transmettre un contexte ou des requêtes manipulés au reste de la chaîne.

Thales indique que ses contrôles couvriront ces interactions entre agents. Cette promesse répond à une lacune importante, mais les détails de mise en œuvre détermineront sa valeur. Les équipes de sécurité doivent savoir comment les identités sont vérifiées, comment les autorisations déléguées sont représentées et comment les politiques accompagnent une tâche à travers plusieurs agents.

Le NIST a identifié le même problème. Son analyse de sécurité des agents de mai 2026 a constaté un large consensus sur le fait que les agents introduisent de nouvelles menaces. Les répondants ont également indiqué que les pratiques de cybersécurité familières restent utiles, mais nécessitent une adaptation aux systèmes agentiques.

L’identité illustre cette adaptation. Une application conventionnelle fonctionne souvent via un compte de service stable aux fonctions prévisibles. Un agent peut élaborer un plan de manière dynamique et choisir parmi plusieurs outils selon un contexte changeant.

Accorder à cet agent des identifiants étendus le rend utile, mais accroît les dommages potentiels liés à une manipulation. Restreindre à l’avance chaque autorisation réduit le risque, mais peut empêcher l’agent d’accomplir un travail légitime. Les équipes de sécurité doivent équilibrer une autonomie utile avec un périmètre d’impact strictement limité.

Les enregistrements d’audit représentent un autre défi. Journaliser un appel d’outil ne suffit pas si les enquêteurs ne peuvent pas déterminer quel utilisateur a lancé la tâche, quelles informations ont influencé l’agent ou pourquoi une action a reçu une autorisation. Des enregistrements utiles doivent relier l’intention humaine, l’identité de l’agent, l’accès aux données et la modification de système qui en résulte.

L’approche de sécurité Thales Google Cloud AI répond à ce problème par une visibilité sur l’ensemble du flux de travail. En principe, une couche partagée peut corréler des activités qui apparaissent autrement dans des journaux distincts de modèles, d’identité, d’API et d’applications.

Cette visibilité peut aider les équipes d’opérations de sécurité à reconnaître un comportement inhabituel. Un agent qui lit habituellement des données de ventes régionales devrait susciter un examen s’il demande soudainement des dossiers d’employés ou un point de terminaison externe inconnu. Le contexte comportemental est précieux lorsque des règles statiques ne peuvent anticiper toutes les séquences valides.

Cependant, la visibilité n’est pas le confinement. Un tableau de bord peut expliquer un incident après que les dommages se sont produits. L’affirmation plus forte est que les politiques peuvent arrêter l’action non sûre en temps réel, sans bloquer les variations légitimes qui rendent les agents utiles.

L’application à l’exécution devient le principal champ de bataille concurrentiel

La concurrence stratégique oppose une sécurité intégrée à une plateforme cloud à des contrôles indépendants promettant des politiques cohérentes entre modèles, agents et outils.

Google Cloud construit un écosystème de partenaires autour d’Agent Gateway au lieu de s’appuyer sur un seul fournisseur de sécurité. Ses participants publiés incluent Thales, Zscaler, Exabeam, Silverfort, Cisco, CrowdStrike, Palo Alto Networks et d’autres. Chaque fournisseur traite une partie différente du flux de travail des agents.

Thales apporte la sécurité des applications et des API d’Imperva à cette structure. Sa couverture déclarée inclut le trafic client-agent, les échanges agent-modèle et les interactions avec des outils utilisant des interfaces telles que Model Context Protocol. MCP est un protocole qui permet aux applications d’IA de se connecter à des données externes et à des capacités logicielles.

Cette approche offre de la flexibilité aux acheteurs d’entreprise. Une entreprise peut utiliser l’infrastructure de Google et sélectionner des contrôles supplémentaires correspondant à ses opérations de sécurité existantes. Elle peut également réduire la pression consistant à dépendre entièrement des protections fournies par un fournisseur de modèles.

La contrepartie est la complexité. Plusieurs produits peuvent inspecter le même flux de travail sous des angles différents. Les équipes de sécurité doivent décider quel composant est responsable de l’identité, de la protection des données, de l’analyse comportementale, de l’autorisation et de la réponse aux incidents.

Des contrôles qui se chevauchent peuvent créer des lacunes aussi facilement que de la profondeur. Un produit peut approuver une requête en fonction de l’identité de l’agent, tandis qu’un autre ne dispose pas du contexte de la tâche nécessaire pour reconnaître un usage abusif. Un troisième peut enregistrer l’appel d’outil sans comprendre les données sensibles renvoyées.

Microsoft poursuit une voie plus intégrée verticalement. Sa stratégie de sécurité des agents relie l’identité, les politiques d’accès, la gouvernance des données et les applications de productivité. Microsoft Entra peut attribuer des identités aux agents, tandis que les politiques Purview régissent les informations sensibles dans l’environnement Microsoft.

Ce modèle offre une voie administrative plus claire aux organisations déjà centrées sur les services Microsoft. Il soulève aussi les préoccupations habituelles liées à la dépendance à une plateforme. Des contrôles optimisés pour les applications d’un fournisseur peuvent offrir une couverture moins cohérente lorsque les flux de travail traversent des clouds, des modèles et des outils tiers.

L’architecture de Google fondée sur les partenaires fait de l’ouverture un élément de sa proposition. Pourtant, cette ouverture transfère le travail d’intégration à la plateforme et à ses clients. Une politique n’est utile que si elle survit à chaque transfert et produit une décision assez rapidement pour le trafic de production.

Les fournisseurs indépendants font face à un défi connexe. Ils doivent prouver que leur couche supplémentaire offre plus qu’une console de surveillance de plus. Les acheteurs attendront des politiques applicables, des enquêtes exploitables et des preuves que les contrôles réduisent les risques sans perturber le travail courant.

Thales dispose d’une position crédible, car Imperva opère déjà autour des applications web et des API. Les flux de travail des agents utilisent bon nombre des mêmes interfaces. L’inspection du trafic existante, la gestion des bots et la protection des API peuvent fournir une base pour reconnaître les clients et contrôler les requêtes.

Le comportement des agents diffère encore du trafic applicatif conventionnel. Un agent valide peut effectuer une requête API techniquement valide dans un but inacceptable. Détecter cette distinction exige du contexte sur l’intention de l’utilisateur, l’autorité déléguée, la sensibilité des données et la séquence des actions antérieures.

C’est là que la pression concurrentielle dépasse la sécurité web établie. Les fournisseurs doivent interpréter le contexte opérationnel d’un agent sans dépendre de sa propre explication. Un modèle manipulé peut produire une justification convaincante pour un appel non sécurisé.

Les fournisseurs cloud disposent également d’un avantage informationnel. Ils exploitent le service de modèles, le plan d’identité, le réseau et la plateforme d’agents. Un partenaire doit recevoir suffisamment de télémétrie pour prendre des décisions précises tout en respectant la confidentialité des clients et les performances du système.

L’architecture la plus solide pourrait donc être en couches. Les contrôles cloud natifs peuvent imposer une identité et une isolation fondamentales, tandis que des produits spécialisés inspectent le comportement des applications et les mouvements de données sensibles. L’approbation humaine reste appropriée pour les décisions irréversibles ou à fort impact.

Cette concurrence ne sera pas tranchée par la liste de fonctionnalités la plus longue. Les entreprises jugeront la capacité de chaque architecture à gérer les environnements mixtes, les identités déléguées et le contexte incomplet. Elles examineront aussi si les équipes de réponse aux incidents peuvent reconstituer un workflow sans devoir assembler plusieurs journaux incompatibles.

La promesse de sécurité doit encore être prouvée en production

Thales et Google Cloud décrivent les bons points de contrôle, mais l’annonce n’établit pas avec quelle précision ni quelle constance ces contrôles fonctionnent sous pression adversariale.

Les entreprises n’ont publié dans cette annonce ni chiffres de déploiement, ni mesures de latence, ni évaluations indépendantes, ni taux détaillés de faux positifs. Elles ne citent pas non plus d’études de cas clients montrant que cette infrastructure intégrée bloque des attaques en production.

Cette absence n’invalide pas l’orientation du produit. Elle limite ce que l’on peut conclure du lancement. L’intégration doit être considérée comme une architecture de sécurité étendue, et non comme la preuve que les workflows agentiques sont désormais sûrs.

L’injection de prompt reste un test exigeant. Les résultats de red teaming publiés par le NIST en mars 2026 décrivent l’injection indirecte de prompt comme un détournement d’agent. Les attaquants placent des instructions hostiles dans du contenu externe qu’un agent traite ultérieurement.

Ces attaques exploitent une ambiguïté fondamentale. Un modèle reçoit à la fois des instructions légitimes et des informations non fiables sous des formes textuelles similaires. Il doit distinguer les données qu’il doit analyser des commandes qu’il doit suivre, même lorsque le contenu malveillant est conçu pour brouiller cette frontière.

Les politiques d’exécution peuvent limiter les dégâts. Une instruction injectée pourrait convaincre un agent de demander des dossiers confidentiels, mais une couche d’autorisation distincte peut tout de même refuser cette requête. Le contrôle n’a pas besoin de déterminer exactement pourquoi le modèle a pris cette mauvaise décision.

Cette séparation constitue l’une des idées les plus fortes du partenariat. Des limites déterministes sur l’accès aux données et l’utilisation des outils peuvent contenir les défaillances que les garde-fous au niveau du modèle ne détectent pas. Des identifiants à privilèges minimaux et des approbations humaines peuvent encore réduire l’impact.

Cependant, le moteur de politiques a besoin d’un contexte précis. Il doit savoir quel utilisateur a autorisé la tâche, quel objectif sert l’agent et quelles ressources sont nécessaires. Des politiques trop larges ou mal maintenues peuvent transformer une couche de contrôle techniquement avancée en passerelle permissive.

Les faux positifs créent l’échec inverse. Si un agent s’interrompt continuellement pour obtenir des approbations ou perd l’accès à des données de routine, les employés risquent de l’éviter. Les administrateurs pourraient assouplir les politiques jusqu’à ce que leur application n’offre plus de protection significative.

La latence compte également. Chaque étape d’inspection ajoute du temps de traitement. L’effet peut être modeste pour une interaction unique, mais significatif dans les workflows qui comprennent des dizaines de requêtes de modèles et d’appels d’outils. Les organisations ont besoin de mesures issues de déploiements multi-agents réalistes.

Le chiffrement et la confidentialité ajoutent une autre tension. Les outils de sécurité ont besoin d’une visibilité suffisante pour identifier les informations sensibles et les instructions malveillantes. Les clients voudront des explications claires sur les contenus inspectés, leur lieu de traitement, leur durée de conservation et les personnes qui peuvent y accéder.

Le problème dépasse un seul produit. Les risques liés aux agents de l’OWASP comprennent le détournement d’objectifs, le mauvais usage des outils, l’abus d’identité, l’empoisonnement de mémoire, la communication inter-agents non sécurisée et les défaillances en cascade. Aucun filtre de trafic unique ne résout toutes ces catégories.

L’empoisonnement de mémoire constitue un exemple utile. Un attaquant pourrait introduire des informations fausses ou malveillantes qu’un agent stocke pour une utilisation ultérieure. Un contrôle d’exécution pourrait inspecter l’entrée d’origine, mais l’effet nuisible peut apparaître des jours plus tard dans un workflow différent.

Les défaillances en cascade sont tout aussi difficiles. Un agent peut générer un résultat incorrect qui paraît fiable à un autre. Chaque appel d’outil individuel peut respecter la politique, tandis que le workflow global évolue vers une issue nuisible.

Les organisations ont donc besoin d’une défense en profondeur. Elles devraient combiner des autorisations restreintes, le sandboxing, des identités signées, une mémoire protégée, des outils validés, une surveillance continue et une revue humaine. Les tests de sécurité doivent couvrir des workflows complets plutôt que des réponses de modèles isolées.

Les recommandations gouvernementales renforcent cette position. Les orientations australiennes sur l’adoption des agents recommandent des points de contrôle humains, une surveillance continue, des autorisations minimales et plusieurs défenses qui se chevauchent. Elles conseillent également d’augmenter progressivement l’autonomie.

Thales AI Security Fabric peut devenir l’une de ces défenses. L’annonce ne justifie pas de le considérer comme l’ensemble du programme de sécurité. Les acheteurs devraient demander comment il interagit avec les systèmes d’identité, les contrôles de développement, la réponse aux incidents et les procédures d’approbation déjà en place.

Qui subit la pression à mesure que la sécurité des agents entre dans le workflow

Les fournisseurs de sécurité, les plateformes cloud et les acheteurs en entreprise subissent désormais la pression de transformer la gouvernance des agents, d’une politique écrite, en logiciel applicable.

Les fournisseurs cloud font face à l’attente la plus immédiate. Ils veulent que les clients fassent passer les agents des expérimentations aux opérations métier, mais l’adoption ralentit lorsque les équipes juridiques et de sécurité ne peuvent pas définir des limites acceptables. Une plateforme incapable de répondre à des questions élémentaires sur l’identité, l’accès et l’auditabilité aura du mal à prendre en charge des déploiements sensibles.

La réponse de Google Cloud consiste à faire d’Agent Gateway un point d’application commun et à l’entourer de partenaires spécialisés. Thales renforce cette stratégie en couvrant les interactions entre applications, API, modèles et outils au sein d’une même infrastructure de sécurité.

Thales doit démontrer que ce périmètre élargi reste gérable. Sa proposition de valeur repose sur sa capacité à offrir aux clients une vision cohérente de plusieurs couches techniques. Des politiques fragmentées ou des alertes redondantes réduiraient l’avantage de l’intégration.

Les fournisseurs de sécurité concurrents subissent la pression de démontrer une couverture tout aussi large. Protéger les prompts à eux seuls ne suffit plus. Les acheteurs ont besoin de contrôles pour les identifiants, l’exécution des outils, les mouvements de données, la mémoire, les messages inter-agents et les actions externes.

Les fournisseurs d’identité font également face à une nouvelle charge de travail. Les agents ont besoin d’identités distinctes, d’autorisations limitées, d’une propriété traçable et de cycles de vie gérables. Les agents temporaires ne devraient pas laisser d’identifiants permanents après la fin de leurs tâches.

Les propriétaires d’applications portent une autre responsabilité. Ils doivent définir les actions qu’un agent peut accomplir et dans quelles conditions. Les équipes de sécurité ne peuvent pas créer de politiques utiles sans les contributions opérationnelles des personnes qui comprennent le workflow.

Les développeurs devront exposer davantage de contexte structuré. Une couche de sécurité peut prendre de meilleures décisions lorsque les appels d’outils déclarent la tâche, l’utilisateur, la ressource demandée et l’effet prévu. Les prompts non structurés seuls offrent une base faible pour l’autorisation.

Les acheteurs en entreprise devraient résister à la tentation de considérer les achats comme la fin de la gouvernance. Installer une infrastructure de sécurité ne détermine pas le niveau d’autonomie acceptable. Les organisations doivent encore classer les cas d’usage, attribuer des responsabilités, définir des points d’escalade et tester des scénarios de défaillance.

Les cas d’usage à faible risque constituent un point de départ raisonnable. Un agent qui rédige un rapport à partir de documents internes approuvés a un rayon d’impact plus réduit qu’un agent qui envoie des messages ou modifie des comptes clients. Les autorisations ne devraient s’étendre qu’après qu’une évaluation a montré que le workflow reste contrôlé.

Les actions à fort impact méritent une approbation explicite. Les virements financiers, les modifications de production, les communications juridiques, les décisions de personnel et la divulgation de données sensibles ne devraient pas dépendre uniquement de la confiance d’un modèle. La revue humaine peut ralentir le workflow, mais cette friction reflète les conséquences d’une erreur.

Les travailleurs du savoir devraient s’y intéresser, car ces contrôles déterminent ce que les agents en entreprise peuvent voir et faire. Une meilleure sécurité peut permettre aux agents d’accéder à des informations internes utiles. Des contrôles mal conçus peuvent soit exposer trop de données, soit bloquer le contexte nécessaire à un travail précis.

Les employés auront également besoin de transparence. Ils devraient savoir lorsqu’un agent agit sous leur identité, quels dossiers il a consultés et si ses résultats déclenchent des changements externes. L’automatisation cachée rend difficile l’établissement des responsabilités lorsqu’un incident se produit.

Le changement plus large est organisationnel. La sécurité de l’IA passe d’une tâche d’évaluation des modèles à la gestion quotidienne des identités et des applications. Cela soumet les agents aux mêmes disciplines opérationnelles que les employés, les services, les fournisseurs et les déploiements logiciels.

Le partenariat de sécurité IA entre Thales et Google Cloud est important car il rend cette transition explicite. Son succès dépendra moins de l’annonce que de la capacité des entreprises à appliquer les contrôles sans créer une nouvelle couche de gouvernance déconnectée.

Trois signaux montreront si les contrôles fonctionnent

Le prochain test repose sur des preuves mesurables de déploiement, suivies d’une identité interopérable et d’une évaluation adversariale crédible.

Le premier signal sera une adoption en production accompagnée de résultats divulgués. Thales ou Google Cloud devraient publier des exemples clients expliquant le workflow, les autorisations, les comportements bloqués et la charge opérationnelle. Des preuves utiles incluraient la précision de détection, la fréquence des approbations, la latence et les résultats de réponse aux incidents.

Une vague déclaration affirmant qu’un client a déployé des agents sécurisés ne révélera pas grand-chose. L’étude de cas la plus solide montrerait comment un contrôle a bloqué une injection de prompt réaliste ou un appel d’outil non autorisé. Elle devrait aussi expliquer à quelle fréquence une activité légitime a été interrompue.

Si ces éléments apparaissent, ils renforceront l’affirmation selon laquelle l’application de contrôles à l’exécution peut soutenir des déploiements pratiques d’agents. Si les clients restent anonymes et les mesures privées, les acheteurs devraient considérer l’intégration comme prometteuse mais non prouvée.

Le deuxième signal sera une identité et une autorisation plus solides entre les plateformes. Le NIST a déjà mis en avant des questions relatives à l’identification des agents, à la délégation, à l’audit et à la non-répudiation. Le marché a besoin de moyens cohérents pour prouver quel agent agit, pour qui et avec quelle autorité.

L’interopérabilité sera importante, car les workflows d’entreprise restent rarement dans l’environnement d’un seul fournisseur. Un agent peut utiliser un modèle Google, interroger une base de données tierce, appeler une application Microsoft et invoquer un outil développé en interne.

Les politiques doivent accompagner ce workflow sans accorder à un identifiant réutilisable un accès étendu. Une autorisation de courte durée liée à une tâche spécifique réduirait le risque. Des enregistrements vérifiables devraient relier chaque action conséquente à la fois à l’agent et à l’humain ou au service responsable.

Les progrès des standards ouverts d’identité renforceraient la stratégie de partenariat de Google Cloud. Une fragmentation persistante favoriserait les plateformes étroitement intégrées qui contrôlent une plus grande partie de la pile technique.

Le troisième signal est celui des tests adversariaux indépendants. Thales et Google Cloud devraient tester le système combiné face à l’injection indirecte de prompts, aux sorties d’outils malveillantes, aux abus d’identifiants, à l’empoisonnement de mémoire et aux agents compromis. Les évaluations devraient mesurer le confinement, et pas seulement déterminer si une attaque a été détectée.

Un test utile devrait partir du principe que le modèle échoue. Il demanderait ensuite si les contrôles externes empêchent l’exfiltration de données ou une modification non autorisée du système. Cela permet de distinguer les promesses de sécurité du modèle de la valeur pratique, en matière de sécurité, de l’architecture qui l’entoure.

Des chercheurs indépendants devraient également examiner les contournements créés par les flux de travail multi-agents. Une politique peut bloquer une demande directe tout en autorisant plusieurs actions individuellement acceptables qui produisent le même résultat interdit.

Le lancement intervient au bon moment. Les entreprises souhaitent que les agents fassent plus que résumer des informations, tandis que les régulateurs et les équipes de sécurité exigent une responsabilité plus claire. Ces pressions font du contrôle à l’exécution une exigence plutôt qu’une fonctionnalité facultative.

Pourtant, la charge de la preuve augmente avec l’autonomie. Plus un agent reçoit d’autorité, plus les acheteurs ont besoin d’éléments démontrant que les identités, les autorisations, les politiques et les journaux d’audit fonctionnent ensemble en situation d’attaque.

Les organisations qui évaluent l’intégration de sécurité IA de Thales et Google Cloud devraient commencer par un flux de travail circonscrit et un budget de défaillance défini. Cartographiez chaque outil, identifiant, source de données et action irréversible. Testez ensuite si les contrôles empêchent les abus sans submerger les utilisateurs de demandes d’approbation.

La question décisive est pratique : le partenariat peut-il transformer la capacité étendue d’un agent en une action étroitement autorisée, à chaque évolution du flux de travail ? Des mesures en production, des identités interopérables et des tests indépendants apporteront la réponse.