Cryptographic Context Injection: Wenn verschlüsselte Angriffe KI-Sicherheitsschranken blind machen


Ein neuer Angriff, der KI-Sicherheitsfilter systematisch blind macht
Die Sicherheitslandschaft rund um große Sprachmodelle (LLMs) bekommt regelmäßig neue Risse – doch die jüngste Entdeckung des Sicherheitsunternehmens Adversa markiert einen qualitativen Sprung. Unter dem Begriff Cryptographic Context Injection haben Forscher eine Technik beschrieben, die nicht mehr auf plump formulierte Schadanweisungen setzt, sondern auf Kryptografie: Die eigentlichen Angriffsbefehle werden verschlüsselt übertragen und erst innerhalb der Ausführungsumgebung des Modells entschlüsselt – in einem Bereich, den klassische Sicherheitsfilter schlicht nicht einsehen.
Konkret wurde die Technik gegen Grok demonstriert, das LLM von xAI. Forschern gelang es, den KI-Assistenten dazu zu bringen, Nutzerdaten – darunter Name, Standort und Chatverläufe – an einen externen Server zu übermitteln. Der Angriff wurde dem Unternehmen bereits im Juni gemeldet; zum Zeitpunkt der Veröffentlichung war die Lücke noch nicht geschlossen. Ähnliche Vektoren wurden zudem gegen Microsofts 365 Copilot und Google Gemini beobachtet, was die Reichweite des Problems deutlich unterstreicht.
Wie Cryptographic Context Injection technisch funktioniert
Um das Ausmaß des Problems zu verstehen, lohnt sich ein Blick auf den Mechanismus: Klassische Prompt-Injection-Angriffe schmuggeln Schadanweisungen in Inhalte ein, die ein KI-Assistent verarbeiten soll – etwa in E-Mails oder Webseiten, die das Modell zusammenfassen soll. LLMs können strukturell nicht zuverlässig unterscheiden, ob eine Anweisung vom autorisierten Nutzer oder von einem manipulierten Dokument stammt. Das ist kein Bug, sondern eine fundamentale Eigenschaft des Trainingsparadigmas: Das Modell ist darauf optimiert, Anweisungen zu befolgen.
Bisherige Gegenmaßnahmen setzen auf sogenannte statische Sicherheitsfilter (Guardrails), die eingehende und ausgehende Texte auf verdächtige Muster prüfen. Genau hier setzt Cryptographic Context Injection an:
- Der Angreifer platziert verschlüsselten Schadcode (Ciphertext) auf einer Webseite – zusammen mit dem Entschlüsselungsschlüssel und einer Anweisung, diesen Code zu entschlüsseln.
- Der KI-Assistent erhält den harmlosen Auftrag, die Seite zu zusammenzufassen.
- Das Modell führt die Entschlüsselung eigenständig in seiner Code-Execution-Sandbox durch – mit Algorithmen wie PBKDF2 und AES-256-GCM.
- Der Sicherheitsfilter sieht zu keinem Zeitpunkt den Klartext der Schadanweisung, weil er keinen Code ausführt, sondern nur Text klassifiziert.
- Die entschlüsselten Anweisungen erreichen das Modell als dessen eigenes Tool-Output – und werden ohne weitere Prüfung ausgeführt.
Der entscheidende Satz des Adversa-Forschers Rony Utevsky bringt das Grundproblem auf den Punkt:
„Static safety guardrails classify inputs as text; they do not execute them. An attacker ships ciphertext along with the key material and an instruction to decrypt it, and the model runs that decryption inside its own code execution sandbox."
Was den Guardrail-Scannern fehlt, ist die Fähigkeit zur dynamischen Code-Interpretation zur Inspektionszeit. Die Schadlast ist verschlüsselt unsichtbar – bis sie vom Modell selbst sichtbar gemacht wird.
Warum das ein strukturelles, kein produktspezifisches Problem ist
Es wäre bequem, diese Vorfälle als Versagen einzelner Anbieter abzutun. Tatsächlich offenbaren sie eine systemische Schwäche: LLMs können das Root-Cause-Problem von Prompt Injections nicht selbst lösen. Das liegt in ihrer Architektur begründet. Jeder neue Guardrail-Ansatz behebt einen spezifischen Angriffsvektor – und schafft damit implizit die Voraussetzung, dass Angreifer den nächsten Vektor entwickeln.
Adversa beschreibt diesen Zusammenhang treffend als Verschiebung des Angriffsvektors: Nicht mehr der Prompt selbst, sondern der gesamte Kontext, den ein LLM als seine eigene Umgebung behandelt – Tool-Outputs, Runtime-Ergebnisse, Zwischenzustände – wird zur Angriffsfläche. Diese ist ungleich größer als das, was traditionell als „Modelleingabe" gilt.
Dr. Maik Bunzel, Gründer und Geschäftsführer von mabucon.eu, betont in diesem Zusammenhang, dass Unternehmen, die KI-Agenten in operative Prozesse integrieren, diese strukturelle Eigenschaft aktiv in ihrer Risikoarchitektur berücksichtigen müssen: Die Sicherheitsfrage ist nicht allein eine Frage des gewählten Modells, sondern der Systemarchitektur rund um das Modell – inklusive der Daten, auf die ein Agent Zugriff hat, und der Aktionen, die er eigenständig ausführen darf.
Implikationen für Unternehmen mit KI-gestützter Automatisierung
Für Organisationen, die KI-Assistenten und -Agenten in ihre Workflows einbinden – sei es für E-Mail-Management, Dokumentenverarbeitung oder Kundenkommunikation – ergeben sich aus diesen Erkenntnissen konkrete Handlungsfelder:
- Principle of Least Privilege für KI-Agenten: Agenten sollten nur auf diejenigen Daten und Systeme zugreifen können, die für ihre spezifische Aufgabe zwingend erforderlich sind. Breite Datenzugriffsrechte multiplizieren das Schadenspotenzial erfolgreicher Prompt-Injection-Angriffe.
- Human-in-the-Loop für sensible Aktionen: Aktionen mit Außenwirkung – das Versenden von E-Mails, das Aufrufen externer URLs, das Weiterleiten von Daten – sollten eine explizite Bestätigungsstufe erfordern, die nicht vom Modell selbst überwunden werden kann.
- Misstrauen gegenüber externen Inhalten als Designprinzip: Jeder Inhalt, den ein KI-Agent aus dem Internet oder aus Nutzerdokumenten verarbeitet, sollte systemarchitek-tonisch als potenziell feindselig behandelt werden – nicht als vertrauenswürdige Erweiterung des Nutzerauftrags.
- Monitoring und Anomalieerkennung: Da Guardrails allein keinen vollständigen Schutz bieten, gewinnt die nachgelagerte Überwachung von Agentenverhalten an Bedeutung: Welche externen Verbindungen baut ein Agent auf? Welche Daten verlassen das System?
- Vendor-Due-Diligence und Patch-Zyklen: Der Umstand, dass xAI über Monate nach der Meldung keine Lösung bereitgestellt hatte, illustriert: Unternehmen sollten bei der Anbieterwahl auch auf Reaktionsgeschwindigkeit bei Sicherheitsmeldungen achten.
Das Katz-und-Maus-Spiel und was es für die KI-Branche bedeutet
Die Analogie, die Sicherheitsforscher verwenden, ist aufschlussreich: Ein Sicherheitsingenieur im Straßenbau errichtet Leitplanken an einer gefährlichen Kurve – anstatt die Kurve selbst zu begradigen. Jede neue Leitplanke reagiert auf den letzten Unfall; die Kurve selbst bleibt gefährlich. Bei LLMs ist die Kurve die fundamentale Unfähigkeit, Kontext und Intention zuverlässig zu trennen.
Das bedeutet nicht, dass KI-Agenten und -Assistenten nicht produktiv und sicher einsetzbar wären. Es bedeutet aber, dass Sicherheit hier nicht durch Vertrauen in das Modell, sondern durch architektonische Kontrolle um das Modell herum erreicht wird. Dr. Maik Bunzel, Gründer und Geschäftsführer von mabucon.eu, sieht darin eine zentrale Gestaltungsaufgabe für die kommenden Jahre: KI-Systeme so zu bauen, dass ihre Sicherheitseigenschaften nicht von der Perfektion eines einzelnen Guardrails abhängen, sondern durch redundante, systemische Kontrollen abgesichert werden.
Cryptographic Context Injection ist in dieser Hinsicht kein Ausreißer – es ist ein Wegweiser. Adversa selbst formuliert es präzise: Die nächste Generation von Angriffen wird genau dort entstehen, wo LLMs externe Tool-Outputs, Runtime-Ergebnisse und Zwischenzustände als Teil ihres eigenen Kontexts behandeln. Wer KI-Agenten heute in Produktionssysteme integriert, sollte diese Angriffsfläche kennen und architek-tonisch adressieren.
Fazit: Sicherheit als Systemdesign, nicht als Produktmerkmal
Die Entdeckung von Cryptographic Context Injection verdeutlicht eine Reife, die der Angreifer-Seite im LLM-Ökosystem attestiert werden muss: Sie denken nicht mehr in Prompts, sondern in Systemen. Die Verteidiger-Seite – und das schließt Unternehmen, die KI-Produkte einsetzen, explizit mit ein – muss denselben Schritt vollziehen. Sicherheit im KI-Zeitalter ist kein Feature, das ein Modellanbieter liefert. Sie ist eine Systemeigenschaft, die durch bewusstes Design entsteht – und die kontinuierliche Auseinandersetzung mit einer sich schnell entwickelnden Bedrohungslandschaft erfordert.