L’avertissement zero trust de Vishal Sharma : les agents IA doivent prouver leur contrôle

Vishal Sharma remet en cause une promesse de sécurité bien connue : demander à des agents IA de respecter des règles ne prouve pas que ces règles ont réellement été respectées. L’avertissement zero trust de Vishal Sharma concerne les agents IA, des systèmes qui utilisent des modèles et des outils logiciels pour agir vers un objectif. Le chercheur de la Queen’s University Belfast demande quelles preuves subsistent lorsqu’un agent affirme avoir supprimé des informations, respecté une restriction ou accompli une tâche autorisée.

Cet argument pousse les acheteurs en entreprise et les développeurs à distinguer la coopération d’un contrôle effectivement applicable. Un agent qui déclare avoir réussi fournit une réponse. Un système qui enregistre indépendamment l’opération concernée fournit un élément que les acheteurs peuvent examiner. Ces résultats méritent des niveaux de confiance différents.

La référence historique est l’architecture zero trust du NIST, une approche de sécurité qui rejette la confiance automatique fondée sur l’emplacement réseau ou la propriété. Le défi soulevé par Sharma porte sur la manière dont ce principe résiste lorsque des agents interprètent des informations, délèguent du travail et transportent du contexte d’une tâche à l’autre. Le compromis central est concret : une autonomie utile nécessite des accès, tandis qu’une autonomie responsable nécessite des limites qui restent effectives lorsque le modèle commet une erreur.

L’avertissement zero trust de Vishal Sharma commence par l’absence de preuves

L’analyse de la sécurité des agents de Sharma, soutenue par son université et publiée par IEEE Spectrum, interroge la manière dont les organisations vérifient le comportement des agents. Ce soutien institutionnel est important : les lecteurs devraient y voir une contribution d’établissement au débat, plutôt qu’une validation indépendante d’un système de sécurité commercial.

L’article décrit des agents opérant sous la direction d’un orchestrateur, un logiciel qui coordonne leurs tâches. Il soulève la possibilité que des prompts ultérieurs récupèrent des informations qu’un agent avait auparavant reçu l’instruction d’oublier. Il rapporte également une expérience interne de la Queen’s University Belfast dans laquelle des attaques de désauthentification orchestrées par des agents ont pris deux à trois secondes. Les attaques de désauthentification interrompent la connexion sans fil authentifiée d’un appareil.

La contribution la plus solide de l’article est son exigence de preuves, tandis que ses affirmations expérimentales nécessitent davantage de détails avant de pouvoir étayer des conclusions générales.

Le compte rendu publié ne fournit pas suffisamment d’éléments méthodologiques pour établir une référence générale en matière de vitesse d’attaque. Sa discussion sur la récupération de contexte n’établit pas non plus que des informations physiquement effacées ont été reconstruites. Le fait que des informations restent accessibles quelque part dans un flux de travail pose un problème différent de la récupération de données qui n’existent plus.

Cette distinction devrait orienter la réponse. Une déclaration concernant l’oubli nécessite un objet défini : un message, un enregistrement stocké, un document accessible ou le comportement appris d’un modèle. Sans cette définition, les organisations ne peuvent pas s’accorder sur ce que serait une suppression réussie.

Prenons un assistant hypothétique de profilage client. Un utilisateur retire son autorisation d’utiliser un entretien antérieur. L’assistant confirme qu’il ne tiendra plus compte de cet entretien, puis produit une recommandation ressemblant à son évaluation précédente. Cette ressemblance ne suffit pas à établir si l’assistant a récupéré l’entretien, conservé un résumé ou atteint indépendamment la même conclusion.

Une enquête devrait examiner ce que le système a réellement conservé et consulté. L’explication générée pourrait fournir un indice, mais elle ne réglerait pas la question à elle seule. Le comportement contesté concerne les mécanismes entourant la réponse, notamment les enregistrements restés disponibles.

Pour les acheteurs, cela modifie les preuves qu’il convient de demander. Une démonstration soignée peut montrer qu’un assistant répond correctement durant une session préparée. Un test contrôlé d’échec peut révéler si une restriction résiste à une demande imprévue. Ces démonstrations répondent à des questions d’achat différentes.

La valeur d’actualité réside dans ce changement d’accent. Sharma attire l’attention sur le moment où une promesse verbale devient une affirmation opérationnelle. Dès lors qu’un agent traite des informations sensibles ou des actions importantes, ce point mérite un examen explicite.

Cela crée également une norme plus équitable pour les fournisseurs. Un prestataire ne devrait pas avoir à promettre que son modèle ne produira jamais de réponse indésirable. Il devrait pouvoir expliquer les limites de son déploiement et fournir des preuves adaptées à ces limites.

