Wie sich die „tödliche Dreifachbedrohung“ der KI stoppen lässt

• LLMs haben ein strukturelles Problem, Code und Daten nicht trennen zu können, und sind daher anfällig für Prompt-Injection-Angriffe
• Vor allem wenn Zugriff auf externe Daten, Einsicht in interne Geheimnisse und Berechtigungen zur externen Kommunikation gleichzeitig gegeben sind, entsteht die sogenannte tödliche Dreierkombination (lethal trifecta), die zu schwerwiegenden Schäden führen kann
• AI-Ingenieure sollten wie Maschinenbauingenieure denken und statt eines deterministischen Ansatzes die Unsicherheit probabilistischer Systeme akzeptieren und mit Sicherheitsreserven arbeiten
• So wie Ingenieure im viktorianischen Zeitalter wegen der Unsicherheit von Materialien mit Überdimensionierung Sicherheitsreserven einplanten, sollten auch AI-Systeme Sicherheitsgrenzen, Risikotoleranzen und Fehlerraten einführen
• Wie Brücken in der physischen Welt Lastgrenzen haben, ist es nun an der Zeit, auch für AI-Systeme Normen mit expliziten Grenzen und Sicherheitsreserven festzulegen

---

Das grundlegende Sicherheitsproblem von LLMs

• Große Sprachmodelle haben den strukturellen Mangel, Code und Daten nicht trennen zu können
• Dadurch sind sie anfällig für Prompt-Injection-Angriffe
  • Das System wird dazu verleitet, Anweisungen zu befolgen, denen es nicht folgen sollte
  • Mitunter führt das nur zu peinlichen Ergebnissen, etwa wenn ein Kundensupport-Agent plötzlich wie ein Pirat spricht
  • In anderen Fällen entstehen jedoch deutlich zerstörerischere Schäden

Die tödliche Dreierkombination (Lethal Trifecta)

• Die schlimmsten Auswirkungen entstehen, wenn die „tödlichen drei Elemente“ zusammenkommen
• Die drei Bestandteile sind
  • Zugriff auf nicht vertrauenswürdige Daten
  • die Fähigkeit, wichtige vertrauliche Informationen zu lesen
  • die Fähigkeit, mit der Außenwelt zu kommunizieren
• Wenn Unternehmen ihren Mitarbeitern leistungsfähige AI-Assistenten geben wollen und ihnen alle drei Fähigkeiten zugleich gewähren, sind schwerwiegende Probleme nahezu unvermeidlich
• Nicht nur AI-Ingenieure, sondern auch normale Nutzer müssen lernen, AI sicher zu verwenden
  • Durch die Installation der falschen App-Kombination kann diese Dreierkombination versehentlich entstehen

Ein Umdenken bei der Denkweise von AI-Ingenieuren ist nötig

Denken wie Maschinenbauingenieure

• Besseres AI-Engineering ist die wichtigste Verteidigungslinie
• AI-Ingenieure sollten wie Ingenieure denken, die Bauwerke wie Brücken errichten
  • im Bewusstsein, dass schlechte Arbeit Menschenleben kosten kann

Lehren aus dem viktorianischen Ingenieurwesen

• Die großen Bauwerke des viktorianischen Großbritanniens wurden von Ingenieuren errichtet, die sich der Eigenschaften ihrer Materialien nicht sicher sein konnten
  • Eisen war damals wegen Inkompetenz oder Betrug oft von geringer Qualität
  • Daher entschieden sich die Ingenieure für Vorsicht und integrierten Redundanz durch Überdimensionierung
  • Das Ergebnis waren Meisterwerke, die Jahrhunderte überdauerten

Das aktuelle Problem der AI-Sicherheitsbranche

• Anbieter von AI-Sicherheit denken nicht auf diese Weise
• Klassische Softwareentwicklung ist deterministisch
  • Sicherheitslücken gelten als Fehler, die behoben werden müssen
  • Nach der Behebung sind sie verschwunden
• AI-Ingenieure haben sich seit ihrer Ausbildung an diese Denkweise gewöhnt
  • Deshalb handeln sie so, als ließe sich das Problem allein mit mehr Trainingsdaten und raffinierteren System-Prompts lösen

Ein Ansatz, der zu probabilistischen Systemen passt

Grenzen von Trainingsdaten und Prompts

