Auf dieser Seite
Helm & Nagel
Helm & Nagel GmbH Cognitive Automation & AI Agent Consulting

Große Sprachmodelle (LLMs) verändern grundlegend, wie Unternehmen mit digitalen Systemen arbeiten. Mit ihrer zunehmenden Verbreitung rückt Cybersicherheit in den Mittelpunkt: Entwickler, Datenwissenschaftler und Sicherheitsverantwortliche müssen verstehen, wie diese Technologien abzusichern sind.

OWASP Top 10 für LLM-Anwendungen

Die OWASP Top 10 für LLM-Anwendungen liefert einen strukturierten Leitfaden zur Absicherung von Sprachmodellen gegen bekannte Schwachstellen. Rund 500 internationale Experten haben die zehn kritischsten Sicherheitsrisiken für LLMs zusammengestellt.

  1. Model Theft: Unbefugter Zugriff auf proprietäre Sprachmodelle verursacht erhebliche wirtschaftliche Schäden und gefährdet Wettbewerbsvorteile.
  2. Overreliance: Zu starke Abhängigkeit von LLMs ohne menschliche Kontrolle führt zu Fehlinformationen und rechtlichen Risiken durch unzutreffende oder unangemessene Ausgaben.
  3. Excessive Agency: LLMs mit zu viel Funktionsumfang oder Autonomie können Aktionen auslösen, die unbeabsichtigte Folgen haben.
  4. Insecure Plugin Design: Sicherheitslücken in LLM-Plugins durch unsichere Eingaben und unzureichende Zugriffskontrollen können schwerwiegende Konsequenzen wie Remote Code Execution haben.
  5. Sensitive Information Disclosure: LLMs können vertrauliche Daten preisgeben und dadurch unbefugten Zugriff, Datenschutzverletzungen und Sicherheitsvorfälle verursachen.
  6. Supply Chain Vulnerabilities: Der Einsatz von Drittanbieter-Datensätzen, Modellen und Plugins bringt Sicherheitsrisiken in LLM-Anwendungen ein.
  7. Model Denial of Service: Angreifer können ressourcenintensive Operationen auf LLMs erzwingen und so Dienstausfälle oder hohe Kosten verursachen.
  8. Training Data Poisoning: Manipulation von Trainingsdaten kann Schwachstellen oder Verzerrungen einführen und die Sicherheit und Wirksamkeit von LLMs beeinträchtigen.
  9. Insecure Output Handling: Unzureichende Validierung von LLM-Ausgaben führt zu Schwachstellen in Backend-Systemen und möglichen Sicherheitsvorfällen.
  10. Prompt Injection: Gezielt formulierte Eingaben können ein LLM dazu bringen, unbeabsichtigte Aktionen auszuführen.

Warum das relevant ist

Das exponentielle Wachstum von LLMs in verschiedenen Branchen macht robuste Cybersicherheitsmaßnahmen unumgänglich. Unternehmen, die Sprachmodelle sicher einsetzen wollen, profitieren von professioneller KI-Beratung, um von Anfang an Best Practices einzuhalten. Die OWASP Top 10 für LLM-Anwendungen bieten dabei konkrete Orientierung zur Absicherung LLM-basierter Systeme gegen aktuelle Bedrohungen.

Fazit

Mit der zunehmenden Bedeutung von LLMs für die Zukunft der Technologie wird das Verständnis ihrer spezifischen Cybersicherheitsrisiken zur Pflicht. Unternehmen, die KI-Agenten einsetzen, müssen insbesondere Risiken wie Prompt Injection und übermäßige Handlungsautonomie im Blick behalten. Die OWASP Top 10 für LLM-Anwendungen bilden einen kritischen Rahmen, um diese komplexe Landschaft zu navigieren und LLM-Technologien sicher einzusetzen.

OWASP-Framework operationell anwenden

Die OWASP Top 10 für LLM-Anwendungen sind eine Kategorisierung, kein Sanierungsplan. Organisationen, die sie als Checkliste behandeln, ohne den operativen Kontext jedes Risikos zu verstehen, setzen häufig unvollständige Kontrollen um. Die folgenden Abschnitte übersetzen die wirkungsstärksten Risiken in konkrete Anforderungen an Gegenmaßnahmen.

Prioritäre Risiken in Unternehmensumgebungen

Helm & Nagel
OWASP TOP 4