Le zero trust reste applicable, mais l’identité ne peut pas établir l’intention

L’architecture zero trust du NIST, publiée en août 2020, concentre la protection sur les ressources au lieu de présumer qu’un réseau interne est digne de confiance. Elle distingue l’authentification, qui établit l’identité, de l’autorisation, qui détermine les accès permis.

Ce cadre ne devient pas obsolète parce qu’un logiciel peut interpréter le langage naturel. Il fournit un point de départ utile : la présence d’un agent au sein d’une organisation ne justifie pas automatiquement l’accès à ses ressources.

Le problème analytique consiste à déterminer quelle autorité un agent authentifié devrait recevoir pour la tâche en cours.

Imaginons un assistant autorisé à préparer une comparaison de fournisseurs. La lecture de propositions approuvées correspond à cette mission. L’envoi à un fournisseur d’une note de négociation confidentielle soulève une question distincte, même si ce même assistant possède la capacité technique d’envoyer des e-mails.

Une authentification réussie établirait quel compte a tenté l’envoi. Elle n’établirait pas, à elle seule, que l’utilisateur voulait précisément cette divulgation. La discussion sur la sécurité doit donc examiner l’action demandée et l’autorité qui la soutient.

C’est là que les déploiements d’agents compliquent des décisions d’entreprise familières. Une instruction humaine peut décrire un résultat sans énumérer chaque opération intermédiaire. « Prépare la comparaison » laisse place à l’interprétation. L’organisation doit néanmoins décider quelles opérations cette interprétation peut autoriser.

Une question d’achat raisonnable s’ensuit : que se passe-t-il lorsque l’assistant choisit une étape inutile ? La réponse devrait identifier le composant chargé d’autoriser ou de refuser l’opération. Une promesse selon laquelle l’assistant choisit habituellement des étapes pertinentes porte sur le comportement, alors que l’acheteur interroge l’autorité.

Le même raisonnement s’applique à la délégation. Supposons qu’un assistant coordinateur demande à un autre agent de rechercher l’historique d’un fournisseur. Cette demande emporte-t-elle l’autorisation d’examiner des contrats confidentiels ? Autorise-t-elle une délégation ultérieure ? Quelle restriction d’origine reste visible au service destinataire ?

Il s’agit de questions hypothétiques de conception, et non de conclusions selon lesquelles chaque plateforme d’agents gère mal la délégation. Leur objectif est de révéler les hypothèses avant que les acheteurs n’accordent de larges accès. Un déploiement peut sembler ordonné tout en laissant son modèle d’autorité mal défini.

Les équipes de sécurité sont par conséquent confrontées à un problème de périmètre. Évaluer un agent comme une application unique pourrait négliger des différences importantes entre lire, modifier, envoyer et supprimer. Évaluer manuellement chaque opération inoffensive créerait une autre charge. L’évaluation utile se situe entre ces extrêmes.

Les équipes produit devraient donc s’attendre à des questions sur la relation entre l’intention de la tâche et l’autorisation exécutable. Un client qui demande cette relation sollicite une propriété du système, pas simplement une instruction supplémentaire pour le modèle.

L’avertissement zero trust de Vishal Sharma est particulièrement utile lorsqu’il est lu sous cet angle. Il incite les organisations à rendre leurs hypothèses vérifiables sans prétendre que tous les principes existants de contrôle d’accès ont échoué.

La mémoire rend le compromis plus difficile à ignorer

Les recommandations d’OWASP sur la sécurité des agents IA abordent l’isolation de la mémoire, l’expiration, le traitement des données sensibles et l’autorisation en dehors du contexte d’un agent. Le contexte désigne les informations fournies au modèle pendant qu’il génère une réponse.

Ces recommandations identifient également l’empoisonnement de la mémoire, soit la persistance d’informations malveillantes qui influencent des comportements ultérieurs. Cette préoccupation relie les informations conservées aux actions futures, plutôt que de traiter chaque réponse comme un événement isolé.

Pour les acheteurs en entreprise, le compromis non résolu porte sur la quantité d’historique utile qu’un assistant devrait conserver et sous quelle autorité continue.

Considérons un flux de recherche hypothétique qui transforme des entretiens en note de projet. Les notes historiques aident l’assistant à éviter de répéter des questions et à préserver des décisions. Ces avantages constituent une raison légitime de conserver des informations. Ils rendent aussi les demandes de retrait plus complexes à évaluer.

