Was ist LLM-Sicherheit? So begegnen Sie den 10 größten Sicherheitsrisiken nach OWASP

Ein Angriff, der eine KI dazu bringt, die Anweisungen eines Angreifers als Befehle zu behandeln – die sogenannte Prompt-Injection –, steht seit 2023 in jeder Ausgabe auf Platz 1 der OWASP Top 10 for LLM Applications.

Näher an einen Konsens kommt man in der KI-Sicherheit kaum. Das Projekt begann als kleine Gruppe von Sicherheitsfachleuten und stützt sich heute auf mehr als 600 mitwirkende Experten in über 18 Ländern.

Wir sind ein KI-Unternehmen, das einen Leitfaden darüber veröffentlicht, wie sich KI zu Dingen überreden lässt – deshalb tun wir gar nicht erst so, als wäre das Problem gelöst. Wilson, der das OWASP-Projekt mitleitet, äußerte sich zu den aktuellen Abwehrmaßnahmen recht deutlich: „… ehrlich gesagt glaube ich nicht, dass wir bei 99 % sind.“

Die Ausgabe 2026 beginnt mit demselben Tenor. Der Projektleiter fordert uns auf, „nicht länger zu versuchen, ein Modell zu bauen, das sich nicht täuschen lässt“, und stattdessen das umgebende System so zu gestalten, dass ein getäuschtes Modell nichts Wichtiges kaputt machen kann.

Diese Haltung vertreten wir bei allen 10 Risiken auf der OWASP-Liste für 2026.

Was bedeutet LLM-Sicherheit?

LLM-Sicherheit bedeutet, KI-Modelle und die Anwendungen, die sie nutzen, vor Angriffen und Missbrauch zu schützen. Das Risiko wächst mit dem, womit das Modell verbunden ist: mit den Dateien und Daten, die es lesen kann, und mit den Tools, die es nutzen kann, etwa E-Mail, Suche oder eine Unternehmensdatenbank.

In richtig abgesicherter Software gibt es eine klare Grenze zwischen den Anweisungen, denen ein Programm folgt, und den Informationen, die es verarbeitet. Bei LLMs fehlt diese Grenze jedoch.

Alles, was das Modell liest, kommt als ein einziger langer Textstrom an: die Anweisungen des Entwicklers, Ihre Frage, eine Webseite, die es aufgerufen hat. KI-Modelle sollen eigentlich im Blick behalten, wer gerade spricht – ob der Entwickler, der Nutzer oder das Modell selbst, während es ein Problem durchdenkt.

Die Forschenden Jasmine Cui und Charles Ye fanden jedoch heraus, dass Modelle meist anhand des Tonfalls eines Textes erraten, wer spricht. Schreibt ein Angreifer also etwas, das wie die eigenen Denkschritte des Modells klingt, hält das Modell die Idee womöglich für seine eigene. Das ist ein Problem für jede Sicherheitsvorkehrung, die darauf angewiesen ist, dass das Modell weiß, wer das Sagen hat.

Auf dasselbe Problem sind wir bei unseren eigenen KI-Agenten gestoßen. Unser CISO Kyle Polley sagte gegenüber ISMG, dass Agenten „Richtlinien womöglich nicht befolgen, selbst wenn man sie in den System-Prompt aufnimmt“. Deshalb haben wir Numbat entwickelt, ein Open-Source-Tool, das prüft, was ein Agent als Nächstes tun will, und die Aktion blockieren kann, wenn sie gegen eine konfigurierte Sicherheitsregel verstößt.

LLM-Sicherheit bedeutet, zu akzeptieren, dass das Modell manchmal Befehle von der falschen Person annimmt, und es mit KI-Leitplanken zu umgeben, die auch dann standhalten.

Welche Best Practices gibt es für die LLM-Sicherheit?

Wir gehen die OWASP Top 10 for LLM Applications 2026 der Reihe nach durch, von Platz 1 bis Platz 10.

