Injection de prompt

Comment fonctionne l'injection de prompt

La fenêtre de contexte d'un agent ne distingue pas les instructions que vous avez écrites du texte qu'il est allé chercher. Les deux arrivent sous forme de tokens dans le même flux. Donc quand un agent lit la landing page d'un concurrent pour la résumer, et que cette page contient une ligne adressée au modèle plutôt qu'au lecteur, le modèle n'a aucun moyen structurel de savoir qu'il ne devrait pas obéir. Ce n'est pas un défaut d'un produit particulier. C'est une propriété de la façon dont les modèles actuels absorbent l'entrée, et c'est pourquoi il n'existe pas de correctif, seulement du confinement.

La surface d'attaque, c'est simplement tout endroit d'où votre agent absorbe du texte écrit par quelqu'un d'autre, ce qui, pour un agent marketing, représente l'essentiel de son travail :

• Tout ce qui est extrait — pages de concurrents, résultats de recherche, documentation que l'agent lit pour répondre à une question.
• Tout ce qui est téléversé — une base de connaissances en PDF, un tableur, une image contenant du texte.
• Tout ce qui est produit par des utilisateurs — avis de stores d'applications, fils de forums, tickets de support, envois de formulaire.
• Tout ce qui arrive — e-mails, messages de chat, charges utiles de webhooks, jusqu'au titre d'une invitation d'agenda.

Pourquoi un modèle qui refuse de divulguer des secrets n'est pas une défense

L'intuition courante veut qu'un modèle bien entraîné refuse tout simplement. Il refuse souvent, pour la formulation évidente. Nous avons mené un test d'intrusion autorisé contre l'un de nos propres conteneurs de production en juillet 2026, et le schéma était sans ambiguïté. Une instruction injectée demandant à l'agent d'afficher une clé d'API a été refusée. Une instruction injectée présentée comme une vérification de connectivité de routine — qui référençait cette même clé comme variable d'environnement à l'intérieur d'une commande au lieu d'en écrire la valeur — a été exécutée sans hésiter, et l'identifiant a quitté la machine.

L'asymétrie est toute la leçon. La prudence du modèle à propos des secrets garde le chemin où il devrait dire le secret à voix haute. Quand l'agent exécute une commande à la place, le shell substitue la valeur et le modèle ne la voit jamais : il n'y a donc rien que son jugement puisse attraper. Toute défense qui repose sur la capacité du modèle à reconnaître une mauvaise intention garde une porte d'un bâtiment qui en compte plusieurs, et le cadrage passe par les autres : divulgue ceci, il refuse ; exécute cette étape de configuration, il obéit.

Ce qui réduit vraiment le risque

Puisque la vulnérabilité ne peut pas être supprimée par l'entraînement, les mesures utiles sont architecturales. Chacune part du principe que l'injection réussit et limite ce qu'elle peut atteindre :

• Gardez les identifiants hors de portée de l'agent. Une clé que l'environnement de l'agent ne détient jamais ne peut pas lui être soutirée. Faire passer les appels au modèle par un proxy qui détient l'identifiant est la seule mesure qui ferme ce chemin précis au lieu de le rétrécir.
• Moindre privilège sur chaque identifiant. Si un jeton ne peut que faire de l'inférence, ou ne lire qu'une propriété, une fuite vous coûte une facture plutôt qu'un compte.
• Restreignez le trafic sortant. Un agent qui ne peut joindre qu'une liste connue d'hôtes a bien moins d'endroits où envoyer ce qu'on lui a fait collecter.
• Placez une porte devant les actions qui sortent du bâtiment. Une porte de validation devant tout ce qui est publié, envoyé ou dépensé transforme une injection réussie en un brouillon que vous rejetez, et non en un post que vos clients lisent.
• Traitez aussi la sortie de l'agent comme une entrée non fiable. Quand le résumé d'un agent devient le contexte d'un autre, l'instruction injectée voyage avec lui.

L'injection de prompt dans un agent marketing

Les agents marketing sont exceptionnellement proches de ce risque, parce que lire des choses écrites par des inconnus est le métier, pas un cas limite. Un spécialiste recherche extrait des sites concurrents. Un spécialiste feedback lit des avis de stores d'applications. Un spécialiste communauté lit des fils de forums. Chacun de ces canaux est un endroit où quelqu'un d'extérieur à votre entreprise choisit le texte, et aucun ne peut être verrouillé sans supprimer la raison d'être de l'agent.

C'est le raisonnement derrière la construction d'AgentCeres — l'AI Growth Officer sur agentceres.com : les spécialistes qui lisent le web ouvert sont séparés de la permission d'agir sur ce qu'ils lisent, et chaque action sortante attend un clic humain. Lire largement et publier librement sont deux privilèges distincts, et un agent qui détient les deux est à une page web hostile de les utiliser ensemble. Si vous évaluez la longueur de laisse à donner à un agent sur vos propres comptes, dois-je laisser un agent IA publier sur les réseaux sociaux à ma place ? traite la même question par l'autre bout ; human-in-the-loop est le principe général sous les deux.