Vous allez concevoir une première version sécurisée de PhishTriage-v1 pour BrightShield Credit Union. Un playbook SOAR (orchestration, automatisation et réponse en matière de sécurité) relie les données d’alerte, l’enrichissement, le routage et les actions approuvées au sein d’un flux de travail reproductible. Une étape basée sur un grand modèle de langage (LLM) lit un texte défini et renvoie des informations consultatives structurées, telles qu’un résumé ou des suggestions de tags. Elle aide l’ingénieur à simplifier l’exécution du playbook, sans pour autant se voir confier l’autorité de contenir un incident.
Chez BrightShield, la limite pertinente est claire. Le LLM peut enrichir une alerte de hameçonnage, rédiger une explication concise et faciliter les notifications. L’analyste reste responsable de la décision finale et doit approuver toute mise en quarantaine, tout blocage ou toute modification de compte.
Le playbook débute par une alerte liée à un e-mail entrant et s’achève par des actions consignées et vérifiables. Le contenu d’un e-mail non fiable ne peut atteindre l’étape d’enrichissement par LLM qu’une fois que le flux de travail a supprimé les données situées hors du périmètre autorisé. Le LLM renvoie un schéma JSON fixe que le playbook valide avant de l’inscrire dans le ticket. Il n’a aucun accès direct aux contrôles de quarantaine, aux listes de blocage, aux identifiants ou aux autorisations en aval.
Cette conception traite le LLM comme un nœud d’enrichissement et de classification plutôt que comme un décideur. L’étape de validation par l’analyste sépare les informations consultatives de toute action susceptible de perturber un membre, un employé ou un processus métier. Examinons l’évolution du niveau de confiance au sein de PhishTriage-v1 :
Le corps des e-mails, le texte des tickets et les en-têtes extraits constituent des données d’entrée contrôlées par un attaquant. L’injection indirecte de prompt (indirect prompt injection) consiste en une instruction dissimulée dans le contenu lu par le LLM, visant à modifier son comportement ou à exposer des données. Un indicateur halluciné correspond à un domaine, une adresse ou tout autre détail de sécurité inventé, sans fondement dans l’enregistrement source. Ces deux risques sont critiques, car un résumé bien rédigé peut sembler exploitable alors qu’il est dangereux ou non étayé.
BrightShield limite BeaconLLM aux textes d’événements de sécurité internes et exige des identifiants d’enregistrement source traçables. Le flux de travail ne doit transmettre que le texte strictement nécessaire à l’enrichissement. Un modèle lisant du contenu non fiable ne doit disposer d’aucun outil, secret ou autorisation de confinement. Examinons les règles de fonctionnement qui établissent cette limite :