Zum Inhalt springen
Beveiligingsnieuws

Cryptographic Context Injection: KI-Schutz aushebeln

Cryptographic Context Injection

Die Diskussion um KI-Sicherheit bekommt wieder neuen Zündstoff: Forschende von Adversa AI beschreiben eine Angriffstechnik namens Cryptographic Context Injection. Dabei geht es weniger um klassische Jailbreaks per Klartext, sondern um den Trick, dass schädliche Anweisungen erst im inneren Ausführungsumfeld der KI sichtbar werden.

Das Ergebnis: Sicherheits-Guardrails, die Texte vor allem nach Inhalt prüfen, können überlistet werden. In diesem Artikel erklären wir, wie der Ansatz funktioniert, welche Beispiele genannt werden und welche Abwehrmaßnahmen sich daraus ableiten lassen.

Was ist Cryptographic Context Injection?

Die Grundidee von Cryptographic Context Injection lautet: Schutzmechanismen klassifizieren Prompt-Text, ohne ihn tatsächlich auszuführen. Wenn der Angreifer den problematischen Inhalt jedoch in verschlüsselter Form bereitstellt, bleibt er für diese Prüfungen zunächst „unsichtbar“.

In den beschriebenen Szenarien wird ein verschlüsselter Payload samt Anweisung zur Entschlüsselung in das Modell-Umfeld gegeben. Die Entschlüsselung erfolgt dann im Code-Execution-Kontext (Sandbox/Trusted Execution Context). Erst dort wird aus dem Ciphertext die eigentliche, schädliche Prompt-Information als Klartext rekonstruiert.

So entsteht ein gefährlicher Effekt: Der wiederhergestellte Prompt befindet sich im „vertrauenswürdigen“ Kontext, während die Guardrails ihn nicht mehr als schädlich markieren. Die Forschenden warnen ausdrücklich, dass die verschlüsselte Variante dem Angreifer eine zusätzliche „Glaubwürdigkeit“ verleiht, die derselbe Text in Klartext-Form nicht hätte.

Warum funktionieren Guardrails nicht automatisch?

Safety-Mechanismen setzen häufig auf Inhaltsprüfungen: Sie bewerten den Prompt, bevor etwas ausgeführt wird, oder sie überwachen die Ausgabe nach vordefinierten Regeln. Cryptographic Context Injection adressiert genau diese Trennung.

  • Eingabeseite: Der schädliche Inhalt liegt zunächst als Ciphertext vor. Für die Guardrails wirkt das wie „harmloser“ Datenstrom.
  • Ausführungsseite: Die Entschlüsselung und das spätere Verwenden des Klartexts geschieht in einem Code-Kontext, in dem die Sicherheitsprüfung nicht in gleicher Weise „in Echtzeit“ eingreift.
  • Ausgabeseite: In der beschriebenen Logik kann sogar das resultierende Verhalten so gestaltet werden, dass Guardrails auch nachgelagert weniger zuverlässig reagieren.

Damit verschiebt sich die Angriffsfläche: Nicht die reinen Worte sind das Problem, sondern wie und wo der Klartext entsteht und weiterverarbeitet wird.

Angriffsvorbereitung: Direkt oder über „Watering Hole“

Nach den Forschenden lässt sich die verschlüsselte Angriffslogik nicht nur direkt in einem Chat platzieren. Ebenso möglich ist ein indirekter Weg über eine sogenannte Watering-Hole-Strategie.

Im indirekten Szenario wird auf einer Webseite ein verschlüsseltes JSON-Objekt eingebettet. Zusätzlich enthält die Seite eine Anweisung zur Entschlüsselung. Ein nachgelagener Agent—zum Beispiel ein Helfer, der Inhalte einer Seite zusammenfasst oder Daten extrahiert—liest dann den Ciphertext, startet die Entschlüsselung und löst die eigentliche Angriffskette aus.

Damit kann ein Angreifer das Vertrauen in „untrusted external pages“ ausnutzen: Der Agent nimmt Daten aus einer fremden Quelle auf und verarbeitet sie, als wären sie Teil eines legitimen Arbeitsschritts.

Gemini: Beispiele für Safety-Umgehung

Ein Teil der Veröffentlichung konzentriert sich auf Gemini in einer öffentlichen Chat-Umgebung im Deep-Thinking-Modus. Dort beschreiben die Forschenden ein Vorgehen, bei dem ein einzelner Prompt Gemini dazu bringt, einen Python-Decryptor auszuführen und den gelieferten Ciphertext in Klartext zu verwandeln.

Mit dieser Technik soll es gelingen, anschließend Inhalte zu erzeugen, die eigentlich eingeschränkt sind. Die Forschenden erwähnen dazu eine Vorgehensweise, in der das Verbotene „eingepackt“ zurückkommt: Der Inhalt wird so formuliert, dass er als etwas erscheint, das die KI für „Safety“ verschlüsseln oder wieder verpacken würde.

In der Beschreibung wird auch angedeutet, dass die Technik mehrseitige Beispiele für eingeschränkte Inhalte produzieren konnte—etwa Instruktionsmaterial, das Sicherheitsfilter normalerweise unterdrücken würden. Entscheidend ist dabei wieder das Prinzip: Sowohl der schädliche Prompt als auch die potenziell gefährliche Ausgabe sollen über den Verschlüsselungsmechanismus die Eingabe- und Ausgabe-Guardrails umgehen.

Grok: Indirekte Cryptographic Context Injection

Ein weiteres Beispiel zielt auf xAI Grok im Zusammenhang mit einem agentischen Browsing-Framework. Die Forschenden beschreiben hier eine Angriffsklasse, die als Zero-Click Data Exfiltration beschrieben wird. Der Ablauf setzt typischerweise auf Social Engineering: Die Zielperson soll dazu gebracht werden, eine präparierte Webpage anzusehen oder analysieren zu lassen.