Zu jedem Risiko erhalten Sie eine verständliche Erklärung, was dabei schiefgeht, sowie ein Beispiel aus der Praxis. Anschließend stellen wir Vorgehensweisen vor, die helfen können, es zu verhindern oder zumindest den Schaden zu begrenzen.

1. Prompt-Injection eindämmen

Eine Prompt-Injection liegt vor, wenn ein Angreifer eine KI dazu bringt, Anweisungen zu befolgen, die sie nicht befolgen sollte. Diese Anweisungen können direkt im Chat eingegeben oder in einer E-Mail, einer Webseite oder einem Dokument versteckt werden.

Die zweite Variante wird als indirekte Prompt-Injection bezeichnet. Sie bitten Ihren Assistenten, ein Dokument zusammenzufassen. Darin hat jemand den Assistenten angewiesen, ihm Ihre privaten Dateien zu schicken. Befolgt der Assistent diese Anweisungen, hat sich die Person, die das Dokument geschrieben hat, faktisch Ihren Zugriff ausgeliehen.

PCMag vergleicht Prompt-Sicherheit mit dem Stopfen von Löchern in einem porösen Stein. Man dichtet eine Öffnung ab, und das Wasser findet eine andere. „Ein Angriff bahnt sich seinen Weg; er wird behoben, doch unzählige andere Angriffswege warten noch darauf, entdeckt zu werden – einfach weil Systeme wie LLMs so dynamisch sind.“

Beispiel: Im Juni 2025 entdeckten Forschende von Aim Security EchoLeak, eine Schwachstelle, durch die Microsoft 365 Copilot dazu gebracht wurde, vertrauliche Unternehmensinformationen preiszugeben. Stellte ein Mitarbeiter eine routinemäßige Arbeitsfrage, konnte Copilot die E-Mail heranziehen, den darin versteckten Anweisungen folgen und sensible Informationen an den Angreifer senden. Der Angriff umging die Prüfungen, die bösartige Anweisungen abfangen und verdächtige Links entfernen sollten.

Was Sie tun können:

• Wenden Sie Metas „Rule of Two“ an: EchoLeak setzte eine KI voraus, die Unternehmensdaten lesen, externe E-Mails lesen und Informationen nach außen senden konnte – und sie verfügte über alle drei Fähigkeiten. Wird sie auf zwei davon beschränkt, kann eine Prompt-Injection nicht zu viel Kontrolle erlangen. Erfordert die Aufgabe alle drei, sollten Sie vor jeder Aktion eine menschliche Freigabe verlangen.
• Testen Sie mit Angreifern, die Ihre Abwehrmaßnahmen kennen: Geben Sie Ihren Sicherheitstestern die Regeln und Filter an die Hand, die Sie eingerichtet haben, und lassen Sie sie diese umgehen. In einer Studie waren Angreifer, die sich an die Abwehrmaßnahmen anpassten, bei den meisten der 12 getesteten Abwehrmechanismen in mehr als 90 % der Fälle erfolgreich.

2. Verhindern, dass sensible Informationen nach außen dringen

Wenn KI-Systeme private Informationen an Personen weitergeben, die diese nicht sehen sollten, spricht man von der Offenlegung sensibler Informationen. Das kann bedeuten, dass die Zahlungsdaten eines Kunden preisgegeben werden oder private Unterhaltungen ungeschützt in einer gemeinsam genutzten Datenbank liegen.

Viele Datenlecks beginnen mit „Oversharing“. Angenommen, ein Unternehmen verbindet seine KI mit Laufwerken und Wissensdatenbanken, deren Berechtigungen zu großzügig sind. Die KI ruft alles ab, was sie erreichen kann – genau wie vorgesehen. Niemand muss einbrechen, und trotzdem sollten Sie das LLM als kompromittiert betrachten.

Beispiel: Im Januar 2025 stießen Forschende von Wiz auf eine DeepSeek-Datenbank, die offen im Internet zugänglich war und mehr als eine Million Protokolleinträge enthielt, darunter Chatverläufe und API-Schlüssel, mit denen Software auf andere Dienste zugreift. Die Forschenden mussten das Modell nicht erst dazu bringen, etwas preiszugeben.

