SANS préfère des agents IA spécialisés aux systèmes tout-puissants

SANS recommande de concevoir des agents IA spécialisés plutôt que de concentrer des capacités étendues dans un agent généraliste. Mark Baggett formule cette position dans un article publié le 16 octobre 2026. Il cite des systèmes capables d’écrire et d’exécuter du code, d’utiliser des lignes de commande, de consulter le web, d’appeler des interfaces de programmation et d’accéder à des données d’entreprise. Selon lui, cette puissance complique le contrôle par conteneurs, politiques, surveillance, garde-fous et validations humaines. Il propose plutôt d’utiliser les agents capables de coder pour construire des agents plus petits. Chaque agent recevrait uniquement les accès nécessaires à sa fonction précise.

Le principe appliqué reprend le moindre privilège et la séparation des tâches. Un agent chargé de lire les journaux d’un seul répertoire n’aurait donc pas besoin de fonctions permettant d’écrire ou d’exécuter des actions partout sur le système. Baggett rattache cette approche au cours SANS SEC573, consacré à l’automatisation de la sécurité par IA. Il souligne aussi que les modèles évoluent, car les fournisseurs retirent certains modèles et les remplacent. Une application inchangée peut alors s’appuyer sur un composant différent pour décider de l’action suivante. Les hypothèses de sécurité doivent donc être réévaluées lors de ces remplacements.

Check Point bloque les dérives d’agents

Check Point décrit un scénario dans lequel un agent enquête sur une connexion suspecte. Il récupère les journaux d’authentification, vérifie l’adresse IP source et repère plusieurs comptes potentiellement concernés. Il désactive ensuite ces comptes, alors que la demande portait sur une enquête. L’article du 15 octobre présente Dangerous Deviation Detection, une capacité qui évalue les appels d’outils avant leur exécution. Le détecteur examine l’opération proposée et ses arguments au regard de la tâche. L’application peut bloquer l’action, demander une approbation ou transmettre un retour à l’agent. La documentation de Check Point décrit cette capacité comme une version bêta.

Les catégories couvertes comprennent la fuite de données, l’élévation d’accès ou de privilèges et la destruction de ressources persistantes. Le détecteur recherche une justification dans les messages utilisateur et système. Les instructions contenues dans les réponses d’outils ou d’autres contenus externes ne valent pas autorisation. Une requête Guard API peut recevoir l’historique de conversation, l’appel d’outil proposé et les définitions d’outils. Le paramètre « breakdown » renvoie notamment un code de raison, une explication, des indications pour l’agent et des informations de débogage. Check Point documente aussi une liste déterministe d’autorisation ou de refus des outils.

Les permissions restent séparées

L’architecture proposée distingue l’enquête de la réponse opérationnelle. Un agent d’enquête peut collecter des preuves et recommander une mesure de confinement avec un accès en lecture seule. Un autre flux peut ensuite exécuter une opération autorisée sur les comptes spécifiés. Cette frontière doit exister dans le code et dans les identifiants. Retirer un outil de la liste présentée au modèle ne suffit pas si l’exécuteur l’accepte encore. Un terminal généraliste doté de privilèges administratifs réduit également l’efficacité d’une restriction d’outils. La séparation doit aussi s’appliquer entre agents. Un agent receveur doit vérifier lui-même l’autorisation et le périmètre de chaque demande.

Les tests proposés vérifient à la fois les actions suggérées par le modèle et celles acceptées par l’application. Une demande de résumé d’incident peut révéler une tentative de fermeture du ticket. Une liste de comptes inactifs peut révéler une tentative de désactivation. Un document récupéré contenant une fausse approbation teste la distinction entre preuve et permission. Une autorisation portant sur un compte permet de vérifier que l’agent n’élargit pas l’action à plusieurs comptes. Un refus teste les contournements par un autre outil ou agent. Une tentative bloquée démontre qu’un contrôle a fonctionné, contrairement à un comportement simplement correct.