Interviewfragen zu AI & LLM Security

Grenzenlose Autonomie plus Tool-Zugriff ist die „exzessive Handlungsmacht

Nicht vertrauenswürdiger Inhalt, den das Modell aufnimmt, kann Anweisungen tragen — das ist indirekte Prompt-Injection. Sie können nicht vollständig verhindern, dass das Modell beeinflusst wird, also isolieren Sie abgerufenen Inhalt als Daten, begrenzen Sie die Tools/Berechtigungen des Agenten, verlangen Sie Bestätigung für sensible Aktionen und geben Sie ihm keine Geheimnisse, zu deren Preisgabe er gezwungen werden könnte. Anzunehmen, das Modell ignoriere injizierte Anweisungen einfach, ist genau der ausgenutzte Fehlermodus.

Ein Drittanbieter-Modell ist eine Lieferketten-Abhängigkeit: Prüfen Sie, dass es aus einer vertrauenswürdigen Quelle mit übereinstimmenden Prüfsummen/Signaturen stammt, dass seine Lizenz Ihre Nutzung erlaubt und dass das Dateiformat beim Laden keinen beliebigen Code ausführt (bevorzugen Sie sichere Serialisierung gegenüber Pickle-artigen Formaten). „Es lädt” und „Download-Geschwindigkeit” sagen nichts über Vertrauen aus, und anzunehmen, öffentliche Modelle seien sicher, ignoriert reale Vergiftungs- und Deserialisierungsrisiken.

Das ist die „unsachgemäße Ausgabebehandlung

Kunden-PII an eine externe API zu senden, setzt sie der Verarbeitung und Aufbewahrung durch einen Dritten aus und kann Datenschutzpflichten verletzen. Minimieren und redigieren Sie, was gesendet wird, bestätigen Sie die Nutzungs-/Aufbewahrungsbedingungen des Anbieters und einen Auftragsverarbeitungsvertrag (oder Kein-Training-Garantien), oder wechseln Sie für sensible Daten zu einer privaten Bereitstellung. Die Schlüssellänge ist irrelevant, und mehr PII zu senden erhöht die Exposition.

Wenn der Abruf jedes indexierte Dokument liefert, egal wer fragt, gibt das Modell getreu Daten preis, die der Nutzer nicht sehen sollte — das ist ein Autorisierungsfehler, keine Halluzination. Erzwingen Sie die dokumentbezogenen Berechtigungen des Nutzers zum Zeitpunkt des Abrufs, sodass nur autorisierte Fragmente in den Kontext gelangen. Ein längerer System-Prompt ist umgehbar und implementiert keine Zugriffskontrolle, die Temperatur ist irrelevant, und ein anderes Modell hat dieselbe Lücke.

Das Training auf ungeprüften Nutzerdaten erlaubt einem Angreifer, das Modell zu vergiften — Hintertüren, Trigger oder verzerrtes Verhalten zu implantieren, das später auftaucht. Beherrschen Sie es durch Datenprüfung und -filterung, Herkunftsverfolgung, Anomalieerkennung im Datensatz und Evaluierung des Modellverhaltens nach dem Training. „Mehr Daten ist besser” ignoriert die Integrität, und das eigentliche Problem ist die Vergiftung, nicht Geschwindigkeit oder Speicherplatz.

Prompt Injection lässt sich nicht vollständig mit mehr Prompt-Text lösen; nimm an, dass das Modell unterwandert werden kann, und begrenze, was es TUN darf. Gib Tools least privilege, sichere wirkungsstarke Aktionen mit menschlicher Bestätigung ab und validiere oder sandboxe Tool-Aufrufe vor dem Handeln (OWASP LLM „Excessive Agency“ und „Improper Output Handling“). Im System-Prompt zu flehen ist umgehbar. Höhere Temperature fügt nur Zufall hinzu, und reines Logging hält den Schaden fest, ohne die injizierte Aktion zu verhindern.