• Trainingsdaten und kluge Prompts senken zwar das Risiko
  • Die intelligentesten aktuellen Spitzenmodelle erkennen und verweigern bösartige Anfragen besser als frühere oder kleinere Modelle
• Doch vollständig beseitigen lässt sich das Risiko nicht
  • Anders als die meiste Software sind LLMs probabilistisch
  • Die Ausgabe wird durch eine zufällige Auswahl unter möglichen Antworten bestimmt
  • Daher sind deterministische Sicherheitsansätze ungeeignet

Nachahmung des Engineerings der physischen Welt

• Ein besserer Weg ist, die Ingenieure der physischen Welt nachzuahmen
• Zu lernen, mit unvorhersehbaren Systemen zu arbeiten
  • also nicht gegen launische Systeme anzukämpfen, deren korrektes Verhalten sich nicht garantieren lässt, sondern mit ihnen zu arbeiten
• Mit Sicherheitsreserven, Risikotoleranzen und Fehlerraten die Unvorhersehbarkeit besser beherrschbar machen

Strategien der Überdimensionierung im AI-Zeitalter

• Leistungsfähigere Modelle als eigentlich nötig einsetzen
  • um das Risiko zu senken, zu unangemessenem Verhalten verleitet zu werden
• Die Zahl der Anfragen begrenzen, die ein LLM aus externen Quellen annehmen darf
  • abgestimmt auf das Schadensrisiko durch bösartige Anfragen
• Sicheres Scheitern in den Mittelpunkt stellen
  • Wenn ein AI-System auf vertrauliche Informationen zugreifen muss, sollte man ihm nicht gleich die Schlüssel zum Königreich überlassen

Warum Sicherheitsgrenzen gesetzt werden müssen

• In der physischen Welt haben Brücken Lastgrenzen
  • auch wenn diese für Fahrer nicht immer klar sichtbar sind, existieren sie
  • entscheidend ist: Diese Grenzwerte lassen innerhalb des rechnerisch tragbaren Bereichs der Brücke ausreichend Reserve
• Nun ist es an der Zeit, auch die virtuelle Welt von AI-Systemen ähnlich auszustatten
• Systeme mit klaren Sicherheitsgrenzen und ausreichenden Reserven zu entwerfen, ist unverzichtbar

[GN⁺]

Hacker-News-Kommentare