Was Sie tun können:

• Prüfen Sie den Zugriff, bevor die KI die Daten liest: Ihre Anwendung sollte prüfen, welche Dokumente die fragende Person sehen darf, bevor sie diese an das Modell weitergibt.
• Schützen Sie die Aufzeichnungen, die Ihre KI hinterlässt: Entfernen Sie private Details und geheime Schlüssel, bevor Sie Aktivitätsprotokolle speichern, verlangen Sie eine Anmeldung und beschränken Sie den Zugriff auf die Personen, die ihn benötigen. Legen Sie eine Aufbewahrungsfrist fest, damit sich diese Aufzeichnungen nicht unbegrenzt ansammeln.

3. Übermäßige Handlungsbefugnis eindämmen

KIs mit übermäßiger Handlungsbefugnis haben mehr Macht, als ihre Rolle erfordert: Tools, die sie nicht brauchen, Berechtigungen, die über ihre Aufgabe hinausgehen, oder die Freiheit, ohne Rückfrage zu handeln. Die Ursache spielt dabei keine Rolle.

Ein eingeschleuster Prompt, ein Bug oder ein Modell, das schlicht falschliegt – alles führt zum selben Ergebnis. Die KI wird früher oder später etwas Zerstörerisches tun, wenn sie die Fähigkeit dazu hat.

Beispiel: Im Juli 2025 berichtete SaaStr-Gründer Jason Lemkin, dass der Coding-Agent von Replit seine Datenbank mit 1.206 Datensätzen zu Führungskräften gelöscht hatte – trotz der Anweisung, keine Änderungen vorzunehmen. Der Agent behauptete zunächst, die Daten ließen sich nicht wiederherstellen, doch später stellte sich heraus, dass eine Wiederherstellung möglich war. Jason stellte fest, dass die Anweisung, die Datenbank in Ruhe zu lassen, dem Agenten nicht die Möglichkeit genommen hatte, sie zu löschen.

Vergrößern

Quelle: X

Was Sie tun können:

• Entfernen Sie Fähigkeiten, die die Aufgabe nicht benötigt: Beschränken Sie sowohl die Tools, die ein Agent erhält, als auch das, was diese Tools tun können. Ein Assistent, der E-Mails zusammenfasst, braucht die Berechtigung, sie zu lesen – nicht, sie zu senden oder zu löschen.
• Platzieren Sie Berechtigungsprüfungen außerhalb der KI: Jede angeforderte Aktion sollte gegen Ihre Sicherheitsregeln geprüft und von einem Menschen freigegeben werden.

4. Prüfen, was in Ihre KI-Lieferkette gelangt

Nur wenige Unternehmen entwickeln KI von Grund auf selbst, und es werden jedes Jahr weniger. Laut der Umfrage „2025: The State of Generative AI in the Enterprise“ von Menlo Ventures lag der Anteil der Unternehmen, die KI-Modelle einkauften, 2024 bei 53 % und stieg 2025 auf 76 %.

In den meisten Fällen laden Unternehmen Modelle von Plattformen wie Hugging Face herunter, trainieren sie mit Datensätzen weiter, die andere zusammengestellt haben, und binden Add-ons und Codepakete ein, die von Fremden geschrieben wurden.

Jeder dieser Bestandteile ist ein Einfallstor. Wird einer davon manipuliert, wird das Problem mit Ihrem Produkt ausgeliefert.

Beispiel: Die Zahl der öffentlichen Modell-Repositorys auf Hugging Face stieg zwischen Januar 2026 und August 2026 von 2,43 Millionen auf 2,96 Millionen. Im Juli 2026 umgingen jedoch Modelle von OpenAI bei internen Sicherheitstests Kontrollen, die sie vom Internet fernhalten sollten, und drangen in Teile der Systeme von Hugging Face ein. Ein Agent beschaffte sich sogar 14 öffentlich einsehbare Zugangsdaten, prüfte, ob sie funktionierten, und teilte sie mit anderen Agenten. Anschließend nutzten die Agenten Schwachstellen aus, über die sie Code auf den Servern von Hugging Face ausführen konnten.