KI hilft dem SOC, indem sie Alerts triagiert und dedupliziert, Vorfälle zusammenfasst, Kontext anreichert, Detections entwirft und das Onboarding von Analysten beschleunigt — was Ermüdung und Verweildauer reduziert. Die Risiken: halluzinierte oder selbstbewusst falsche Schlüsse, Automation Bias, bei dem Analysten aufhören zu prüfen, Prompt Injection über vom Angreifer kontrollierte Log- oder Alert-Daten, das Abfließen sensibler Daten an Drittmodelle, und Angreifer, die dieselben Tools nutzen. Halte einen Menschen in der Schleife, prüfe die Ausgaben und isoliere nicht vertrauenswürdige Eingaben.

Direkte Prompt Injection liegt vor, wenn ein Nutzer gegnerische Anweisungen direkt in den Prompt tippt, um den System-Prompt oder Sicherheitsregeln zu überschreiben. Indirekte Prompt Injection verbirgt bösartige Anweisungen in externen Inhalten, die das Modell später einliest — eine Webseite, eine E-Mail, ein PDF oder ein RAG-Dokument —, sodass der Angriff auslöst, ohne dass das Opfer ihn je tippt. Indirekte Injection ist das größere Risiko, weil Angreifer und Opfer verschiedene Personen sind und die Payload in Daten mitreist, denen die App implizit vertraut.

Unsichere Ausgabeverarbeitung bedeutet, dem zu vertrauen, was das Modell zurückgibt, und es ohne Validierung oder Codierung an ein nachgelagertes System weiterzureichen. Weil die Modellausgabe von Angreifern beeinflussbar ist, führt das Rendern als rohes HTML zu XSS, das Einspeisen in einen URL-Fetcher zu SSRF und das Übergeben an eine Shell oder SQL-Abfrage zu Command- oder SQL-Injection. Die Lösung ist, die Modellausgabe genauso wie nicht vertrauenswürdige Benutzereingaben zu behandeln: kontextbewusste Ausgabecodierung, Allowlisting, Sanitization und Parametrisierung, bevor sie einen Sink erreicht.

Ein Jailbreak zielt auf das Sicherheits-Alignment des Modells: Er bringt das Modell dazu, Inhalte zu erzeugen, die der Anbieter zu verbieten versuchte, etwa schädliche Anleitungen. Prompt Injection zielt auf die Anweisungshierarchie der Anwendung: Sie überschreibt den System-Prompt des Entwicklers oder kapert das Verhalten des Modells innerhalb einer App, oft über nicht vertrauenswürdige Daten. Jailbreaks greifen das Modell an; Prompt Injection greift das umgebende System an. Sie überschneiden sich, aber das Ziel und die überschrittene Vertrauensgrenze unterscheiden sich.

Die LLM-Supply-Chain umfasst Basismodelle, fine-getunte Varianten, Datensätze, Embeddings, Plugins, Bibliotheken und die Hosting-Plattform — jede davon ein Punkt, an dem Risiko entstehen kann. Zu den Bedrohungen zählen das Herunterladen manipulierter oder mit Backdoors versehener Modellgewichte, bösartige Fine-Tunes, vergiftete oder lizenzbelastete Datensätze, anfällige oder überberechtigte Plugins sowie typosquattete Modell-Repos. Verteidigung: Modelle aus vertrauenswürdigen Registries beziehen, Integrität und Provenienz prüfen, eine AI Bill of Materials pflegen, Abhängigkeiten scannen und pinnen, Plugins prüfen und das Least-Privilege-Prinzip auf alles anwenden, mit dem das Modell integriert wird.

Das NIST AI Risk Management Framework (AI RMF 1.0) ist ein freiwilliges, risikobasiertes Framework zur Governance vertrauenswürdiger KI über ihren gesamten Lebenszyklus. Sein Kern sind vier Funktionen: Govern (Kultur, Richtlinien, Verantwortlichkeit — und es zieht sich durch die anderen), Map (Kontext und Risikoidentifikation), Measure (Risiken bewerten und nachverfolgen) und Manage (priorisieren und reagieren). Es definiert außerdem Vertrauenswürdigkeitsmerkmale — valide und zuverlässig, sicher, abgesichert und widerstandsfähig, rechenschaftspflichtig und transparent, erklärbar, datenschutzfördernd und fair. Es ergänzt technische Listen wie die OWASP LLM Top 10 auf der Programmebene.

