Je lisais il y a quelques soirées le OWASP Top 10 pour les applications d’IA à grande échelle (large language model) : la liste mise à jour publiée à la fin de l’an dernier, et un point m’a immédiatement interpellé parce qu’il correspond de manière très directe au problème que Newton Protocol essaie de résoudre en toute discrétion. L’injection de prompt occupait la première place, non pas comme une simple préoccupation théorique, mais comme la vulnérabilité la plus critique qui affecte activement les systèmes de production en ce moment, des copilotes d’entreprise aux assistants de programmation en passant par les agents autonomes qui gèrent de vrais flux de travail. La description de la communauté sécurité est presque déconcertante de simplicité : un attaquant insère des instructions malveillantes dans le contenu que l’agent est censé lire comme des données ; l’agent ne peut pas distinguer de manière fiable l’instruction de l’information, et la charge malveillante remplace ce que l’agent était censé faire à l’origine. Dans la plupart des contextes logiciels, cela produit une mauvaise réponse ou un document divulgué. Dans le cas d’un agent financier onchain disposant d’un portefeuille financé et de droits d’exécution de transactions, cela produit quelque chose de bien plus grave encore.
Ce qui m’intéresse vraiment, c’est à quel point la description du problème par la communauté de recherche en sécurité correspond exactement à l’écart architectural que Newton est conçu pour combler, même si les deux conversations se réfèrent rarement l’une à l’autre directement. Les chercheurs en sécurité convergent vers ce qu’un analyste a décrit comme la « triple menace mortelle » : la combinaison de l’accès à des données privées, de l’exposition à du contenu non fiable et de la capacité d’effectuer des actions externes. Lorsque les trois sont présentes simultanément dans un seul agent, la surface d’attaque ne reste plus théorique et devient une quasi-certitude sous une pression adversariale suffisante. Pour un agent d’automatisation DeFi, ces trois propriétés ne sont pas des cas limites : ce sont le descriptif de poste de base. L’agent lit des données de marché et des flux externes, détient des permissions de clé de session sur un portefeuille financé, et exécute des transactions de manière autonome. OpenAI, Anthropic et Google DeepMind ont toutes reconnu dans des publications de 2025 que l’injection via prompts ne peut pas être entièrement résolue au sein des architectures actuelles de grands modèles de langage, car toute défense formulée comme une instruction de prompt peut être elle-même contournée par une attaque suffisamment habile. Je me demande parfois si les personnes qui déploient des agents d’IA pour des opérations de trésorerie onchain ont réellement relu attentivement cette phrase, car elle dit effectivement que le modèle lui-même ne peut pas être la dernière ligne de défense.
La partie à laquelle je reviens sans cesse, c’est ce que cela implique pour l’emplacement exact de la frontière de sécurité, et pourquoi la couche d’application des politiques avant règlement de Newton répond à quelque chose que des défenses uniquement au niveau du modèle ne peuvent pas faire de manière structurelle. Le consensus qui se dégage de la recherche en sécurité est que la bonne approche n’est pas un meilleur filtrage des prompts, mais une application déterministe des politiques au niveau de l’outil, en limitant ce que l’agent peut faire avec ses droits d’exécution, quels que soient les instructions qu’il a reçues ou de qui elles proviennent. Les listes de bénéficiaires approuvés de Newton, les plafonds de dépenses et les politiques de mise en conformité ne sont pas des fonctionnalités que l’agent lui-même applique : ce sont des contraintes externes évaluées par un réseau d’opérateurs neutres avant que la transaction n’atteigne la chaîne. Un agent compromis, auquel on a injecté des instructions pour transférer des fonds à une adresse de l’attaquant, passe quand même le contrôle des politiques de Newton avant que ce transfert ne se confirme, et si l’adresse de destination ne figure pas dans la liste des bénéficiaires approuvés, la transaction est bloquée indépendamment de ce que l’agent pense être autorisé à faire. La question qui me vient à l’esprit est de savoir si cette distinction — faire confiance à l’agent versus contraindre ce qu’il peut réellement exécuter — est comprise avec suffisamment de clarté par les développeurs qui construisent actuellement des systèmes d’automatisation onchain destinés à la production.
En regardant de l’extérieur vers la direction que prend cette conversation, il y a une dimension temporelle qui semble importante et pourtant sous-estimée. La communauté de la recherche en sécurité documente activement des attaques où un seul document injecté dans une base de données vectorielle permet d’obtenir un taux de réussite de 90 % ; où l’empoisonnement de la mémoire crée des attaques différées qui persistent d’une session à l’autre ; et où des systèmes multi-agents se transmettent entre eux des instructions compromises d’une manière qui rend presque impossible de retracer, a posteriori, le point d’injection initial. Or, toutes ces recherches arrivent à maturité exactement au moment où des agents d’IA sur chaîne passent de petits déploiements expérimentaux à des systèmes gérant des capitaux significatifs sur de vrais protocoles. L’arrivée du bêta-mainnet de Newton pendant cette fenêtre précise ressemble moins à une coïncidence qu’à la découverte par le protocole de la jonction entre deux domaines, la sécurité de l’IA et la finance onchain, qui évoluent en parallèle sans reconnaître pleinement à quel point elles s’intersectent directement. Que les développeurs qui construisent la prochaine génération d’agents financiers considèrent l’application de politiques avant règlement comme une exigence fondamentale, ou qu’ils en découvrent la nécessité à la dure, c’est une question à laquelle je n’ai pas encore la réponse — mais le temps nous dira...