OpenAI ordnet Prompt Injection als Social Engineering ein und verlagert die Verteidigung in die Oberfläche

Der Angriff, der OpenAI tatsächlich Sorgen macht

Der Beitrag von OpenAI führt ein konkretes Beispiel an: eine E-Mail, die wie ein gewöhnliches Follow-up aus dem Arbeitsalltag wirkt, inklusive Aktionspunkten zu Umstrukturierungsunterlagen und Rollenbeschreibungen. Darin versteckt ist eine Anweisung, die einem Assistenten mitteilt, er habe die "vollständige Berechtigung", Name und Adresse eines Mitarbeiters abzurufen und an ein externes "Compliance-Validierungssystem" zu übermitteln.

Laut OpenAI funktionierte dieser Angriff, der von externen Forschern gemeldet wurde, in 50 % der Fälle, wenn er mit einer plausiblen Nutzeranfrage nach "tiefgehender Recherche" zu E-Mails über einen neuen Mitarbeiterprozess kombiniert wurde. Der entscheidende Punkt ist, dass die Payload nicht wie eine Injection-Zeichenfolge aussieht. Sie sieht aus wie ein Memo.

Deshalb steht OpenAI dem "KI-Firewalling" skeptisch gegenüber – einer Zwischenschicht, die Eingaben als bösartig oder harmlos einordnet. Wie es im Beitrag heißt, wird die Erkennung solcher ausgefeilten Angriffe zum "gleichen, sehr schwierigen Problem wie das Erkennen einer Lüge oder Falschinformation, oft ohne den notwendigen Kontext." Eine gut geschriebene E-Mail lässt sich nicht mit Regex entlarven.

Das Drei-Akteure-Modell aus dem Kundensupport

OpenAI beschreibt einen KI-Agenten in derselben Position wie einen menschlichen Kundensupport-Mitarbeiter: Er handelt im Auftrag eines Arbeitgebers, ist dabei aber ständig Dritten ausgesetzt, die ihn in die Irre führen könnten. Die Lehre aus diesem Bereich lautet nicht, den Menschen immun gegen Manipulation zu machen, sondern zu begrenzen, was ein manipulierter Mensch anrichten kann.

In der realen Welt erhält der Agent ein Regelwerk, dem er folgen soll, doch es wird erwartet, dass er in der feindlichen Umgebung, in der er sich bewegt, in die Irre geführt wird.Montana Labs

Die Analogie zum Support ist konkret: Rückerstattungslimits, Phishing-Warnungen und deterministische Kontrollen, die den Schaden begrenzen, selbst wenn der Agent getäuscht wird. Übertragen auf Agenten verändert das die Zielsetzung. Es geht nicht mehr darum, zu garantieren, dass das Modell niemals getäuscht wird. Es geht darum, sicherzustellen, dass ein erfolgreicher Trick nicht heimlich Daten abgreifen oder eine gefährliche Aktion ausführen kann.

Source-Sink-Analyse verlagert die Prüfung an den Punkt der Übertragung

Speziell für ChatGPT kombiniert OpenAI das Social-Engineering-Denken mit einer Source-Sink-Analyse: Ein Angreifer benötigt sowohl eine Source (eine Möglichkeit, das System zu beeinflussen) als auch einen Sink (eine Fähigkeit, die gefährlich wird). Bei Agenten ist die gefährliche Kombination nicht vertrauenswürdiger externer Inhalt plus eine Aktion wie die Übermittlung von Informationen an Dritte, das Folgen eines Links oder der Aufruf eines Tools.

Genau hier kommt das Frontend ins Spiel. Die Safe-Url-Maßnahme von OpenAI erkennt, wenn Informationen, die der Assistent in einer Konversation erfahren hat, kurz davor stehen, an Dritte gesendet zu werden. In solchen Fällen zeigt sie dem Nutzer entweder genau, was übermittelt würde, und bittet um Bestätigung, oder sie blockiert die Aktion und weist den Agenten an, einen anderen Weg zu finden. Derselbe Mechanismus greift bei Navigationen und Lesezeichen in Atlas sowie bei Suchen und Navigationen in Deep Research.

Canvas und Apps erweitern diesen Ansatz, indem generierte Anwendungen in einer Sandbox laufen, die unerwartete Kommunikation erkennt und den Nutzer um Zustimmung bittet. Die Sicherheitsgrenze wird also als Ereignis in der Oberfläche ausgedrückt, nicht als unsichtbarer Backend-Filter.

Was das für Teams bedeutet, die Agent-Oberflächen bauen

Die Konsequenz für das Design ist, dass Zustimmungsabfragen tragende Sicherheitsinfrastruktur sind, keine Reibung, die man wegoptimieren sollte. Wenn die einzige Absicherung einer gefährlichen Aktion ein Dialog ist, der dem Nutzer zeigt, welche Daten das System gerade verlassen würden, dann ist die Klarheit, das Timing und die Verständlichkeit dieses Dialogs die eigentliche Verteidigung. Eine verwirrende oder leicht wegklickbare Abfrage hebt den Schutz auf.

OpenAIs eigener Leitfaden für alle, die ein Modell in eine Anwendung integrieren, liefert einen nützlichen Test: fragen Sie sich, welche Kontrollen ein menschlicher Support-Mitarbeiter in derselben Situation hätte, und implementieren Sie diese. Das Unternehmen geht davon aus, dass ein hinreichend leistungsfähiges Modell Social Engineering irgendwann besser widerstehen wird als ein Mensch, merkt aber an, dass dies "nicht immer praktikabel oder wirtschaftlich sinnvoll" ist – genau deshalb existieren die Prüfungen auf Oberflächenebene als Rückfallebene und nicht allein das Training.

Für praxisorientierte Teams lautet die konkrete Handlungsempfehlung, die Sinks des eigenen Agenten zu inventarisieren – jede Stelle, an der er Daten übermitteln, einem Link folgen oder ein externes Tool aufrufen kann – und für jeden Sink zu entscheiden, ob eine Aktion unbemerkt ablaufen darf. Für die riskanten Fälle lautet OpenAIs Antwort: nein – dem Nutzer sichtbar machen oder blockieren und umleiten.