Die OWASP Top 10 für LLM-Anwendungen sind die Konsensliste der kritischsten Risiken beim Entwickeln mit großen Sprachmodellen. Die Ausgabe 2025 umfasst Prompt Injection, Offenlegung sensibler Informationen, Supply Chain, Daten- und Modellvergiftung, unsichere Ausgabeverarbeitung, übermäßige Handlungsvollmacht, Leakage von System-Prompts, Schwachstellen in Vektoren und Embeddings, Fehlinformation sowie unbegrenzten Ressourcenverbrauch. Sie existiert, weil klassische AppSec-Listen die LLM-spezifischen Fehlerbilder nicht erfassen, und gibt Teams ein gemeinsames Vokabular sowie eine Checkliste, um Maßnahmen zu priorisieren.

RAG-Sicherheit bedeutet, jedes abgerufene Dokument als nicht vertrauenswürdige Eingabe zu behandeln. Zentrale Risiken: indirekte Prompt Injection, die in abgerufenen Inhalten versteckt ist, Vergiftung der Wissensbasis oder der Embeddings sowie fehlende benutzerbezogene Autorisierung, sodass das Modell Daten zurückgibt, auf die der Benutzer keinen Zugriff hat. Zu den Verteidigungsmaßnahmen zählen Zugriffskontrolle beim Retrieval, Inhaltsprovenienz und Prüfung der Ingestion, Behandeln von abgerufenem Text als Daten statt als Anweisungen, Ausgabevalidierung und Isolierung der Vektordatenbank pro Mandant.

Ein LLM-Agent verwandelt Text über Tools und Function Calls in Aktionen, sodass eine Prompt Injection zu einer realen Aktion wird — das Risiko übermäßiger Handlungsvollmacht. Sichere ihn ab, indem du jedem Tool das geringste benötigte Privileg und den engsten Geltungsbereich gibst, Tool-Argumente validierst und einschränkst, menschliche Bestätigung für sensible oder irreversible Aktionen verlangst, die Ausführung sandboxt, Aufrufe rate-limitierst und budgetierst und jeden Tool-Aufruf protokollierst. Lass niemals zu, dass die von nicht vertrauenswürdigen Daten beeinflusste Ausgabe des Modells direkt eine folgenschwere Aktion autorisiert.

LLM-Apps geben Daten auf mehrere Arten preis: Das Modell memoriert und gibt sensible Trainings- oder Fine-Tuning-Daten wieder, der System-Prompt (der Geheimnisse oder Logik enthalten kann) wird extrahiert, abgerufene RAG-Dokumente legen Daten offen, die der Benutzer nicht sehen sollte, und Kontext aus einer Benutzer- oder Sitzung blutet in eine andere über. Vorbeugung bedeutet Datenminimierung vor dem Training, niemals Geheimnisse in Prompts, das Erzwingen benutzerbezogener Autorisierung beim Retrieval, Ausgabefilterung und PII-Redaktion sowie Mandantenisolierung.

Trainingsdaten-Vergiftung liegt vor, wenn ein Angreifer die Daten manipuliert, die zum Pre-Training, Fine-Tuning oder Einbetten eines Modells verwendet werden, sodass das resultierende Modell sich bösartig verhält — durch Einbetten eines Backdoor-Triggers, Einschleusen von Verzerrungen oder Verschlechtern der Genauigkeit. Es nutzt aus, dass Modelle große, oft aus dem Web stammende Datensätze scrapen und ihnen vertrauen. Zu den Verteidigungsmaßnahmen zählen das Kuratieren und Signieren von Datenquellen, Provenienz- und Integritätsprüfungen, Anomalieerkennung in Trainingsdaten, Datensatz-Versionierung und das Beschränken, wer zu Trainings- und RAG-Korpora beitragen darf.