Supposons qu’une personne interrogée demande le retrait d’une déclaration sensible. L’acheteur doit savoir quelle promesse le produit offre. Supprimer la transcription d’origine, l’exclure des recherches ultérieures et réviser une note dérivée sont des résultats distincts.

Un contrat significatif préciserait le résultat applicable. Une démonstration testerait ensuite directement ce résultat. Demander à l’assistant s’il se souvient de la déclaration fournirait une preuve plus faible, car cette question repose sur la même interface dont le comportement est contesté.

Cette distinction compte également pour le travail ordinaire de gestion des connaissances. Une personne choisissant une base de connaissances personnelle doit comprendre comment la collecte, la récupération et le retrait s’articulent. La commodité ne répond pas à ces questions, et une catégorie de produit n’établit pas une garantie de sécurité.

Il existe aussi une tension entre l’enquête et la minimisation. Une organisation peut vouloir conserver suffisamment d’historique pour expliquer une recommandation importante. Elle peut simultanément vouloir éviter de garder des informations personnelles inutiles. Aucun de ces objectifs ne disparaît parce qu’un assistant effectue le travail.

Une enquête hypothétique illustre la difficulté. Un client conteste une recommandation après la suppression de l’entretien sous-jacent. Les enquêteurs ont besoin d’un compte rendu des éléments autorisés qui ont éclairé la décision. Conserver indéfiniment chaque document brut compromettrait la promesse de retrait ; ne rien conserver entraverait l’enquête.

L’implication éditoriale est que la « mémoire » mérite un langage produit plus précis. Les acheteurs devraient attendre des descriptions des enregistrements concernés et des garanties attachées à chacun. Un seul bouton intitulé « oublier » laisse trop de place à des attentes incompatibles.

La pression commerciale pèse sur les fournisseurs qui vendent une continuité entre les projets. Plus cette continuité devient utile, plus ses limites deviennent importantes pour un client évaluant un travail sensible. La valeur d’une fonctionnalité de mémoire et ses exigences de gouvernance grandissent ensemble.

La question de Sharma dépasse donc un scénario d’attaque inhabituel. Elle révèle un enjeu d’achat fondamental : une organisation peut-elle vérifier le traitement des informations une fois que la conversation est passée à autre chose ?

Les recherches sur les navigateurs montrent pourquoi l’architecture change les enjeux

Les chercheurs de l’University of Washington Franziska Roesner et David Kohlbrenner ont examiné les frontières d’origine des navigateurs dans sept navigateurs agentiques. Leurs travaux concernent la same-origin policy, une règle de navigateur qui sépare des sites web mutuellement non fiables.

Son compte rendu d’avril 2026 décrit des expériences menées fin janvier et début février. Il rapporte une démonstration d’attaque inter-origines impliquant ChatGPT Atlas en Agent Mode. Pour plusieurs autres produits, il identifie des conditions préalables à une attaque plutôt que des attaques équivalentes menées à terme.

Le scénario dépend de conditions précises, notamment d’une injection de prompt réussie, visant à amener un agent à traiter un contenu non fiable comme des instructions. Les versions et configurations testées sont importantes. Ces résultats ne doivent pas être transformés en affirmation non étayée concernant toutes les versions actuelles de navigateurs.

La question architecturale plus large est de savoir si l’accès d’un assistant crée une voie que le code ordinaire d’un site web ne posséderait pas.

Pour les acheteurs, cette question offre une comparaison plus utile qu’un classement générique de l’intelligence des modèles. Un assistant performant peut fonctionner dans des limites d’accès restreintes. Un autre déploiement peut exposer des informations plus étendues tout en s’appuyant davantage sur le jugement de l’assistant.

Ces configurations entraînent des décisions d’achat différentes, même lorsque leurs démonstrations paraissent similaires. Les deux pourraient résumer une page avec succès. Seul un examen plus approfondi révélerait quelles informations supplémentaires chaque assistant peut atteindre durant cette tâche.

Prenons l’exemple hypothétique d’un employé demandant un résumé d’une page publique d’un fournisseur. Le résultat attendu concerne cette page. Si le flux de travail permet également l’accès à des documents professionnels privés, les évaluateurs doivent comprendre pourquoi cet accès existe et ce qui en limite l’usage.

La demande de l’employé fournit un point de référence utile. Elle définit l’objectif commercial au regard duquel l’accès supplémentaire peut être évalué. Un résumé réussi ne répond pas à la question de savoir si le système a exposé davantage d’informations que ne l’exigeait la mission.

C’est aussi pourquoi les comparaisons doivent employer un langage prudent. Des chercheurs qui identifient une voie possible vers un préjudice ont établi un élément qui mérite d’être examiné. Ils n’ont pas nécessairement établi une attaque réussie contre chaque produit partageant une caractéristique de conception.

