L'injection de prompt indirecte et les documents que tu n'as pas écrits

La plupart des incidents de sécurité LLM que j’ai examinés n’ont pas commencé par un exploit ingénieux. Ils ont commencé par une fonctionnalité d’apparence raisonnable et une frontière de confiance que personne n’avait tracée intentionnellement.

À quoi ressemble un vrai contrôle

Le moindre privilège est le contrôle le moins cher dont tu disposes. Un agent qui ne peut faire que trois choses ne peut être manipulé que pour faire trois choses. L’instinct d’accorder de larges capacités « par sécurité » est exactement à l’envers.

La gestion des sorties, c’est là où les vieilles vulnérabilités web reviennent sous de nouveaux habits. Le texte du modèle devient le HTML, le SQL ou la commande shell de quelqu’un d’autre. Traite-le comme l’entrée non fiable qu’il est, et les défenses familières s’appliquent toujours.

Mesurer le rayon d’impact

Le logging est le contrôle que personne n’apprécie jusqu’à la revue d’incident. Si tu ne peux pas rejouer précisément ce que le modèle a vu — system prompt, historique, contexte récupéré, appels d’outils — tu n’enquêtes pas, tu devines.

Quoi logger

L’instruction dangereuse vient rarement de l’utilisateur que tu surveilles. Elle vient de la page web que l’agent a récupérée, du document qu’il a retrouvé, du ticket qu’il a résumé. L’injection indirecte est le mode de défaillance qui surprend le plus les équipes.

L’injection de prompt n’est pas une liste de mauvaises chaînes à filtrer. C’est la conséquence structurelle du mélange des instructions et des données dans le même canal. Tu ne peux pas filtrer pour te sortir d’un design qui invite la confusion dès le départ.

L’exploit est rarement ingénieux. Le correctif l’est rarement aussi. Trace la frontière, accorde le minimum, logge assez pour pouvoir récupérer, et tu auras géré la majorité de ce qui arrive vraiment.