Höchstwirksame LLM-Risiken für Unternehmen

  • Prompt Injection nutzt das instruktionsfolgende Verhalten des Modells aus, ohne Zugriff auf das Modell selbst zu benötigen
  • Excessive Agency vergrößert den Schadenradius, je mehr Werkzeuge Agenten erhalten
  • Training Data Poisoning erzeugt langfristige Risiken, die erst nach dem Deployment erkennbar werden
  • Sensitive Information Disclosure ist systemisch in RAG-Architekturen ohne Zugriffskontrollen

Prompt Injection: Die häufigste aktive Bedrohung

Prompt Injection ist die am häufigsten ausgenutzte LLM-Schwachstelle. Sie erfordert keinen Zugriff auf Modellinterna, sondern nutzt das instruktionsfolgende Verhalten des Modells selbst aus. Ein Angreifer, der Text in einen Prompt einschleusen kann, etwa über Dokumentinhalte, von einem Agenten abgerufene Webseiten oder benutzerseitige Eingaben, kann Systeminstruktionen überschreiben, den Inhalt des Kontextfensters exfiltrieren oder Werkzeugaufrufe umleiten.

Direkte Injection tritt auf, wenn ein Angreifer die Benutzereingabe kontrolliert. Sie lässt sich durch Eingabevalidierung adressieren. Indirekte Injection ist anders: Das Modell muss angreifergesteuerte Inhalte aus dem Web oder aus Dokumenten abrufen und verarbeiten. Diese Variante ist schwerer abzuwehren und nimmt zu, je mehr agentische LLM-Systeme Webseiten durchsuchen, Inhalte abrufen und eigenständig handeln.

Anforderungen an Gegenmaßnahmen: Trennen Sie Instruktionskanäle von Datenkanälen, wo es architektonisch möglich ist. Setzen Sie Ausgabevalidierung ein, die Antwortinhalte markiert, die frühere Instruktionen zu überschreiben versuchen. Implementieren Sie bei agentischen Systemen Privilegientrennung. Agenten sollten keinen Zugriff auf Werkzeuge haben, deren Ausgaben sie nicht sicher verarbeiten können, wenn die abgerufenen Inhalte feindlich sind.

Excessive Agency: Das Risiko wächst mit den Fähigkeiten

Je mehr Werkzeuge LLMs erhalten, also Code-Ausführung, Datenbankschreibzugriffe, E-Mail-Versand, API-Aufrufe, desto größer wird der Schadenradius eines kompromittierten oder fehlverhaltenden Agenten. Excessive Agency ist keine Schwachstelle im klassischen Sinne. Es ist eine Architekturentscheidung, mehr Handlungsfähigkeit zu gewähren, als das Risikomodell rechtfertigt.

Die praktische Kontrolle ist Least Privilege by Design. Ein LLM-Agent sollte nur auf die Werkzeuge zugreifen können, die für seinen definierten Aufgabenbereich erforderlich sind, und diese Werkzeuge sollten auf die minimal notwendigen Berechtigungen beschränkt sein. Ein Agent, der E-Mail-Antworten entwirft, sollte keine Sendeberechtigung haben. Für verbindliche Aktionen ist menschliche Überprüfung einzuholen.

Prüfanforderung: Dokumentieren Sie den Fähigkeitskatalog jedes eingesetzten LLM-Agenten. Halten Sie für jede Fähigkeit, also Werkzeug, API, Berechtigung, die geschäftliche Begründung und die Überprüfungsfrequenz fest. Diese Dokumentation wird zunehmend von Regulierungsbehörden gefordert, die die KI-DSGVO-Konformität in Finanzdienstleistungen und kritischer Infrastruktur prüfen.

Training Data Poisoning: Das langfristige Risiko

Im Unterschied zu Prompt Injection wirkt Training Data Poisoning auf einem langen Zeithorizont. Die Erkennung erfolgt erst, nachdem das kompromittierte Modell im Einsatz ist. Der Angriffsvektor ist die Trainingspipeline. Wenn ein Angreifer beeinflusst, welche Daten ein Modell trainieren oder feinabstimmen, kann er verzerrte Antworten, Backdoor-Trigger oder systematisch falsche Ausgaben einführen, die in bestimmten Kontexten auftreten.

