Secrets, outils, et l'agent qui a lu votre fichier env

Je tiens une courte liste des façons dont les fonctionnalités IA dérapent en production. Presque toutes se ramènent à la même cause racine : le système a traité comme fiable quelque chose qu’un attaquant pouvait influencer.

À quoi ressemble un vrai contrôle

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.

Mesurer le rayon de l’explosion

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.

Le modèle mental qui aide le plus, c’est la frontière de confiance. Tracez une ligne autour des choses que vous contrôlez. Tout ce qui franchit cette ligne — entrée utilisateur, documents récupérés, sortie d’outil, la réponse du modèle lui-même — est non fiable jusqu’à ce que vous ayez fait quelque chose de délibéré pour lui accorder votre confiance.

Quoi logger

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.

Les questions que je me pose d’abord

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.

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.