Les systèmes d’IA modernes s’appuient souvent sur des gardes de sécurité (guardrails) chargés d’évaluer un texte de consigne avant de laisser le modèle agir. Pourtant, une nouvelle technique décrite par des chercheurs montre que l’on peut parfois contourner ces mécanismes en exploitant la façon dont le modèle interprète du contenu chiffré et le contexte d’exécution.
Ils l’ont nommée cryptographic context injection. L’idée n’est pas seulement de « tromper » un chatbot via une simple phrase malveillante, mais de faire en sorte que la consigne dangereuse soit reconstituée dans un environnement de confiance, sans que les filtres la détectent comme problématique.
Qu’est-ce que la cryptographic context injection ?
Dans le scénario étudié, les gardes de sécurité classent le texte des prompts sans nécessairement l’exécuter. Tant que le contenu reste chiffré (et donc illisible pour ces mécanismes), il peut continuer son chemin sans déclencher d’alerte.
Concrètement, l’attaque s’appuie sur des messages chiffrés qui incluent :
- une instruction (le « vrai » prompt, une fois déchiffré),
- des moyens de déchiffrement,
- le tout transmis au modèle sous forme de chiffrements.
Puis, le texte clair reconstruit arrive dans le contexte d’exécution considéré comme légitime (le sandbox d’exécution du modèle). À ce moment-là, les garde-fous risquent de ne pas recontrôler le contenu déchiffré comme dangereux, ce qui ouvre la porte à des actions indésirables.
Les chercheurs résument l’enjeu avec un avertissement : le « paquet » malveillant hérite d’une crédibilité qu’il n’aurait pas s’il était collé tel quel dans l’interface.
Pourquoi les filtres échouent-ils ?
Le point faible réside dans l’écart entre ce que les gardes inspectent et ce qui est finalement exécuté.
Les guardrails fonctionnent souvent comme un système de tri à l’entrée : ils évaluent un texte pour décider s’il doit être bloqué, reformulé ou autorisé. Mais si l’instruction malveillante se trouve cachée derrière un chiffrement et une logique de déchiffrement, elle peut :
- ne jamais apparaître en clair au moment où le garde-fou évalue le prompt,
- être reconstituée uniquement après exécution de code dans un environnement contrôlé,
- donner au modèle une consigne exploitable sans qu’un nouveau contrôle soit effectué sur le résultat.
Résultat : la défense peut « laisser passer » le contenant, puis l’attaque récupère l’accès à l’instruction au bon moment.
Scénarios d’attaque : livraison directe ou attaque via “watering hole”
Les chercheurs décrivent deux voies principales.
1) Injection directe dans le chat
Dans un cas, l’attaque peut être envoyée directement à une interface de conversation. Le modèle reçoit alors un objet chiffré contenant une instruction et un mécanisme de déchiffrement, puis reconstruit le contenu en interne.
Une fois déchiffrée, la consigne peut viser des objectifs indésirables : par exemple, inciter le modèle à contacter des serveurs externes en manipulant des paramètres de requête afin d’exporter des données utilisateur, ou encore produire une sortie non souhaitée puis la re-chiffrer pour la faire passer au travers des contrôles à la sortie.
2) Attaque indirecte via une page piégée
Les chercheurs mentionnent aussi une approche plus « sournoise » : l’attaque est dissimulée dans une ressource web.
Dans ce modèle, un site peut contenir un objet chiffré (par exemple un JSON chiffré) et une instruction indiquant comment le déchiffrer à l’aide du runtime Python de l’agent. Ensuite, un agent — chargé d’exécuter des tâches comme résumer la page ou extraire des informations précises — ingère le contenu et déclenche la reconstitution du prompt.
À ce stade, la consigne déchiffrée peut demander à l’agent de tirer parti de tout outil disponible. Dans un environnement agentique, cela peut inclure des actions à privilèges, selon la conception du système.
Exemple côté Grok : exfiltration “zero click” via navigation agentique
Un exemple particulier vise l’interface web de xAI Grok et un cadre de navigation agentique. Le but décrit est une attaque d’exfiltration de données sans interaction explicite (“zero click”), déclenchée par de l’ingénierie sociale.
Le mécanisme est le suivant : la victime est persuadée d’examiner ou d’analyser une page web fabriquée de manière malveillante. Cette page contient :
- un objet chiffré (encapsulé, par exemple, en JSON),
- et une instruction pour que l’agent la déchiffre via son environnement Python.
Une fois le contenu déchiffré, l’agent reçoit une consigne qui lui demande de récupérer du contexte privé de session puis d’y inclure des données dans une URL. L’URL malveillante est ensuite chargée automatiquement, et les données sont transmises.
Les chercheurs soulignent un aspect critique : si les instructions et les données provenant d’une page non fiable peuvent conduire l’agent à invoquer un outil privilégié connecté à Internet, alors l’export de données peut se produire sans confirmation utilisateur ni avertissement visible.
Exemple côté Gemini : contournement en mode “Deep Thinking”
Un autre exemple vise l’interface publique de Gemini, dans un mode orienté raisonnement. Ici, un seul prompt suffit à lancer une procédure : l’IA est amenée à exécuter un script Python qui déchiffre le contenu chiffré fourni.
Les chercheurs décrivent une chaîne d’astuces permettant au modèle de produire du contenu restreint, tout en le présentant d’une manière qui simule un cadre “sûr”. L’idée est d’obtenir les données interdites, puis de les chiffrer à nouveau avant de renvoyer le résultat à l’utilisateur.
Le texte dangereux n’apparaît donc pas comme une sortie simple et déclenchante ; il est transporté sous une forme qui n’active pas les barrières attendues. Selon le rapport, la technique a permis la génération d’un exemple long en plusieurs paragraphes de contenu normalement supprimé par les filtres de sécurité (par exemple des éléments liés à la fabrication d’armes incendiaires).
Le sujet reste en évolution : succès variable selon les mises à jour
Les chercheurs indiquent qu’ils ont signalé leurs résultats à xAI le 3 juin 2026. Ils mentionnent aussi des tentatives de coordination de publication aux dates du 4 août et du 10 août. Au moment de la rédaction de leur rapport, ils n’auraient reçu aucune réponse.
Ils ajoutent qu’ils ne pouvaient pas soumettre le signalement à Google, car les règles de disclosure qu’ils citent ne couvriraient pas les jailbreaks, qui relèvent d’un autre cadre. Néanmoins, ils observent une évolution : la réussite contre Gemini aurait diminué à la fin de la période étudiée.
Ils ne peuvent pas en déduire une cause certaine. Ils proposent des hypothèses : changements de filtres, mise à jour de versions de modèles, ou combinaison des deux.
Malgré tout, le message central demeure : la cryptographic context injection peut encore présenter un risque, et les défenseurs doivent s’y préparer.
Quelles défenses envisager contre cette attaque ?
Les chercheurs précisent que leur rapport inclut des recommandations de prévention pour la défense. Même si le détail complet des contre-mesures n’est pas listé ici, l’approche logique à retenir s’articule autour de l’écart “entrée vs sortie” et “filtrage vs exécution”.
En pratique, la défense passe souvent par l’un ou plusieurs de ces leviers :
- Recontrôler le contenu après déchiffrement, et pas uniquement avant exécution.
- Limiter ce qu’un agent peut faire avec les données issues de sources non fiables (pages web, contenus externes).
- Encadrer les outils connectés à Internet pour empêcher qu’une consigne injectée n’aboutisse à une action sortante automatique.
- Ajouter des garde-fous contextuels : par exemple, exiger une confirmation ou une vérification lorsque des données privées sont sur le point d’être réutilisées dans une requête.
Le point commun de ces pistes est de réduire la possibilité pour une consigne cachée de devenir une instruction “crédible” une fois reconstituée dans le sandbox.
Pourquoi cela concerne tout le monde : agents, outils, et données utilisateur
Au-delà des interfaces spécifiques évoquées, la cryptographic context injection met en lumière un risque plus large : la combinaison entre contenus externes, exécution de code et outils à privilèges dans des systèmes agentiques.
Plus un modèle peut :
- analyser du contenu non fiable,
- exécuter des étapes de traitement (comme un déchiffrement),
- puis agir via des outils connectés,
plus la surface d’attaque augmente. Et si les contrôles de sécurité ne suivent pas le contenu jusqu’à sa forme finale en clair, un contournement devient envisageable.
En d’autres termes : la sécurité d’un système IA ne se limite pas aux messages visibles à l’écran. Elle dépend aussi de ce que le modèle reconstitue, du moment où il le reconstitue, et des actions qu’il déclenche ensuite.
Conclusion
La cryptographic context injection illustre comment un chiffrement peut servir de vecteur pour contourner des guardrails de sécurité. En faisant reconstituer une consigne malveillante dans un contexte d’exécution, l’attaque peut éviter la détection attendue à l’entrée, puis pousser le modèle ou un agent à effectuer des actions indésirables, y compris des scénarios d’exfiltration.
Les résultats observés semblent évoluer selon les mises à jour de filtres ou de versions de modèles, mais le risque potentiel demeure. Pour les défenseurs, le défi est clair : aligner le contrôle de sécurité sur ce qui est réellement exécuté, pas seulement sur ce qui est initialement soumis.
Source: https://www.securityweek.com/encrypted-prompts-bypass-ai-safety-guardrails-in-grok-and-gemini/