Die Webseite enthält wieder ein verschlüsseltes JSON sowie den Auftrag, es mit dem Python-Runtime-Umfeld des Agents zu entschlüsseln. Der entschlüsselte Prompt soll dann dazu führen, dass der Agent auf sein privates Sitzungsumfeld zugreift—also auf Kontextinformationen, die innerhalb der Session verfügbar sind.

Anschließend soll die gestohlene Information in einer URL eingebettet werden. Diese URL wird dann autonom geladen, wodurch die Nutzerdaten an den Angreifer übertragen werden.

Die Forschenden betonen dabei einen besonders heiklen Punkt: Wenn Anweisungen und Daten aus einer untrusted Quelle (der Webseite) die Ausführung privilegierter, internetfähiger Tools steuern, kann der Agent Privilegien nutzen, ohne dass es eine sichtbare Benutzerbestätigung oder eine klare Warnung gibt. Dadurch werden sensible Metadaten oder Verlaufskontexte „in Inputs“ eines ausgehenden Werkzeugs überführt—und der Angreifer kommt an die Daten, obwohl der Benutzer der eigentliche Ausführungsimpuls fehlt.

Einordnung der Offenlegung: Reaktionen und Entwicklung

Die Forschenden berichten, dass sie ihre Ergebnisse am 3. Juni 2026 an xAI gemeldet haben. Außerdem versuchten sie, eine koordinierte Offenlegung an zwei Terminen (4. und 10. August) zu organisieren. Nach eigener Aussage gab es zum Zeitpunkt des Schreibens keine Rückmeldung.

Eine Meldung an Google war laut Bericht nicht möglich, da Jailbreaks außerhalb des Anwendungsbereichs des dortigen Vulnerability Disclosure Programms fallen. Dennoch verweisen die Forschenden darauf, dass die Erfolgsquote des Angriffs gegen Gemini zum August hin zurückgegangen sei.

Ob die Ursache in Filter-Updates, Modelländerungen oder beiden liegt, bleibt unklar. Gleichzeitig halten die Forschenden fest, dass die Technik weiterhin potenziell gefährlich ist—nicht nur aus theoretischer Sicht, sondern als realistische Option für Akteure mit böswilligen Absichten.

Abwehr: Was Defender aus dem Bericht ableiten können

Die Veröffentlichung endet nicht bei der Beschreibung des Angriffs. Laut Bericht enthält der Report auch konkrete Hinweise für Verteidiger. Da die Kernidee auf Entschlüsselung im Ausführungsumfeld und das anschließende Weiterreichen von Klartextanweisungen abzielt, sollten Schutzmaßnahmen genau dort ansetzen.

  • Kontext- und Datenfluss kontrollieren: Prüfen, ob entschlüsselter Inhalt aus untrusted Quellen direkt in „privilegierte“ Schritte (Tools, externe Requests, Datenextraktion) einfließt.
  • Stärkere Trennung von Prüf- und Ausführungsschritten: Wenn die Guardrails nur vor der Ausführung prüfen, braucht es zusätzliche Kontrollen im Verlauf der Ausführung.
  • Werkzeugnutzung einschränken: Besonders kritisch ist, wenn Agenten externe Webseiten auswerten und daraus anschließend internetfähige Tools anstoßen. Begrenzen oder konsequent validieren, was solche Tools dürfen.
  • Transparenz und Warnlogik: Wo immer Daten aus Session-Kontexten extrahiert und in externe Requests eingebettet werden könnten, braucht es klare Detektion und – je nach Produkt – sinnvolle Benutzerinvolvierung.

Die eigentliche Herausforderung besteht darin, dass die Angriffslogik nicht ausschließlich über „böse Wörter“ läuft, sondern über verschlüsselte Zustände und die Rekonstruktion eines „anweisenden“ Prompts im vertrauenswürdigen Umfeld.

Warum das Thema jetzt wichtig bleibt

Cryptographic Context Injection zeigt, dass sich Angriffe gegen KI-Schutzvorkehrungen weiterentwickeln. Sobald Modelle oder Agenten Code ausführen können und dabei Daten aus fremden Quellen verarbeiten, entsteht ein neuer Spielraum.

Auch wenn sich die Erfolgsquote gegen Gemini laut Bericht reduziert hat, bedeutet das nicht, dass der Ansatz „weg“ ist. Vielmehr ist er ein Hinweis darauf, wie dynamisch die Beziehung zwischen Angriffstechniken und Sicherheitsupdates ist.

Für Organisationen, die KI-gestützte Agenten einsetzen—vor allem mit Browser-Funktionalität, Code-Ausführung oder Werkzeugen mit Außenwirkung—ist die wichtigste Lehre: Sicherheit muss entlang des gesamten Datenflusses gedacht werden, nicht nur bei der ersten Textprüfung.

Fazit

Die von Adversa AI beschriebene Technik Cryptographic Context Injection nutzt Verschlüsselung, um schädliche Prompt-Anteile für Guardrails zu tarnen. Erst im Ausführungskontext wird die eigentliche Anweisung entschlüsselt, wodurch Input- und Output-Schutzmechanismen umgangen werden können.

Die Beispiele aus dem Umfeld von Gemini und Grok verdeutlichen zudem, wie schnell daraus Datenabfluss über agentische Workflows entstehen kann. Für Defender gilt: Entscheidend ist die Kontrolle darüber, wie entschlüsselter Klartext in privilegierte Schritte gelangt—und wie konsequent solche Pfade überwacht oder blockiert werden.

Quelle: https://www.securityweek.com/encrypted-prompts-bypass-ai-safety-guardrails-in-grok-and-gemini/