Yandex Cloud explique comment déployer des agents d'IA en cybersécurité sans faux blocages ni pannes

Yandex Cloud a décrit comment les agents d'IA peuvent devenir de précieux assistants pour un SOC, tout en n'obtenant pas le droit d'agir sur des points critiques sans contrôle humain. Dans une analyse publiée sur Habr, l'équipe présente deux scénarios : dans l'un, l'agent fait gagner des dizaines de minutes à l'analyste ; dans l'autre, il isole par erreur un contrôleur de domaine et paralyse l'entreprise.

Pourquoi le SOC est surchargé

Un SOC moderne vit dans un bruit permanent : un seul analyste peut avoir à traiter jusqu'à 1000 alertes par jour, dont jusqu'à 95 % se révèlent être des faux positifs. Dans ce contexte, confier le tri initial et la corrélation à l'IA paraît presque inévitable. Un agent sait analyser rapidement des logs, décoder des commandes, aller chercher du contexte dans le SIEM et rapprocher des événements de MITRE ATT&CK. Là où un humain passe des dizaines de minutes de travail concentré, un modèle peut fournir une ébauche en quelques secondes.

Mais Yandex Cloud prévient : le potentiel d'automatisation dépasse la fiabilité réelle de ces systèmes. L'auteur cite une étude d'Anthropic de mars selon laquelle, pour les métiers de l'informatique et des mathématiques, l'automatisation théorique des tâches atteint 94 %, contre seulement 33 % environ en pratique. Cet écart dit l'essentiel : l'IA est déjà utile, mais on ne peut pas la considérer comme un employé autonome et mature. Surtout en cybersécurité, où une erreur d'interprétation d'un événement peut coûter bien plus qu'une fausse alerte : l'arrêt de services clés.

Où l'agent se trompe

L'exemple central de l'article repose sur une alerte sur le contrôleur de domaine DC01. Dans le scénario sûr, l'agent reçoit un signal de lancement suspect de PowerShell, décode la commande Base64, comprend qu'elle énumère les membres de Domain Admins et la rattache à une technique de reconnaissance des privilèges. Il vérifie ensuite les politiques internes, constate que DC01 relève du Tier-0, collecte des événements supplémentaires uniquement sur une fenêtre de temps étroite et, au lieu d'agir automatiquement, produit un rapport pour l'analyste du SOC, assorti d'une confirmation HITL obligatoire.

Dans le mauvais scénario, ce n'est pas l'entrée qui casse, mais le raisonnement. L'agent corrèle les événements de façon trop grossière, par heure et par hôte plutôt que par identifiants de session et chaîne de processus. Il relie ainsi une requête DNS sans rapport à l'activité PowerShell, interprète le tableau comme du C2 ou de l'exfiltration et décide d'isoler DC01. Pour un contrôleur de domaine, c'est un désastre : Kerberos et LDAP tombent, les services dépendants s'arrêtent, et l'entreprise subit une interruption à cause d'une conclusion erronée du modèle.

«

Il faut accepter que les modèles hallucinent et peuvent se tromper », écrit Sergueï Nesterouk.

Quelles barrières mettre en place

L'idée maîtresse de l'article : il ne faut pas combattre la possibilité même de l'hallucination, mais les conséquences de l'erreur. Un LLM ne manipule pas la vérité comme un analyste et, dans l'incertitude, il tente plus souvent de deviner que de dire honnêtement « je ne sais pas ». Un agent d'IA digne de confiance en cybersécurité n'est donc pas un modèle isolé, mais un ensemble de contraintes externes qui l'entourent : validation des entrées, contrôle de la mémoire, droits stricts sur les outils, audit et couche d'approbation humaine là où le coût de l'erreur est trop élevé.

• filtrage des données d'entrée et protection contre le prompt injection
• RAG avec une base de connaissances à jour, RBAC, reranking et vérification des conflits
• reasoning firewall : superviseur, décomposition des tâches, vérification croisée et évaluation de la confiance
• restriction des actions sur le Tier-0, politique d'abstention et human-in-the-loop obligatoire

Yandex Cloud recommande de déployer ces systèmes par étapes. Comme repère pratique, l'équipe utilise AI-SAFE, un cadre de modélisation des menaces pour les systèmes à agents, structuré en cinq niveaux : saisie utilisateur, orchestration du contexte, raisonnement du modèle, outils et bases de connaissances. D'abord, un assistant qui cherche des données, rassemble du contexte et réduit la charge cognitive de l'équipe. Ensuite, une automatisation partielle avec confirmation humaine. Et ce n'est qu'après avoir accumulé des logs, des métriques de qualité, des scénarios de défaillance bien compris et un fonctionnement stable que l'on peut accorder à l'agent des pouvoirs plus étendus.

Ce que cela signifie

Le marché va vers une IA devenue la norme dans les SOC, mais les gagnants ne seront pas ceux qui mettront un agent en production les premiers : ce seront ceux qui l'entoureront de guardrails et laisseront à un humain la décision finale aux points critiques. Pour les entreprises, c'est un bon repère : on peut déjà automatiser la routine, mais pas encore la confiance.