Sie entwerfen eine sichere erste Version von PhishTriage-v1 für die BrightShield Credit Union. Ein SOAR-Playbook (Security Orchestration, Automation, and Response) verknüpft Alarmdaten, Anreicherung, Routing und genehmigte Maßnahmen zu einem wiederholbaren Arbeitsablauf. Ein LLM-Schritt (Large Language Model) liest definierten Text ein und liefert eine strukturierte, beratende Ausgabe, etwa eine Zusammenfassung oder vorgeschlagene Tags. Dies erleichtert Technikern die Bedienung des Playbooks, ohne dass das Modell die Befugnis zur Eindämmung eines Sicherheitsvorfalls erhält.
Bei BrightShield ist die sinnvolle Grenze klar definiert: Das LLM kann einen Phishing-Alarm anreichern, eine prägnante Erläuterung verfassen und bei der Benachrichtigung unterstützen. Die Verantwortung für die endgültige Entscheidung verbleibt bei einem Analysten; Maßnahmen wie Quarantäne, Blockierung oder Kontoänderungen müssen von diesem genehmigt werden.
Das Playbook beginnt mit einem eingehenden E-Mail-Alarm und endet mit protokollierten, überprüfbaren Maßnahmen. Nicht vertrauenswürdige E-Mail-Inhalte gelangen erst dann zu einem LLM-Anreicherungsschritt, wenn der Arbeitsablauf Daten entfernt hat, die außerhalb des zulässigen Bereichs liegen. Das LLM liefert ein festes JSON-Schema zurück, das vom Playbook validiert wird, bevor die Daten in das Ticket geschrieben werden. Es besteht kein direkter Zugriff auf Quarantäne-Funktionen, Sperrlisten, Zugangsdaten oder nachgelagerte Berechtigungen.
Bei diesem Design fungiert das LLM als Knotenpunkt für Anreicherung und Klassifizierung, nicht als Entscheidungsträger. Die Kontrollinstanz durch den Analysten trennt beratende Informationen von Maßnahmen, die Mitglieder, Mitarbeiter oder Geschäftsprozesse beeinträchtigen könnten. Betrachten wir nun, wie sich die Vertrauensstellung im Verlauf von PhishTriage-v1 verändert:
E-Mail-Inhalte, Ticket-Texte und extrahierte Header stellen Eingaben dar, die von Angreifern kontrolliert werden können. Bei einer indirekten Prompt-Injection handelt es sich um eine Anweisung, die in den vom LLM gelesenen Inhalten verborgen ist und darauf abzielt, das Verhalten des Modells zu steuern oder Daten offenzulegen. Ein halluzinierter Indikator ist eine frei erfundene Domain, Adresse oder ein anderes Sicherheitsdetail, für das es im zugrundeliegenden Datensatz keine Belege gibt. Beide Risiken sind von Bedeutung, da eine sauber formulierte Zusammenfassung handlungsrelevant erscheinen kann, obwohl sie unsicher ist oder nicht durch Daten gestützt wird.
BrightShield beschränkt BeaconLLM auf Texte zu internen Sicherheitsereignissen und setzt nachverfolgbare IDs der Quelldatensätze voraus. Der Workflow sollte nur die für die Anreicherung unbedingt erforderlichen Textpassagen übermitteln. Ein Modell, das nicht vertrauenswürdige Inhalte verarbeitet, darf keinen Zugriff auf Tools, Geheimnisse oder Berechtigungen zur Eindämmung von Bedrohungen haben. Betrachten wir die Betriebsregeln, die diese Grenzen festlegen: