Le rayon d'explosion d'un agent doté d'un outil de trop

La plupart des incidents de sécurité 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 délibérément.

Les questions que je me pose d’abord

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 piégé que pour faire trois choses. L’instinct d’accorder de larges capacités « par sécurité » est exactement à l’envers.

Le traitement des sorties, c’est là que les vieilles vulnérabilités web reviennent sous un nouveau costume. 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 familières s’appliquent encore.

La frontière a bougé

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

À quoi ressemble un vrai contrôle

L’instruction dangereuse vient rarement de l’utilisateur que vous surveillez. Elle vient 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 interdites à filtrer. C’est la conséquence structurelle du mélange entre instructions et données dans un même canal. Vous ne pouvez pas filtrer pour échapper à 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, loggez assez pour pouvoir reconstituer, et vous aurez géré la majorité de ce qui arrive réellement.