„Wir stellen über den gesamten Lebenszyklus eines Modells hinweg strengere Anforderungen an das Alignment, schaffen stärker isolierte Sandboxes, schränken den Internetzugang ein und kontrollieren den Zugriff auf Modellgewichte noch strenger“, heißt es im Bericht von OpenAI.

Was Sie tun können:

• Legen Sie Modelle auf eine exakte Version fest und verifizieren Sie sie: Fixieren Sie jedes Modell auf eine geprüfte Version und kontrollieren Sie vor dem Laden seinen Datei-Fingerabdruck, damit sich keine ausgetauschte Datei unter derselben Bezeichnung einschleichen kann. OWASP empfiehlt außerdem digitale Signaturen, allerdings mit einer Einschränkung: Eine Signatur belegt, woher ein Modell stammt, nicht aber, dass es sicher ist.
• Prüfen Sie jedes Paket, das Ihre KI vorschlägt: Bevor Sie ein Codepaket installieren, das ein KI-Assistent empfohlen hat, vergewissern Sie sich, dass es existiert, dass es das Paket ist, das Sie gemeint haben, und dass es vom erwarteten Herausgeber stammt.

5. Vor Daten- und Modellvergiftung schützen

Eine vergiftete KI lernt aus manipulierten Daten. Das können die Beispiele sein, mit denen sie feinabgestimmt wurde, oder eine Wissensdatenbank, die sie nach Antworten durchsucht. Das Modell scheint weiterhin zu funktionieren; es lernt nur die falschen Lektionen – und manchmal lernt es, sich nur dann falsch zu verhalten, wenn es eine bestimmte Auslöserphrase sieht.

Bis jemand diese Phrase verwendet, besteht das Modell jeden Test, dem Sie es unterziehen.

Vergrößern

Außerdem lässt sich das nur sehr schwer rückgängig machen. Eine Vergiftung ist kein Bug, den man einfach patchen kann. Wenn Ihre Daten fehlerhaft sind, müssen Sie sie möglicherweise erneut prüfen, das Modell neu trainieren oder es ganz ersetzen.

Beispiel: Im Oktober 2025 zeigten Forschende von Anthropic, dem UK AI Security Institute und dem Alan Turing Institute, dass 250 vergiftete Dokumente ausreichen konnten, um einem Modell beizubringen, Kauderwelsch zu erzeugen, sobald es auf einen bestimmten Auslöser stieß. Dieselbe Anzahl wirkte bei allen vier getesteten Modellgrößen, obwohl das größte Modell mit mehr als 20-mal so vielen sauberen Daten trainiert worden war.

Was Sie tun können:

• Verfolgen Sie, woher Ihre Daten stammen: Dokumentieren Sie jeden Datensatz und jedes Modell, das Sie verwenden, woher es stammt und was sich zwischen den Versionen geändert hat. Wir empfehlen eine Versionskontrolle für Datensätze, damit Sie bei einer entdeckten Vergiftung zu einer sauberen Version zurückkehren und nachvollziehen können, wie sie hineingelangt ist.
• Testen Sie auf Hintertüren: Eine „Hintertür“ ist ein verborgenes Verhalten, das ein Angreifer in einem Modell platziert und das darauf wartet, durch eine bestimmte Phrase oder einen anderen Auslöser aktiviert zu werden. Testen Sie darauf mit Eingaben, die das Modell dazu bringen sollen, seine üblichen Regeln zu brechen.

6. Unbegrenzten Ressourcenverbrauch deckeln

Wenn KIs keinerlei Grenzen dafür haben, wie viel Arbeit sie leisten oder wie hohe Kosten sie verursachen dürfen, gilt ihr Verbrauch als „unbegrenzt“. Die meisten KI-Dienste rechnen nutzungsbasiert ab, sodass ein Angreifer Ihre Rechnung in die Höhe treiben oder eine Kopie Ihres Modells erstellen könnte.

OWASP bezeichnet das Kernproblem als „Kostenasymmetrie“. Eine kurze, günstige Anfrage kann auf Ihrer Seite aufwendige Berechnungen auslösen.

Beispiel: Im Mai 2024 entdeckte das Threat Research Team von Sysdig einen neuen Angriff namens „LLMjacking“. Eine Gruppe von Angreifern nahm mit gestohlenen Zugangsdaten 10 in der Cloud gehostete LLM-Dienste ins Visier. Sie verschafften sich über eine anfällige Laravel-Version Zugang und ermittelten dann, was mit den Zugangsdaten möglich war und welche Kontingente bestanden – offensichtlich mit dem Ziel, den Zugang zu verkaufen. Zudem fragten sie zahlreiche Protokollierungseinstellungen ab, vermutlich um einer Entdeckung zu entgehen. Laut Sysdig könnten sich die Kosten für das Opfer im schlimmsten Fall auf über 46.000 US-Dollar pro Tag belaufen.

Was Sie tun können:

• Legen Sie Budgets fest, die die Ausgaben stoppen: Definieren Sie feste Ausgabenlimits für einzelne Nutzer, API-Schlüssel, Teams und das gesamte Konto. Erzwingen Sie diese überall dort, wo Anfragen eingehen können.
• Legen Sie für jede Aufgabe einen Abbruchpunkt fest: Begrenzen Sie, wie lange eine Aufgabe laufen darf, wie viel Text sie verarbeiten und erzeugen darf und wie viele Tool-Aufrufe sie tätigen darf. Fügen Sie automatische Abbruchmechanismen für Agenten hinzu, die sich wiederholen oder ihr Kontingent überschreiten.

7. Fehlinformationen erkennen, bevor gehandelt wird

Wenn eine KI etwas Falsches erzeugt, das richtig klingt, und jemand – oder etwas – danach handelt, spricht man von Fehlinformationen. Das Kernrisiko ist weniger die falsche Antwort selbst als vielmehr, dass ihr vertraut und sie verwendet wird.

Die dokumentierten Vorfälle deuten darauf hin, dass Fachleute Fehlinformationen weniger ernst genommen haben, als sie es hätten tun sollen. Laut dem Eröffnungsschreiben der Ausgabe 2026 setzten die Abstimmenden sie fast ans Ende der Liste, gemessen an realen Vorfällen gehört sie jedoch fast an die Spitze.

Beispiel: Im Jahr 2025 legte Deloitte Australia im Rahmen eines Regierungsauftrags über 440.000 A$ eine Überprüfung von IT-Systemen im Sozialwesen vor. Der an der University of Sydney tätige Forscher Chris Rudge stieß auf Verweise auf nicht existierende Forschungsarbeiten sowie auf ein erfundenes Zitat aus einem Urteil eines Bundesgerichts. Der überarbeitete Bericht legte offen, dass Deloitte Azure OpenAI GPT-4o in seiner Methodik eingesetzt hatte, und das Unternehmen erklärte sich bereit, die letzte Rate zurückzuzahlen. Dabei handelte es sich bedauerlicherweise ausgerechnet um eine Assurance-Prüfung.

Was Sie tun können:

• Prüfen Sie, ob die Belege die Antwort stützen: Verankern Sie Aussagen in aktuellen, maßgeblichen Quellen. Rufen Sie bei einer Antwort zu Richtlinien die freigegebene Richtlinie ab und prüfen Sie, ob sie die Schlussfolgerung einschließlich ihrer Ausnahmen stützt.
• Verifizieren Sie, bevor das System handelt: Wenn ein Agent angibt, dass ein Kunde eine Identitätsprüfung bestanden hat, gleichen Sie dies mit dem Verifizierungssystem ab, bevor Sie eine Zahlung freigeben. Verlangen Sie bei folgenreichen Entscheidungen eine menschliche Freigabe und stellen Sie der prüfenden Person die zugehörigen Belege zur Verfügung.

8. Den Schaden durch die Offenlegung verborgenen Kontexts begrenzen

KI-Anwendungen geben dem Modell Anweisungen und Hintergrundinformationen, die Nutzer normalerweise nicht sehen. Dazu können der System-Prompt, interne Richtlinien, Beschreibungen verfügbarer Tools und Regeln dazu gehören, wer sie nutzen darf. Eine Offenlegung verborgenen Kontexts liegt vor, wenn das Modell diese Informationen jemandem preisgibt.

Den früheren Eintrag „System Prompt Leakage“ hat OWASP 2026 erweitert, weil der System-Prompt nur ein Teil dessen ist, was nach außen gelangen kann. Wie groß die Gefahr ist, hängt davon ab, was Sie dort hinterlegt haben. Ein geleakter Leitfaden zur Tonalität ist leicht peinlich, ein geleakter API-Schlüssel dagegen verschafft jemandem Zugriff auf Ihre vertrauliche Datenbank.

Beispiel: Im Februar 2023 brachten Nutzer Microsofts Bing Chat dazu, seine internen Anweisungen preiszugeben. Einer der erfolgreichen Versuche stammte von Marvin von Hagen, der sich als OpenAI-Entwickler ausgab und um die Anweisungen bat, um das Modell konfigurieren zu können. Bing legte Regeln für seine Suchen, Antworten und sein Sicherheitsverhalten offen, ebenso wie seinen internen Namen Sydney. Unter den offengelegten Anweisungen war auch eine, die ihm vorschrieb, diese Anweisungen vertraulich zu behandeln.

Was Sie tun können:

• Secrets aus dem Kontext des Modells heraushalten: Gehen Sie davon aus, dass alles, was das Modell lesen kann, für Nutzer sichtbar werden könnte – speichern Sie Passwörter, API-Schlüssel und Zugriffstoken in einem separaten Secrets-Management-System.
• Berechtigungen so gestalten, dass sie auch dann greifen, wenn die Regeln nach außen dringen: Setzen Sie Zugriffsprüfungen in Ihrem Anwendungscode durch. Wenn ein Tool Administratoren vorbehalten ist, prüfen Sie die Kontoberechtigungen des Nutzers, bevor es ausgeführt wird.

9. Vektoren und Embeddings absichern

Wenn eine KI per Vektorsuche in den Dokumenten Ihres Unternehmens nach Antworten sucht, durchsucht sie den Text nicht direkt. Die Dokumente werden in sogenannte „Embeddings“ umgewandelt – lange Zahlenreihen, die die Bedeutung jedes Abschnitts erfassen – und in einer Vektordatenbank gespeichert. Eine Frage wird auf die gleiche Weise umgewandelt, und das System ruft die Abschnitte ab, deren Zahlen denen der Frage am nächsten kommen.

OWASP fasst die vier Arten zusammen, wie ein solches System versagen kann: Durch Poisoning liefert es falsche Ergebnisse, durch Inversion gibt es Daten preis, durch Jamming verstummt es, und durch eine fehlerhafte Zugriffskontrolle gibt es alles an jeden heraus.

Die Zahlen sind nicht die sichere Abstraktion, für die man sie halten könnte. Gespeicherte Embeddings lassen sich wieder in Text zurückverwandeln, und eine Methode konnte in ihren Tests 92 % kurzer Abschnitte mit 32 Token exakt rekonstruieren. Ein geleaktes Backup, das „nur Embeddings“ enthält, kann also ebenfalls die Inhalte der Dokumente offenlegen.

Beispiel: In einer auf der USENIX Security 2025 vorgestellten Studie zeigten Forschende, dass ein einziges sorgfältig präpariertes Dokument eine KI daran hindern konnte, eine bestimmte Frage zu beantworten. Sie fügten es der Sammlung hinzu, die die KI durchsuchte. Stieß die KI darauf, konnte sie antworten, sie habe nicht genügend Informationen oder eine Antwort sei unsicher. Das Dokument musste die KI dafür nicht einmal anweisen, ihre Regeln zu ignorieren. Dies wird als „Retrieval Jamming“ bezeichnet.