• Archivlink zum Artikel
• Dies ist bereits der zweite Economist-Artikel in dieser Woche, der die lethal trifecta erwähnt. Der erste war AI-Systeme werden nie vollständig sicher sein — die „lethal trifecta“, auf die man reagieren muss, der meiner Meinung nach am klarsten in den Medien erklärt, was Prompt Injection ist und warum sie gefährlich ist. Ich werde darin auch zitiert, daher bin ich vielleicht etwas voreingenommen, aber ich würde den Artikel Führungskräften unbedingt empfehlen. Den neuen Artikel mag ich dagegen nicht besonders. Er erwähnt, dass LLMs nichtdeterministisch sind und Sicherheitslücken deshalb schwer zu beheben seien, und benutzt daher die Analogie, man müsse sie wie Brücken „überengineeren“ und auf Toleranzen auslegen. Für Brücken mag das passen, aber bei Sicherheitslücken ist es meiner Ansicht nach keine grundlegende Lösung. Wenn ein System nur einmal in 100 Versuchen durch Prompt Injection kompromittiert wird, wird ein Angreifer so lange Varianten ausprobieren, bis es klappt. Wenn man bei der lethal trifecta auch nur eines der Elemente blockiert — Zugriff auf nicht öffentliche Daten, Ausführung nicht vertrauenswürdiger Anweisungen, externer Exfiltrationspfad — kann der Angriff nicht zustande kommen
  • Brückenbauer entwerfen in der Regel nicht für aktive, gegnerische Angriffe. Und selbst wenn doch, konzentrieren sie sich eher darauf, dass sich eine Brücke leicht verlegen und schnell neu aufbauen lässt, statt sie maximal robust zu machen. Eine zusätzliche Behelfsbrücke zu errichten ist schneller und billiger als eine extrem stabile Brücke zu bauen, die Bombardements übersteht. Siehe konkretes Beispiel
  • LLMs sind wie Menschen nichtdeterministisch. Deshalb kann man Sicherheitsmanagement auch ähnlich wie bei Menschen angehen. Man sollte ihnen per rollenbasierter Zugriffskontrolle nur die minimal nötigen Rechte geben und riskante oder kostspielige Aktionen durch Freigabeprozesse absichern. Bei wichtigen Organisationen in Technik, Infrastruktur, Verteidigung oder Finanzen ist es Standard, das Bedrohungsmodell so aufzusetzen, als ob sich Agenten ausländischer Staaten wie Russland, China, Israel oder Nordkorea im Team befinden könnten
  • Eigentlich sind beide Artikel derselbe Artikel. Im Economist gibt es vorne in jeder Ausgabe die Reihe „Leaders“, die die tiefergehenden Artikel derselben Ausgabe verkürzt und verallgemeinert zusammenfasst. Im Grunde wird auf die ganze Zeitung eine umgekehrte Pyramide angewendet (Erklärung zur umgekehrten Pyramide). Der verlinkte Artikel fungiert auch diesmal als eine Art Kurzfassung des eigentlichen Problemartikels
  • Ich denke bei Sicherheitsproblemen von LLMs an die Frage: „Was wäre, wenn mein Code durch Social Engineering kompromittiert werden könnte?“ LLMs sind Menschen darin ähnlich, dass sie sich trotz allen Trainings täuschen lassen. Wenn man einem Computer Root-Rechte gibt und dann jeden auf der Welt mit dem LLM sprechen lässt, wird er zwangsläufig verwundbar. So wie man Menschen keine unbegrenzten Befugnisse delegiert, sollte man auch LLMs keinen Zugriff auf datenfremde Informationen eines Anfragenden oder Änderungen an Nutzerdaten erlauben
  • Das Problem ist, dass es reicht, nur einen Teil der lethal trifecta abzuschneiden. In Wirklichkeit sind diese drei Elemente miteinander verflochten. Externe Inhalte wie E-Mails können zum Beispiel selbst personenbezogene Informationen sein, und wenn man E-Mails versendet, kann der Inhalt meines Posteingangs zum Angreifer gelangen. Außerdem sind E-Mail, GitHub usw. gerade dann am nützlichsten, wenn sowohl Senden als auch Empfangen möglich ist; für jede Funktion einen eigenen dedizierten Server zu betreiben, ist ineffizient
• Mit meinem Hintergrund im Maschinenbau wirkt dieser Artikel unzureichend. Man hört oft „man muss einfach mehr Stärke hinzufügen“, aber in der Praxis geht das nur, wenn man die verschiedenen Ausfallmodi im Detail versteht. Die lethal trifecta ist nur ein Ausfallmodus, und man fügt „Stärke“ hinzu, um genau diesen zu verhindern. Nicht: „Diese Brücke schwingt zu stark, also überlegen wir, wie man eine schwingende Brücke sicher überquert“, sondern: Man ändert die Brücke so, dass sie gar nicht erst übermäßig schwingt
  • Ich habe das Gefühl, die Welt ist verrückt geworden. In dieser Brücken-Analogie wäre es so, als gäbe es seit Langem Brückenbautechnik, aber gelegentlich verschwindet plötzlich der Boden und Menschen fallen in den Fluss, und statt über andere Ansätze zu reden, sagt man: „Spannen wir unten ein Netz und fangen wir sie auf, wenn alle runterfallen.“ Wir pumpen Milliarden in eine im Kern unvorhersehbare Technologie und fügen dann einfach noch ein paar Leitplanken hinzu. Das ist wirklich absurd
  • Sobald in einem Artikel „coders need to“ steht, verliere ich sofort das Interesse. Die Analogie selbst fühlt sich falsch an und klingt auch für Leute mit echter Praxiserfahrung im Feld unpassend. Schon die Beispielannahme des Journalisten — dass ein LLM im Unternehmen gleichzeitig untrusted data, sensible Informationen und externe Kommunikation haben darf — ist das eigentliche Problem. Unternehmen schaffen solche Risiken oft selbst, weil sie Funktionalität über Sicherheit stellen. Die Behauptung „LLMs sind nicht probabilistisch, daher ist ein deterministischer Ansatz ungeeignet“ ist ein logischer Sprung. Auch bei Nichtdeterminismus bleibt die Sandbox-Logik gültig. Anders gesagt: Wenn man die Analogie zu weit zieht, hilft sie dem Bereich am Ende eher nicht. Es wäre besser, mit den tatsächlichen Begriffen und dem Fachwissen der Domäne zu arbeiten, aber dann wäre der Artikel vermutlich weniger attraktiv
• Behauptet der Artikel ernsthaft, dass Geschwindigkeitsbegrenzungen und bessere Modelle die einzige Lösung seien? Softwareingenieure beschäftigen sich mit so etwas seit Jahrzehnten. Diese Branche kennt die Antworten in Sachen Sicherheit; das Problem ist, dass das nicht zur aktuellen Haltung passt, mit der AI-Produkte überhastet auf den Markt gebracht werden
  • AI gehört inzwischen ebenfalls zur IT, und dann lautet die Schlussfolgerung eher: „Wir verstehen Sicherheit eben doch nicht.“ Zu sagen, man sei bei AI careless, trifft es nicht. Dass es keine perfekte Trennung zwischen Daten- und Befehlstokens gibt, ist eine grundlegende Grenze, keine Nachlässigkeit. Zu behaupten, „das haben wir alles schon vor Jahrzehnten gelöst“, ist arrogant
  • Aussagen wie „Wir haben Sicherheit schon vor Jahrzehnten gelöst“ tauchen typischerweise auf, wenn eine neue Industrie schlechte alte Standards wiederholt und dabei nur schnell „AI-Produkte“ herausbringen will. Schon Fälle wie der von Beginn an angreifbare MCP-Standard zeigen, dass Ansätze wie „einfach gute Prompts schreiben“ fast lächerlich sind. Das größte Problem ist, dass fast alle in der AI-Industrie MCP-Server ganz selbstverständlich mit direktem Datenbankzugriff entworfen haben. Nur weil etwas möglich ist, heißt das nicht, dass man es auch tun sollte. Die mangelhafte Sicherheit solcher Designs hat bereits zur realen Kompromittierung vieler AI-Produkte geführt
  • Die Behauptung „Wir kennen Sicherheit bereits“ stimmt in der Praxis nicht wirklich. Sobald man auf menschliche Faktoren schaut, erst recht nicht, und selbst milliardenschwere wiederholte Schulungen verlieren mit der Zeit an Wirksamkeit. Erst kürzlich gab es Fälle, in denen sogar hervorragende Sicherheitsexperten auf YouTube auf simples Phishing hereingefallen sind
• Originalbeitrag von @simonw: The lethal trifecta for AI agents, zusätzlich lesenswert ist auch ein weiterer Beitrag dazu. Ich lasse auch den Link zur zugehörigen HN-Diskussion hier
• Die lethal trifecta bezeichnet das Problem, das entsteht, wenn ein LLM gleichzeitig Zugriff auf nicht vertrauenswürdige Daten, Einsicht in sensible Informationen und externe Kommunikation hat. Die Lösung besteht darin, das Risiko durch Grenz- bzw. Rechteverwaltung zu senken; im Grunde Security 101
  • Stimmt, aber in der Praxis entsteht dabei eine starke Spannung zwischen Sicherheit und Funktionalität. Wenn man mit persönlichen Daten nützliche Dinge tun will, öffnet man damit die Tür für Prompt-Injection-Schwachstellen. Und obwohl es für die Effizienz von Agenten hilfreich ist, möglichst viel zusammenhängenden Kontext zu bündeln, sinkt der Nutzen, wenn man Agenten, die untrusted input lesen, vollständig separiert oder isoliert. Siehe zugehöriger Blogpost
  • Streng genommen ist auch das nur grundlegende Access Control. In dem Moment, in dem eine Internetverbindung hinzukommt, steigt das Risiko massiv. Ein hervorragender Sicherheitsforscher könnte mit nur einer einzigen Prompt Injection das gesamte System übernehmen und damit mindestens eine der Bedingungen sofort erfüllen