Un acheteur devrait appliquer la même rigueur aux réponses des fournisseurs. Un exemple corrigé peut fermer une voie démontrée sans établir que toutes les voies associées ont disparu. À l’inverse, un résultat de recherche plus ancien ne doit pas être automatiquement présenté comme une vulnérabilité non résolue aujourd’hui.

La leçon méthodologique du débat actuel est la suivante. Les affirmations de sécurité deviennent plus informatives lorsqu’elles identifient la limite testée, les conditions impliquées et le résultat observé. Les seuls noms de produits ne peuvent pas porter cette explication.

Cela soutient la demande de preuve de Sharma tout en ajoutant une limite importante. Les éléments de preuve doivent rester liés au système et aux circonstances qui les ont produits. Les étendre davantage exige des tests supplémentaires, pas une rhétorique plus affirmée.

Un Meilleur Comportement des Modèles Ne Résout Pas la Question du Confinement

Le compte rendu d’Anthropic de novembre 2025 sur les défenses contre l’injection de prompt décrit l’entraînement, les systèmes de détection et les tests adversariaux pour l’utilisation du navigateur. L’entreprise reconnaît explicitement que les agents de navigation restent vulnérables.

Son analyse de mai 2026 du confinement des agents distingue les défenses du modèle des restrictions imposées à l’environnement dans lequel un agent opère. Le confinement consiste à limiter ce qu’un système peut atteindre ou faire. Anthropic décrit l’utilisation de limites environnementales parallèlement à des mesures visant à améliorer le comportement du modèle.

Il s’agit de récits de fournisseur sur son approche. Ils établissent la justification de sécurité déclarée par l’entreprise, plutôt qu’une preuve indépendante que chaque déploiement atteint la protection recherchée.

La comparaison importante porte sur la réduction de la probabilité d’une erreur et la limitation de ses conséquences lorsqu’elle se produit.

Un assistant documentaire hypothétique rend cette distinction concrète. Un meilleur jugement pourrait l’aider à rejeter une instruction trompeuse contenue dans une proposition. Une restriction d’accès pourrait l’empêcher d’obtenir un document confidentiel sans lien, quelle que soit son interprétation de cette instruction.

Ces résultats répondent à des questions distinctes. Le client souhaite un comportement raisonnable pendant le travail légitime. Il souhaite également une réponse défendable sur ce qui se passe en cas d’échec. Une évaluation approfondie devrait examiner les deux.

Cela crée un défi pratique pour les présentations destinées aux achats. Les démonstrations de modèles sont faciles à comprendre parce qu’elles montrent un comportement visible. Les restrictions environnementales peuvent sembler moins impressionnantes jusqu’à ce qu’un évaluateur demande au système de franchir une limite interdite.

Une démonstration convaincante rendrait visible la tentative de franchissement. Les évaluateurs pourraient alors examiner ce qui l’a bloquée, quelles preuves ont subsisté et si la mission légitime pouvait se poursuivre. Le refus lui-même ne serait qu’une partie du résultat.

L’évaluation devrait également prendre en compte le coût des restrictions. Un assistant très limité pourrait exiger des informations supplémentaires de l’utilisateur ou ne pas achever une tâche par ailleurs raisonnable. Cela ne rend pas la restriction erronée. Cela fait de son effet opérationnel un élément de la décision d’achat.

De même, des interruptions fréquentes ne constituent pas automatiquement la preuve d’une sécurité supérieure. Une interruption mérite l’attention lorsqu’elle aide une personne à comprendre et autoriser une conséquence importante. Une demande d’approbation vague peut laisser la décision sous-jacente tout aussi peu claire.

La question utile pour l’acheteur est donc précise : quelle action proposée attend l’autorité de qui, et qu’est-ce qui change exactement après l’approbation ? La réponse doit rester compréhensible pour une personne responsable du résultat commercial.

Ce cadre évite une opposition artificielle entre des modèles plus intelligents et des limites plus solides. Les clients bénéficient des deux, mais devraient demander aux fournisseurs d’expliquer la contribution de chacun. L’amélioration dans un domaine ne démontre pas une amélioration dans tous les autres.

Il renforce également la pression concurrentielle. Les fournisseurs qui vendent une autonomie plus étendue ont besoin de preuves proportionnées à l’autorité que demandent leurs produits. Cette charge augmente avec les conséquences d’une action erronée.

L’avertissement de Vishal Sharma sur le zéro confiance s’inscrit dans ce débat sans le trancher. La question est de savoir si le déploiement fournit une description crédible du contrôle lorsque le comportement coopératif ne suffit plus.