Für Organisationen, die Basismodelle mit internen Daten feinabstimmen, sind folgende Kontrollen entscheidend:

  • Datenprovenienz-Tracking: Jeder Trainingsdatensatz sollte eine nachvollziehbare Quelle haben. Das erfüllt zugleich Prüfanforderungen des EU AI Act für KI-Hochrisikosysteme.
  • Eingabevalidierung vor der Aufnahme: Filtern Sie Trainingsdaten durch Konsistenzprüfungen und Anomalieerkennung, bevor sie in die Trainingspipeline eingehen.
  • Red-Team-Evaluation nach dem Training: Testen Sie gezielt auf Backdoor-Trigger und systematische Verzerrungen durch die Trainingsdaten, nicht nur auf allgemeine Fähigkeitsbenchmarks.

Sensitive Information Disclosure: Systemisch in RAG-Architekturen

RAG-Systeme, die aus großen Wissensdatenbanken abrufen, erzeugen ein spezifisches Offenlegungsrisiko. Eine geschickt formulierte Abfrage kann Inhalte aus Dokumenten abrufen und an die Oberfläche bringen, auf die der Nutzer keinen Zugriff haben sollte. Wenn das Abrufsystem keine dokumentenebenen Zugriffskontrollen durchsetzt, wird die Bereitschaft des LLM, abgerufene Inhalte zu synthetisieren und zusammenzufassen, zu einem unbeabsichtigten Umgehungsmechanismus für Zugriffskontrollen.

Die Lösung ist zugriffsgesteuertes Abrufen, ausgerichtet an Grundsätzen der Datensouveränität. Die Abrufabfrage muss auf Dokumente beschränkt sein, auf die der authentifizierte Nutzer zugreifen darf. Diese Prüfung muss vor dem Abruf erfolgen, nicht danach. Filterung nach dem Abruf ist unzureichend, da eine aus unberechtigten Quelldokumenten generierte Zusammenfassung sensible Informationen enthalten kann, selbst wenn die Quelldokumente aus der Antwort herausgefiltert werden.

Ein Sicherheitsprogramm für LLM-Systeme aufbauen

Bedrohungsmodellierung vor dem Deployment

Standardmäßige Anwendungsbedrohungsmodellierung, also die Identifikation von Assets, Bedrohungen, Angriffsvektoren und Kontrollen, gilt auch für LLM-Systeme, erfordert aber Erweiterungen. Der Prompt und das Kontextfenster sind Angriffsflächen, die in klassischen Anwendungen nicht existieren. Modellausgaben sind nicht deterministisch, was bedeutet, dass Ausgabevalidierung probabilistisch statt regelbasiert sein muss. Agentische Systeme haben dynamische Fähigkeitskataloge, die sich bei der Integration neuer Werkzeuge erweitern.

Organisationen, die LLMs in sicherheitsrelevanten Kontexten einsetzen, sollten LLM-spezifische Bedrohungsmodellierung vor dem Deployment durchführen, nicht als nachträgliche Prüfungsübung. Im Rahmen unserer KI-Beratung entwickeln wir Sicherheitsstrategien, die die spezifischen Risiken großer Sprachmodelle in Unternehmensumgebungen adressieren.

Monitoring und Anomalieerkennung im Betrieb

LLM-Systeme erfordern im Betrieb ein verhaltensbasiertes Monitoring, das über reines Request-Logging hinausgeht. Effektives Monitoring verfolgt:

  • Ungewöhnliche Prompt-Muster, die auf Injection-Versuche hinweisen können
  • Antwortinhalte, die statistisch von erwarteten Verteilungen für einen bestimmten Anwendungsfall abweichen
  • Werkzeugaufrufmuster, die nicht normalen Workflowsequenzen entsprechen
  • Kontextfensterauslastung, die auf Datenextraktionsversuche hindeuten kann

Lieferanten- und Supply-Chain-Sorgfaltspflicht

Die OWASP-Kategorie Supply Chain Vulnerabilities ist operativ relevanter geworden, da Organisationen Drittanbieter-Modell-APIs, Feinabstimmungsdienste und Plugin-Ökosysteme nutzen. Sorgfaltspflichtanforderungen für LLM-Supply-Chain-Komponenten umfassen:

  • Datenverarbeitungsvereinbarungen, die festlegen, was mit Prompts und Antworten geschieht
  • Sicherheitszertifizierungen (SOC 2, ISO 27001) für API-Anbieter, die sensible Daten verarbeiten
  • Abhängigkeitsprüfungen für LLM-Anwendungsframeworks und Plugin-Bibliotheken
  • Vertragliche Regelungen zur Benachrichtigung im Falle eines Sicherheitsvorfalls, der die gemeinsame Modellinfrastruktur betrifft

Weiterführende Inhalte