Briser le cercle vicieux : comment Asana aborde la sécurité de l'IA agentique
L'IA agentique introduit une catégorie de risque de sécurité que le secteur n'a pas résolue. Voici comment Asana voit les choses, ainsi que les invariants de sécurité que nous appliquons à l'ensemble de nos fonctionnalités d'IA.
Le problème
Les systèmes d'IA agentique ne se contentent pas de répondre à des questions. Ils lisent des documents, effectuent des actions et coordonnent les outils. Plus ils peuvent en faire, plus leur surface d'attaque est grande.
Contrairement au code conventionnel, les LLM ont une propriété qui rend cela fondamentalement difficile : ils ne peuvent pas distinguer de manière fiable les instructions des données. Tout ce qui est fourni à un LLM atterrit dans le même flux, de sorte qu'une donnée soigneusement conçue peut détourner le modèle de la même manière qu'une instruction légitime le ferait. C'est la racine de l'injection de requête, ce que Simon Willison appelle « le péché originel » des applications basées sur les LLM.
Ce n'est pas théorique. Des chercheurs ont démontré cette classe d'attaque contre Microsoft 365 Copilot, le serveur MCP de GitHub, Slack AI et bien d'autres. Bruce Schneier l'a dit sans détour : le secteur ne dispose pas encore de défenses solides contre cette catégorie d'attaques.
Comment créer une IA agentique de manière responsable alors que l'industrie n'a pas encore compris les principes fondamentaux ?
Le trio mortel
Willison résume le risque principal en trois capacités qui, combinées, créent les conditions d'un préjudice :
L'accès aux données sensibles. L'agent peut lire des informations confidentielles ou privées.
Exposition à du contenu non fiable. L'agent traite des données qui peuvent contenir des instructions malveillantes cachées.
La capacité à communiquer vers l'extérieur. L'agent peut envoyer des informations à l'extérieur du système.
Une précision utile concernant le troisième volet : il s'agit en réalité de la capacité à créer des effets secondaires, et pas seulement de la communication sortante. L'exfiltration de données vers le serveur d'un attaquant est l'exemple classique, mais une instruction malveillante qui renomme discrètement tous les projets d'un espace de travail ou qui envoie du contenu sensible sur le mauvais canal interne constitue le même type de problème. Nous utilisons « communication externe » comme abréviation, mais c'est la version plus large contre laquelle nous nous défendons réellement.
Chacun des trois volets est gérable. Même deux ensemble le sont généralement. Mais lorsque les trois convergent, vous avez un chemin d'attaque viable.
L'indicateur important : briser l'une de ces étapes réduit considérablement le risque global. Nous n'avons pas besoin de résoudre parfaitement le problème de l'injection de requête. Personne n'y est parvenu. Nous devons nous assurer que les trois conditions ne peuvent pas coexister facilement.
Korny Sietsma s'appuie sur ce principe pour établir une correspondance entre le trio et les mesures d'atténuation telles que le sandboxing, la décomposition des tâches, le principe du moindre privilège et le principe de l'humain dans la boucle. Ce sont les éléments fondamentaux. La question est de savoir comment les concrétiser.
Contexte, points de contrôle et contrôles
Nous organisons notre réflexion autour de trois piliers qui correspondent directement au trio mortel. Chacun limite une étape.
Asana dispose de plusieurs surfaces d'IA. Les AI Teammates sont des participants agissants qui ont leurs propres adhésions et autorisations dans l'espace de travail. D'autres fonctionnalités d'IA fonctionnent comme l'utilisateur, la limite étant ce à quoi cet utilisateur peut déjà accéder. Les invariants ci-dessous se concentrent sur le cas agentique, où la surface est la plus grande, et nous indiquerons les différences de mise en œuvre selon la surface.
Contexte : gérer ce que l'IA peut voir
Volet Trifecta : accès aux données sensibles
Pour que l'IA agentique soit utile, elle a besoin de contexte. Le défi consiste à lui donner suffisamment d'informations pour qu'elle soit utile, sans pour autant lui donner carte blanche.
Notre invariant fondamental est le principe du moindre privilège, dont l'expression exacte dépend de la surface. Pour les AI Teammates, qui ont leur propre adhésion distincte de celle de tout utilisateur individuel, la limite est l'intersection des autorisations du collègue et de celles de l'utilisateur. Pour les fonctionnalités d'IA qui agissent en tant qu'utilisateur, la limite est simplement l'accès propre à cet utilisateur. Dans tous les cas, la même couche d'autorisation côté serveur qui régit toutes les autres interactions sur Asana régit l'accès de l'IA. Les fonctionnalités de l'IA ne bénéficient pas d'autorisations élevées. Elles fonctionnent dans le cadre du système de contrôle d'accès d'Asana, et non en dehors de celui-ci.
La définition du contexte ne se limite pas à la réglementation de l'accès aux données internes sur Asana ; elle englobe également les intégrations externes avec lesquelles un agent peut interagir. Alors que les intégrations nécessitent actuellement une autorisation explicite de l'utilisateur, nous développons des voies de contrôle granulaires et spécifiques à l'agent. Cela permet aux organisations de restreindre les privilèges d'intégration pour les AI Teammates qui gèrent des entrées à haut risque. Notre invariant architectural de base est clair : la limite de ce qu'une IA peut voir doit être dynamique et déterminée par les propriétaires des données, plutôt que d'être une valeur par défaut codée en dur dans le produit.
Même si un attaquant introduit des instructions malveillantes dans le contexte de l'IA, ce que l'IA peut réellement voir est limité par le même modèle d'autorisation que tout le reste.
Points de contrôle : filtrer ce que l'IA écoute
Étape du triptyque : exposition à du contenu non fiable
Il s'agit de l'étape la plus difficile. Sur une plateforme de gestion du travail, la majeure partie de ce que l'IA lit est du contenu généré par les utilisateurs : tâches, commentaires, documents joints. Une partie de ce contenu provient de l'extérieur de l'organisation. Vous ne pouvez pas refuser de le lire.
Nous établissons plutôt des points de contrôle : des endroits où nous distinguons l'intention fiable du contenu arbitraire, et où les humains peuvent intervenir si quelque chose semble anormal.
Traitement des instructions en fonction de la source. Les fonctionnalités d'IA étiquettent le contenu en fonction de la fiabilité de l'auteur et de la source, de sorte que le modèle peut donner plus de poids aux instructions provenant d'utilisateurs autorisés qu'à celles rencontrées dans du contenu arbitraire au cours du processus. Cela réduit la surface d'attaque pour l'injection de requêtes, mais ne la ferme pas ; le modèle lit toujours tout dans son contexte, et la garantie de sécurité est partielle plutôt qu'absolue. Nous abordons les limites de cette approche ci-dessous.
Journalisation et analyse forensique. Chaque appel de modèle est enregistré avec ses entrées, ses sorties, son acteur, le contexte de la fonctionnalité et les événements en aval, y compris les objets du graphe de travail touchés par une automatisation et les URL qui sont apparues dans la sortie. Nous envoyons automatiquement des alertes en cas de signaux opérationnels tels que des taux d'erreur et des pics de coûts. Pour les anomalies liées à la sécurité, ces mêmes journaux permettent une enquête a posteriori par des humains. Comme le fait remarquer Willison, même la détection basée sur des modèles, qui permet de détecter la plupart des attaques, serait insuffisante à elle seule ; la visibilité et la capacité d'enquête sont la base durable sur laquelle nous nous appuyons, et non le mur.
Conception « Human-in-the-loop ». Les fonctionnalités d'IA présentent leur travail pour examen par l'humain plutôt que d'effectuer des actions irréversibles en silence.
Décomposition des tâches et actions contrôlées. Les processus complexes sont divisés en étapes plus petites, et les actions disponibles pour les fonctionnalités d'IA sont intentionnellement limitées plutôt qu'ouvertes.
Aucune de ces mesures n'est infaillible à elle seule. Ensemble, elles forment une défense en profondeur.
Contrôles : restreindre les actions de l'IA
Le troisième pilier : la capacité à créer des effets secondaires
C'est au niveau du troisième pilier que la plupart des attaques se produisent dans le monde réel. Si un pirate parvient à convaincre une IA d'intégrer des données sensibles dans une URL, de les envoyer via une intégration ou de modifier un enregistrement sur lequel d'autres personnes comptent, l'attaque est réussie.
Nous investissons ici dans plusieurs catégories de contrôle :
Traiter le résultat du LLM comme non fiable. Le contenu généré ne bénéficie pas d'un bonus de confiance parce qu'il provient d'une IA Asana. Il suit les mêmes processus de validation et de rendu que n'importe quel autre contenu généré par les utilisateurs.
Approbation humaine obligatoire pour les actions à fort impact. Certaines catégories d'actions nécessitent toujours une approbation humaine explicite, quel que soit le degré de confiance de l'IA ou le caractère routinier de la demande. Pour les AI Teammates, cela inclut les actions qui élargissent les accès (modification des autorisations, ajout de membres) et les actions qui détruisent les données (suppressions). L'IA peut les proposer, mais elle ne peut pas les exécuter seule.
Barrières de protection pour le traitement des liens. Les URL externes dans le contenu généré par l'IA sont traitées avant d'atteindre un utilisateur. Les nouvelles URL qui n'apparaissaient pas dans l'entrée font l'objet d'un examen supplémentaire et apparaissent sous leur forme complète et non masquée plutôt que sous la forme d'un texte d'ancrage renommé, de sorte que l'IA ne peut pas être utilisée comme une arme pour déguiser un point de terminaison d'exfiltration en un simple « cliquez ici pour le résumé ».
Pas de HTTP sortant à usage général. Les fonctionnalités d'IA ne disposent pas d'une primitive ouverte de type « envoyer une requête à n'importe quelle URL ». Les intégrations externes passent par des canaux délimités avec leur propre autorisation.
Piste d'audit des actions. Chaque écriture, mutation et action sortante effectuée par une fonctionnalité d'IA est enregistrée à côté de l'appel du modèle qui l'a déclenchée, de sorte qu'un enquêteur peut reconstituer ce qu'une IA a fait, et pas seulement ce qui lui a été demandé.
L'objectif n'est pas de rendre la communication externe impossible. Les fonctionnalités d'IA doivent faire référence à des liens, mettre à jour des tâches et produire des résultats utiles. L'objectif est de s'assurer qu'elles ne peuvent pas le faire secrètement d'une manière que l'utilisateur n'a pas voulue.
Un modèle pour les valeurs émises par l'IA
Dans ce cadre, le même sous-problème concret revient sans cesse : une fonctionnalité d'IA produit quelque chose (un identifiant d'objet, un destinataire, une URL) et le code en aval agit sur cet élément, souvent avec des autorisations plus étendues que l'IA elle-même. Les hallucinations et les injections de requêtes aboutissent au même résultat : une valeur émise par le modèle est considérée comme fiable.
Nous utilisons un modèle en quatre parties comme liste de contrôle pour la révision de la conception de ces valeurs :
Restreindre ce que l'IA est autorisée à produire en premier lieu, avant que la validation ne doive être exécutée.
Validez chaque valeur produite par l'IA côté serveur par rapport à la même couche d'autorisation que tout le reste. Le modèle est traité comme un client non fiable.
Justifiez le choix en conservant suffisamment de contexte structuré pour expliquer pourquoi l'IA a choisi ce qu'elle a choisi. C'est ce qui rend possibles l'enquête, les évaluations et la réponse aux incidents ultérieurement.
Faites remonter le problème avec une friction, un plan de secours ou un examen humain lorsqu'une valeur présente un risque élevé ou sort du cadre prévu.
Le fil conducteur : le comportement du modèle ne devrait pas être le principal contrôle de sécurité. De meilleures invites et le fait de « dire au modèle de ne pas faire cela » sont des défenses en profondeur utiles, mais les contrôles durables se trouvent dans le système autour du modèle.
Fondé sur des principes
Ces choix ne sont pas ponctuels. Elles découlent des principes publiés par Asana en matière d'IA.
Les personnes sont responsables de leurs décisions : c'est ce qui motive la conception axée sur les points de contrôle. L'IA apporte son aide, mais les êtres humains restent au cœur du processus et sont responsables.
Nous nous engageons à assurer la sécurité, ce qui justifie l'investissement dans des contrôles à plusieurs niveaux, même s'ils ajoutent des frictions. L'alternative aggrave les risques à mesure que les fonctionnalités d'IA prennent en charge des tâches plus complexes.
Nous encourageons la transparence, c'est pourquoi nous rédigeons cet article. Nous n'avons pas résolu le problème de la sécurité de l'IA agentique. Mais le fait d'être ouverts sur la façon dont nous raisonnons au sujet de ces risques et sur les mesures d'atténuation que nous mettons en œuvre aide l'ensemble de la communauté à progresser face à un défi commun et favorise l'examen minutieux qui nous permet de nous améliorer.
Les limites honnêtes
L'injection de requête n'est toujours pas fondamentalement résolue, et l'injection de requête indirecte (les instructions malveillantes sont intégrées dans le contenu que l'IA récupère au cours de son travail, plutôt que dans le contenu qu'un utilisateur lui fournit directement) est la variante qui a le plus touché le secteur en 2026. Le balisage tenant compte de la source est utile, mais il ne comble pas entièrement cette lacune, car le modèle doit encore choisir de respecter les balises. Nos points de contrôle réduisent considérablement le risque ; ils ne l'éliminent pas. Tant que les instructions et les données partagent une fenêtre de contexte, les entrées malveillantes récupérées par le biais de la recherche, des formulaires publics ou des intégrations passeront parfois entre les mailles du filet. Nous considérons qu'il s'agit d'un domaine d'investissement actif et continu, avec un examen plus approfondi de tout chemin qui permet à du contenu créé en externe d'atteindre une fonctionnalité agentique. Le travail sur les modèles de conception pour sécuriser les agents LLM indique des pistes prometteuses, mais le consensus du secteur est encore en cours d'élaboration.
Le paysage des menaces évolue rapidement. De nouveaux vecteurs continuent d'apparaître, de l' injection invisible de requêtes basées sur des images aux chaînes d'exfiltration en plusieurs étapes. Nous concevons des contrôles à plusieurs niveaux et composables afin que de nouvelles mesures d'atténuation puissent être ajoutées à mesure que de nouvelles menaces apparaissent. Il s'agit d'une course aux armements, et non d'un problème que l'on résout une fois pour toutes. Le Top 10 de l'OWASP pour les applications LLM est une référence utile et évolutive.
Nous ne considérons pas ces lacunes comme des raisons de ralentir. Nous les considérons comme des raisons d'agir de manière réfléchie. Le trio mortel nous indique les enjeux. Le contexte, les points de contrôle et les contrôles nous fournissent un cadre d'action. Et comme aucune équipe ne résout ce problème seule, nous investissons activement, aux côtés de nos partenaires de recherche et de nos clients, pour renforcer ces surfaces à mesure que le paysage des menaces évolue.
Références
Simon Willison, « The lethal trifecta for AI agents », juin 2025
Korny Sietsma, « Agentic AI and Security », Martin Fowler, octobre 2025
Bruce Schneier, « We Are Still Unable to Secure LLMs from Malicious Inputs », août 2025
