Cybersicherheit
HiddenLayer-Forscher umgehen OpenAIs Sicherheitsmechanismen und entlarven kritische Schwachstelle in der AI-Selbstmoderation

Am 6. Oktober 2025 kündigte OpenAI AgentKit an, ein Toolkit für den Bau, die Bereitstellung und die Verwaltung von KI-Agents. Eine seiner Komponenten ist Sicherheitsmechanismen, eine modulare Sicherheitsebene, die dafür konzipiert ist, die Eingaben, Ausgaben und Tool-Interaktionen von Agents zu überwachen, um Missbrauch, Datenlecks oder schädliches Verhalten zu verhindern. Sicherheitsmechanismen können personenbezogene Daten maskieren oder markieren, Jailbreaks erkennen und Richtlinienbeschränkungen neben der Agent-Ausführung anwenden.
Während Sicherheitsmechanismen ein neu veröffentlichter Bestandteil von OpenAIs Agent-Architektur sind, zeigt HiddenLayers Forschung eine tiefere Verwundbarkeit auf: Da sowohl die Aktionen des Agents als auch die Sicherheitsprüfungen ähnliche Modelllogik verwenden, können Angreifer Eingaben erstellen, die beide gleichzeitig untergraben – und damit effektiv die Sicherheitsebene von innen heraus brechen.
Was HiddenLayer entdeckte
OpenAIs Design sieht Agents vor, die durch verkettete Logik operieren: Ein Benutzer gibt eine Anfrage ein, der Agent ruft Tools oder externe Ressourcen auf und die Antworten werden von Sicherheitsmechanismen gefiltert oder validiert, bevor sie ausgeführt oder ausgegeben werden. Die Absicht ist, dass der Agent unabhängig von dem, was er tut – sei es Text generieren, eine Webseite abrufen oder eine Funktion auslösen – Sicherheitsmechanismen als Wächter fungiert.
HiddenLayer argumentiert, dass dieser Wächter strukturell fehlerhaft ist, wenn er aus dem gleichen Modelltyp wie das zu schützende Modell aufgebaut ist. In ihren Experimenten erstellten sie Anfragen, die eine Doppelfunktion haben: Sie zwingen das Agent-Modell, Inhalte zu generieren, die gegen die Richtlinie verstoßen, und manipulieren das Sicherheitsmechanismen-Modell, um zu erklären, dass der Inhalt “sicher” ist. Effektiv enthält die Anfrage eine Übersteuerung der internen Logik des Richters – seine Konfidenzschwellen, Entscheidungsverzweigungen – sodass der Richter den schädlichen Ausgang falsch als “sicher” einstuft. Das System produziert dann nicht zugelassene Inhalte, ohne dass eine Warnung ausgelöst wird.
Sie trieben den Angriff weiter, indem sie indirekte Inhaltsinjektionen angriffen, wie z. B. Tool-basierte Abrufaufrufe. Angenommen, der Agent ruft eine Webseite ab, die schädliche Anweisungen oder versteckte Anfragen enthält. Sicherheitsmechanismen sollten dies markieren oder blockieren, aber HiddenLayers Technik integriert eine Übersteuerung des Richters in den abgerufenen Inhalt selbst. Wenn der Richter diesen verarbeitet, sieht er die Übersteuerung und “genehmigt” sie, wodurch der Tool-Aufruf – und jeder schädliche Inhalt, den er zurückgibt – ungeprüft passieren kann.
Die tiefere Lektion ist klar: Wenn Ihr Sicherheitsmechanismus mit der gleichen Logik und den gleichen Verwundbarkeiten wie das zu schützende Modell aufgebaut ist, kann eine einzige clever konstruierte Anfrage beide brechen.
Warum das wichtig ist
Was HiddenLayer aufgedeckt hat, ist kein einfacher Bug – es ist eine warnende Geschichte darüber, wie wir Sicherheit in LLM-Systemen konzipieren. Jede Architektur, die auf dem gleichen Modelltyp für Generierung und Bewertung setzt, riskiert gemeinsame Ausfälle bei adversarialen Eingaben.
Das bedeutet, dass viele Bereitsteller, die dachten, “wir haben Sicherheitsmechanismen implementiert, also sind wir sicher”, das Risiko unterschätzen könnten. In harmlosen, alltäglichen Anwendungsfällen könnten ihre Filter wirksam erscheinen, aber in adversarialen Szenarien könnten sie stillschweigend fehlschlagen. In Bereichen wie Gesundheitswesen, Finanzen, Regierung oder kritischen Systemen könnten solche stillschweigenden Zusammenbrüche zu ernsthaften Schäden führen.
Diese Forschung baut auch auf früheren Prompt-Injektionsmethoden auf. HiddenLayers frühere “Policy Puppetry“-Technik zeigte, wie Angreifer schädliche Anweisungen als Richtlinieninhalte tarnen können. Jetzt demonstrieren sie, dass solche maskierten Angriffe sich auch auf die Sicherheitslogik selbst erstrecken können.
Auswirkungen auf Bereitsteller und Forscher
Im Lichte dieser Verwundbarkeit muss jeder, der agente LLM-Systeme verwendet oder entwickelt, seine Sicherheitsstrategie überdenken.
Erstens: verlassen Sie sich nicht ausschließlich auf interne modellbasierte Prüfungen. Sicherheit muss geschichtet sein. Das bedeutet, Regel-basierte Filter, Anomalie-Erkennungssysteme, Protokollierungssysteme, externe Überwachung, menschliche Aufsicht und Prüfspuren zu kombinieren. Wenn eine Ebene fehlschlägt, können andere den Bruch possibly fangen.
Zweitens: regelmäßige adversarische Red-Teaming ist unverhandelbar. Modelle sollten Anfragen ausgesetzt werden, die versuchen, ihre eigene Wachlogik zu übersteuern – nicht nur “schlechten Inhalt”. Tests müssen sich weiterentwickeln, während Angreifer neue Techniken erfinden.
Drittens: In regulierten oder sicherheitskritischen Bereichen sind Transparenz und Überprüfbarkeit unerlässlich. Bereitsteller benötigen den Beweis, dass ein System adversarialen Angriffen standhalten kann, nicht nur grundlegende Funktionalität. Das legt nahe, dass Drittanbieter-Prüfungen, formale Verifizierung oder Sicherheitsgarantien zu Anforderungen werden können.
Viertens: Für Modell-Ersteller ist das Beheben dieser Klasse von Verwundbarkeiten schwierig. Da sie mit der Art und Weise verbunden ist, wie Modelle Anweisungen parsen und befolgen, garantiert das Filtern einer Klasse von Anfragen nicht die Widerstandsfähigkeit gegen neue. Feinabstimmung oder filterbasierte Verteidigungen können die Modellleistung verschlechtern oder zu Wettrüsten führen. Eine robustere Konstruktion kann architektonische Trennung erfordern – Wachlogik, die in einem anderen Modell oder Subsystem als dem Generierungsmodell läuft.
Einschränkungen und offene Fragen
Um klar zu sein: HiddenLayers Arbeit ist ein Konzeptbeweis, kein endgültiges Urteil über jede Sicherheitsarchitektur. Ihre erfolgreichen Angriffe hängen von tiefem Wissen über die Prompt-Struktur und die interne Bewertungslogik des Wachmodells ab. In eingeschränkteren Anfrageumgebungen oder Systemen, die Verteidigungen randomisieren, kann der Angriff schwieriger zu starten sein.
Außerdem analysieren sie nicht vollständig, wie kohärent oder nützlich die schädlichen Ausgaben sind, wenn sie unter diesen Einschränkungen erstellt werden. Einige Jailbreak- oder Übersteuerungsausgaben können in Qualität oder Zuverlässigkeit abnehmen. Das Risiko ist also real, aber durch Umgebung, Anfragebudget, Schnittstellenbeschränkungen und Wachrandomisierung eingeschränkt.
Schließlich verwenden einige Sicherheitsmechanismen-Entwürfe unterschiedliche Modellklassen, Ensemble-Methoden oder randomisierte Bewertung. Es ist nicht sicher, dass jedes solche System anfällig ist; ob dieser Angriff weit verbreitet ist, ist eine offene Forschungsfrage.
Blick in die Zukunft: Die Zukunft der KI-Sicherheit
Wir scheinen in eine neue Phase einzutreten: Angriffe nicht nur gegen Modelle, sondern gegen ihre Sicherheitsebenen. Techniken wie Kettenübernahme, hierarchische Prompt-Subversion und Richter-Übersteuerung werden die Verteidigungen zwingen, sich schneller zu entwickeln.
Der Weg nach vorne führt wahrscheinlich zu externer Überwachung – Systemen, die Ausgaben von außen überwachen, nicht die Modelllogik teilen oder Sicherheit durch externe Prüfungen durchsetzen. Hybride Architekturen, formale Methoden, Anomalie-Erkennung und menschliche Feedback-Schleifen werden zusammenkommen müssen.
Sicherheitsmechanismen sind ein nützliches Werkzeug, aber HiddenLayers Erkenntnisse erinnern uns daran: Sie können nicht das einzige Werkzeug sein. Sicherheit muss von außerhalb des Systems kommen, nicht nur von innerhalb.
del Logik, oder Sicherheit durch externe Prüfungen durchsetzen. Hybride Architekturen, formale Methoden, Anomalie-Erkennung und menschliche Feedback-Schleifen werden zusammenkommen müssen. Sicherheitsmechanismen sind ein nützliches Werkzeug, aber HiddenLayers Erkenntnisse erinnern uns daran: Sie können nicht das einzige Werkzeug sein. Sicherheit muss von außerhalb des Systems kommen, nicht nur von innerhalb.