• LLMs unterscheiden nicht zwischen Prompt und Daten. So etwas wie ein NX bit (No-Execute-Bit) gibt es nicht, und meines Wissens wurde auch nichts wirklich Vergleichbares implementiert. Natürlich würde selbst ein solches Konzept, so wie das NX bit auch Remote Code Execution nicht vollständig verhindert hat, keine perfekte Lösung bieten. Der derzeit realistischste Ansatz ist, den LLM-Agent-Prozess mit bestehenden Sicherheitsmechanismen zu kontrollieren. Man kann ihn etwa unter einem separaten Benutzerkonto ausführen, um Dateizugriffe zu begrenzen, und zusätzliche Einschränkungen über Netzwerk, Hardware und cgroups einziehen. Dennoch bleibt das Risiko bestehen, dass ein LLM bei Anweisungen in untrusted data auch geheime Daten mit hinausgibt. Und wenn ein Nutzer die Ausgabe des LLMs nicht erkennt und nach außen kopiert, entsteht erneut ein Exfiltrationspfad
  • Man sagt zwar, niemand habe etwas Vergleichbares gebaut, aber ich frage mich, ob es überhaupt jemand ernsthaft versucht hat oder ob es dazu relevante Trainingsdaten gibt. Soziale Lebewesen betreiben ganz natürlich compartmentalization. Selbst Hunde verbergen die Existenz von Futter, indem sie auf menschliche Reaktionen achten. Auch ich trenne beim Aufziehen eines Kindes Informationen nach sozialem Kontext, vertraulichem Wissen, den personenbezogenen Daten des Kindes, Informationen, die das Kind noch nicht verarbeiten kann, meinen inneren Gedanken und Inhalten aus nicht vertrauenswürdigen Quellen. Intelligenz ist wichtig, aber Weisheit ist im LLM-Bereich noch kein Thema erster Ordnung. Selbst Welpen und Kleinkinder sind bei der Fähigkeit zur Abgrenzung weiter
• In einem zugehörigen Hintergrundartikel fand ich ein eindrucksvolles Zitat: Das von Google vorgeschlagene System CaMeL verwendet zwei LLMs, um einen Teil der Risiken der lethal trifecta zu vermeiden. Eines greift nur auf untrusted data zu, das andere verarbeitet alles andere. Ein hochvertrauenswürdiges Modell übersetzt die sprachlichen Anweisungen des Nutzers in Code innerhalb eines eng begrenzten Rahmens, und das untrusted Modell füllt die Lücken dieses Codes aus. Diese Architektur liefert Sicherheitsgarantien, schränkt aber den Aufgabenbereich des LLM entsprechend stark ein. Davon höre ich zum ersten Mal und frage mich, wie gut das in der Praxis funktioniert. Garantiert es wirklich „absolute“ Sicherheit, welche Einschränkungen entstehen dabei, und könnte es eine reale Alternative sein? Artikelquelle
  • Ich habe mich lange mit dem CaMeL-Paper beschäftigt. Es ist ein ziemlich guter Ansatz, aber die praktische Umsetzung ist sehr schwierig, und das System kann nur einen stark eingeschränkten Funktionsumfang abdecken. Ich habe das in meiner Analyse zusammengefasst
• Es wird die Analogie bemüht, dass „AI-Ingenieure wie echte Ingenieure in Bereichen denken sollten, in denen Fehler Menschenleben kosten können, etwa beim Brückenbau“. Sinngemäß heißt es: „AI-Ingenieure werden schon in der Ausbildung darauf konditioniert zu glauben, dass mehr Trainingsdaten und klügere Prompts Probleme einfach lösen“
  • Mit „AI-Ingenieure sollten wie echte Ingenieure denken“ ist hier wohl gemeint: nicht einfach wie Softwareingenieure, sondern wie Ingenieure im klassischen Sinn — denn heute steckt Software auch in Brücken und Autos, also sollte man sich zumindest die Denkweise physischer Ingenieurdisziplinen aneignen
  • Es klingt fast so, als würde damit vorgeschlagen, dass man Zertifizierungen für Software Engineering oder sogar ethische Zulassungen bräuchte. Aber solange unethische, aber legale Software extrem hohe Gewinne erzeugt, dürfte so etwas schwer durchsetzbar sein
  • Die Konsequenz aus der Idee „Mit besseren Trainingsdaten lösen wir das“ ist letztlich, dass genau solche tragischen Schäden selbst zu Trainingsdaten werden
  • Man sollte neben Software-„Ingenieuren“ auch die Rolle von „Architekten“ nicht vergessen
• Ich frage mich, ob es nicht eine Geschäftschance wäre, ein Softwareprodukt als Abo-Service gegen eine moderate Gebühr anzubieten, das LLM-Konten automatisch überwacht und Eingaben filtert bzw. per Pipeline verarbeitet