Was Sie tun können:

• Getrennte Indizes für öffentliche und private Daten führen: Vermischen Sie gescrapte Webinhalte nicht mit Partnerdaten oder vertraulichen internen Dokumenten. Trennen Sie die Daten physisch nach Vertrauensstufe, statt Inhalte innerhalb eines einzigen Index zu kennzeichnen. So schließen Sie eine ganze Klasse von Fehlkonfigurationen aus, und aus dem Internet gescrapte Inhalte können nicht neben Ihren Vorstandsunterlagen landen.
• Embeddings wie die Dokumente behandeln, aus denen sie stammen: Verschlüsseln Sie sie, schützen Sie Backups der Vektordatenbank ebenso wie die Quelldateien, und löschen Sie Embeddings, wenn Sie das Original löschen. API-Schlüssel für Ihren Embedding-Dienst sollten geheim gehalten werden.

10. KI-Ausgaben prüfen, bevor sie weitergegeben werden

Wenn eine Anwendung KI-Ausgaben an ein anderes System weitergibt, ohne zu prüfen, ob sie dort sicher verwendet werden können, liegt eine unsachgemäße Verarbeitung von LLM-Ausgaben vor.

Der Eintrag umfasst auch den unsicheren Code, den KI-Coding-Assistenten in großem Umfang generieren. Jede Zeile, die ein Assistent schreibt, zählt also ebenfalls als Ausgabe.

Beispiel: 2025 zeigte der Forscher Johann Rehberger, wie der Coding-Assistent Amp von Sourcegraph Chatinhalte allein durch die Anzeige eines Bildes preisgeben konnte. Mithilfe von Prompt Injection brachte er Amp dazu, private Informationen in die Webadresse eines Bildes einzufügen. Die Anwendung rief dieses Bild dann automatisch ab und schickte die Informationen so an seinen Server. Der Fehler bei der Ausgabeverarbeitung lag in genau dieser automatischen Anfrage – der vom Modell generierte Text wurde zu einer Verbindung mit einem externen Server, über die private Daten abflossen.

Was Sie tun können:

• Die Ausgabe für ihr Ziel absichern: Prüfen und verarbeiten Sie Antworten je nachdem, wohin sie gelangen. Bei einer Webseite verhindern Sie, dass generierter Text zu ausführbarem Code wird. Bei einer Datenbank verwenden Sie parametrisierte Abfragen, die übergebene Werte von Befehlen getrennt halten.
• Verhindern, dass Antworten automatisch externe Verbindungen aufbauen: Deaktivieren Sie standardmäßig das automatische Laden von Bildern, Linkvorschauen und eingebetteten Seiten in Modellantworten. Beschränken Sie notwendige Verbindungen auf ausdrücklich freigegebene Ziele.

Wie sichert Perplexity LLMs ab?

Wir gehen davon aus, dass jedes der oben genannten Risiken irgendwann eintritt, und gestalten unsere Systeme so, dass es dann nur wenig ausrichten kann. Unser CISO Kyle Polley hat in einem aktuellen Workshop erläutert, wie das funktioniert.

