Exfiltration de données via un assistant serviable

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

La frontière s’est déplacée

Le moindre privilège est le contrôle le moins cher dont vous disposez. 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 à contresens.

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

À quoi ressemble un vrai contrôle

La journalisation est le contrôle que personne n’apprécie jusqu’à la revue d’incident. Si vous ne pouvez pas rejouer précisément ce que le modèle a vu — system prompt, historique, contexte récupéré, appels d’outils — vous n’enquêtez pas, vous devinez.

Mesurer le rayon d’explosion

L’instruction dangereuse provient rarement de l’utilisateur que vous surveillez. Elle provient de la page web que l’agent a récupérée, du document qu’il a consulté, 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 chaînes malveillantes à filtrer. C’est la conséquence structurelle du mélange d’instructions et de données dans le même canal. Vous ne pouvez pas vous sortir par le filtrage d’une conception qui invite la confusion dès le départ.

L’exploit est rarement astucieux. Le correctif l’est rarement non plus. Tracez la frontière, accordez le minimum, journalisez assez pour pouvoir reconstituer, et vous aurez géré la majorité de ce qui se produit réellement.