Les Prochaines Preuves Devraient Venir de Tests d’Échec

Au cours des trois prochains mois, les signaux les plus utiles concerneront la reproductibilité, l’application des contrôles et le comportement dans des conditions réalistes d’échec. Il s’agit de points de vigilance éditoriaux, et non d’engagements de publication annoncés.

Les preuves les plus solides expliqueront ce qui a échoué, ce qui est resté protégé et si le travail légitime a tout de même été achevé.

Premièrement, surveillez un compte rendu reproductible de l’expérience de Queen’s University Belfast. Une publication plus complète identifierait idéalement l’équipement, la configuration, la méthode de chronométrage et la référence utilisés pour évaluer la vitesse d’attaque rapportée.

Ces éléments renforceraient l’affirmation expérimentale si des équipes indépendantes obtenaient des résultats comparables dans les conditions indiquées. Un résultat plus restreint resterait néanmoins instructif. Il aiderait les lecteurs à distinguer une observation particulière en laboratoire d’une affirmation générale sur les attaques assistées par agents.

La même norme s’applique à la récupération de contexte. Un test utile définirait quelles informations ont été supprimées, où elles avaient existé et quelles voies de récupération restaient disponibles. Sans ces détails, une recollection apparente laisse trop d’explications possibles.

Deuxièmement, surveillez les sorties de produits qui facilitent l’inspection des limites d’autorité. Le signal pertinent est une modification documentée associée à une restriction vérifiable. Un nouveau libellé de sécurité, à lui seul, ne fournit pas cette preuve.

Par exemple, une sortie hypothétique pourrait démontrer qu’un assistant peut préparer un message externe tandis qu’un composant distinct contrôle sa transmission. Les évaluateurs devraient néanmoins examiner le destinataire, le contenu et les conditions d’autorisation couverts par cette restriction.

De tels éléments renforceraient l’idée que les fournisseurs transposent des principes de sécurité généraux en contrôles déployables. Une sortie qui ajouterait simplement une instruction supplémentaire apporterait moins de soutien aux affirmations concernant des limites appliquées indépendamment.

Troisièmement, surveillez les évaluations indépendantes qui testent la récupération parallèlement à la résistance aux attaques. Bloquer une opération indésirable est utile. Les acheteurs doivent aussi savoir si le système peut se rétablir sans répéter la tentative, perdre un travail autorisé ou exiger une intervention excessive.

Une évaluation hypothétique pourrait comparer la même mission avant et après une restriction d’accès. Le résultat devrait décrire à la fois les actions interdites et l’achèvement légitime. Sinon, un système qui accomplit peu pourrait paraître sûr pour une raison peu utile.

Des résultats montrant des dommages limités et un travail autorisé mené à bien renforceraient les arguments en faveur d’une autonomie pratique. Des résultats montrant qu’un achèvement utile exige un accès étendu et mal expliqué révéleraient un compromis persistant.

Ces signaux sont importants, car l’argument actuel peut autrement devenir circulaire. Les chercheurs demandent une vérification. Les fournisseurs décrivent des protections. Les acheteurs reçoivent des assurances sans description commune de ce que couvrent ces assurances.

Des preuves plus précises permettraient un désaccord plus restreint et plus productif. Un déploiement pourrait convenir à la rédaction et à la recherche, tandis qu’un autre prendrait en charge des opérations à conséquences importantes. La justification devrait identifier ce que chaque système peut établir au sujet de son comportement.

Pour les développeurs, l’implication immédiate consiste à rendre les affirmations de sécurité vérifiables avant d’élargir les responsabilités d’un agent. Pour les acheteurs d’entreprise, il s’agit de relier les preuves demandées à une conséquence commerciale précise. Pour les travailleurs du savoir, il s’agit de comprendre l’autorité associée à un assistant avant de lui confier un travail sensible.

Avant votre prochain projet pilote d’agent, choisissez une action contestée et définissez les preuves qui permettraient de la trancher. Envisagez un destinataire non autorisé, un document retiré ou une demande dépassant la mission initiale. Demandez au fournisseur de montrer ce qui se passe, où la restriction opère et quelle trace subsiste ensuite. Évaluez ensuite si la tâche autorisée est toujours achevée. Considérez la démonstration comme une preuve concernant ce déploiement et cette configuration, avec des limites clairement énoncées. L’avertissement de Vishal Sharma sur le zéro confiance fournit une question de départ utile pour cette conversation : lorsqu’un assistant affirme avoir respecté les règles, que quelqu’un d’autre peut-il réellement vérifier ?