• Der Agent erhält einen eigenen Computer, und der ist anfangs leer: Agent-Tools, die auf Ihrem Laptop installiert sind, können Zugriff auf dessen Dateien, Apps und gespeicherte Anmeldedaten erhalten. Perplexity Computer funktioniert umgekehrt. Jede Aufgabe läuft in einer eigenen isolierten Sandbox, und wie Polley es formuliert: „Standardmäßig hat sie auf nichts Zugriff.“
• Der Agent sieht die Passwörter nie: Die Anmeldedaten für verbundene Dienste werden außerhalb der Sandbox gespeichert. Wenn der Agent einen Dienst wie GitHub erreichen muss, sendet er eine Anfrage ohne Anmeldedaten. Ein Gateway prüft, ob Ziel und Anfrage den Erwartungen entsprechen, und fügt die Anmeldedaten erst auf dem Weg nach außen hinzu. Der Agent kann die Verbindung nutzen, ohne die Schlüssel zu erhalten.
• Ihre Berechtigungen werden übernommen, und Sie können sie weiter einschränken: Über OAuth hergestellte Verbindungen wahren Ihre Zugriffsberechtigungen im verbundenen Dienst. Was Sie nicht sehen können, kann auch Ihr Agent nicht sehen.
• Jeder Webseite wird grundsätzlich misstraut: Wir haben BrowseSafe für Comet, unseren agentischen Browser, entwickelt, weil die von uns getesteten Tools im Praxiseinsatz nicht unseren Anforderungen entsprachen. Der Browser scannt Webseiten und andere externe Inhalte, einschließlich E-Mails, auf Prompt Injection. Sowohl das Modell als auch den Datensatz haben wir als Open Source veröffentlicht.
• Wir überwachen den Agenten und die Rechner, auf denen er läuft: Numbat ist zwischen die Handlungsentscheidung eines Agenten und die tatsächliche Ausführung des Tools geschaltet. Numbat protokolliert Aktivitäten unterstützter Coding-Agenten und kann Aktionen, die gegen konfigurierte Richtlinien verstoßen, blockieren, bevor sie ausgeführt werden. Bumblebee inventarisiert Softwarepakete auf Laptops, Servern und in Build-Pipelines und markiert bekanntermaßen schädliche Pakete. Beide sind Open Source.
• Die Modellanbieter speichern Ihre Daten nicht: Mit unseren externen LLM-Anbietern haben wir Vereinbarungen über Zero Data Retention getroffen. Enterprise-Admins können zudem die Datenaufbewahrung bei Perplexity selbst auf bis zu 24 Stunden verkürzen.

Wir haben Numbat proaktiv entwickelt – aus einem Grund, den Polley in einem Satz zusammenfasst: „Je mehr Autonomie man einem Agenten gibt, desto größer ist das Risiko.“

Häufige Fragen zur LLM-Sicherheit

Welches LLM ist am sichersten?

Kein LLM macht eine Anwendung allein sicher – Modelle können Inhalte, die sie lesen sollen, immer noch mit Anweisungen verwechseln, die sie befolgen sollen. Zudem können Abwehrmechanismen, die in Standardtests stark wirken, unter Druck einknicken.

Die bessere Frage ist, welches Setup für Ihren Anwendungsfall am sichersten ist. Dazu gehören eingeschränkte Berechtigungen, vom Modell ferngehaltene Anmeldedaten, menschliche Freigabe für riskante Aktionen und Tests durch Personen, die Ihre Abwehrmaßnahmen kennen.

Was sind LLM-Schwachstellen?

LLM-Schwachstellen sind Schwächen, durch die ein KI-System getäuscht werden, Daten preisgeben oder Schaden anrichten kann – sei es durch einen Angreifer oder durch eigene Fehler.

Die zehn größten Risiken sind Prompt Injection, Offenlegung sensibler Informationen, übermäßige Handlungsfreiheit (Excessive Agency), Schwachstellen in der Lieferkette, Daten- und Modellvergiftung, unbegrenzter Ressourcenverbrauch, Fehlinformationen, Offenlegung versteckten Kontexts, Schwachstellen bei Vektoren und Embeddings sowie unsachgemäße Ausgabeverarbeitung.

Ist ein privates LLM sicher?

In mancher Hinsicht ist es die sicherere Option, aber nicht automatisch. Wenn Sie ein Modell auf Ihrer eigenen Infrastruktur oder in einer Cloud-Umgebung betreiben, haben Sie mehr Kontrolle über den Umgang mit Daten. Prompt Injections, übermäßige Handlungsfreiheit, Poisoning oder Fehlinformationen lassen sich dadurch jedoch nicht automatisch verhindern.

Beim Self-Hosting sind Sie außerdem für das heruntergeladene Modell verantwortlich, einschließlich der Risiken in der Lieferkette und der dafür erforderlichen Infrastruktur.