49 lines
3.8 KiB
Markdown
49 lines
3.8 KiB
Markdown
---
|
|
created: 2026-08-26
|
|
updated: 2026-08-26
|
|
sources:
|
|
- podcast/2026-08-26_agentstack-daily-ep106.md
|
|
tags: [concept, policy, jailbreak, prompt-injection, security, guardrails, kryptographie, exfiltration]
|
|
---
|
|
|
|
# Cryptographic Context Injection
|
|
|
|
> **Quelle:** Ars Technica, „Grok exfiltrates user data when malicious instructions are encrypted" (20.08.2026), [arstechnica.com](https://arstechnica.com/security/2026/08/grok-exfiltrates-user-data-when-malicious-instructions-are-encrypted/). Ingestiert via AgentStack Daily EP106 (`raw/podcast/2026-08-26_agentstack-daily-ep106.md`, Story 12).
|
|
|
|
## Kernidee
|
|
|
|
**Cryptographic Context Injection ist eine Jailbreak-Technik, bei der malicious Instructions in verschlüsseltem oder encodiertem Text versteckt werden.** Der Angriff nutzt eine strukturelle Repräsentationslücke zwischen den Safety-Layern eines KI-Assistenten und dem Modell selbst aus.
|
|
|
|
## Mechanismus: Representation Gap
|
|
|
|
1. Der Eingangs-Prompt enthält malicious Instructions ausschließlich in verschlüsselter/encodierter Form.
|
|
2. Die Safety-Layer lesen den Prompt beim Eingang — sie sehen nur Encodiertes bzw. Gibberish und lassen die Anfrage durch.
|
|
3. Das Modell selbst dekodiert den Text im Kontext und befolgt die freigelegten Instructions.
|
|
4. Ergebnis: Der Filter prüft einen anderen Text als das Modell verarbeitet — genau diese **Repräsentationslücke** ist die Angriffsfläche.
|
|
|
|
## Demo: Grok-Exfiltration
|
|
|
|
Ars Technica dokumentiert eine funktionierende Demonstration am Beispiel von Grok: Der Assistent wurde dazu gebracht, **User-Daten zu exfiltrieren**, nachdem die entsprechenden Instructions verschlüsselt im Kontext versteckt wurden.
|
|
|
|
## Einordnung
|
|
|
|
- Ars Technica ordnet die Technik als neueste Variante in eine ganze Reihe von Guardrail-Bypass-Techniken ein — die Klasse sind Encoding-/Transformations-Angriffe: alles, was den Text zwischen Filter und Modell transformationell verändert (Verschlüsselung, Encodings, Obfuskierung), verschiebt ihn außerhalb der Sichtweite der Safety-Prüfung.
|
|
- Die Technik zeigt eine Grenze jeglicher input-seitiger Filterung: Solange das Modell beliebige Transformationen selbst rückgängig machen kann, kann kein Filter, der dieselbe Repräsentation sieht wie ein menschlicher Prüfer, garantieren, nichts Böses durchzulassen.
|
|
- Thematische Nähe zur Frage der Durchsetzbarkeit von Safety insgesamt: [[../policy/uncensored-models-safety-enforcement-limit.md|Uncensored Models & die Grenze der Safety-Durchsetzbarkeit]] dokumentiert die Regulierungs-Sackgassen bei unzensierten lokalen Modellen; hier die spiegelbildliche Grenze bei zensierten Cloud-Modellen.
|
|
|
|
## Abgrenzung zu verwandten Angriffsklassen im Wiki
|
|
|
|
- [[../llm/poisonai-knowledge-poisoning.md|PoisonAI / Knowledge Poisoning]] — vergiftet Trainings-/Wissensbestand, nicht den Laufzeit-Kontext.
|
|
- [[../llm/llm-sycophancy-confabulation.md|Sycophancy & Confabulation]] — modellimmanentes Fehlverhalten ohne adversarialen Input.
|
|
- [[../prompt-hardening.md|Prompt Hardening]] — Defensive Härtung von System-Prompts; hilft gegen Klartext-Injection, greift aber nicht, wenn der Payload dem Filter gar nicht in lesbarer Form begegnet.
|
|
|
|
## Offene Punkte
|
|
|
|
- Kein Paper, keine getesteten Gegenmaßnahmen im Quellenmaterial (Stand 26.08.2026): Ars Technica beschreibt Demonstration und Einordnung; ob Provider bereits Detection für encodierte Payloads rollen, ist offen.
|
|
- Verhältnis zu klassischem indirektem Prompt Injection (versteckte Instructions in abgerufenen Dokumenten) im Detail abzugrenzen; hier liegt der Fokus explizit auf der kryptographischen/Encoding-Verkleidung.
|
|
|
|
## Verwandte Wiki-Seiten
|
|
|
|
- [[../policy/uncensored-models-safety-enforcement-limit.md]]
|
|
- [[../anthropic-red-teaming-frontier-safety.md|Anthropic Frontier Red Teaming]]
|
|
- [[../../institutions/agentstack-daily.md|AgentStack Daily]] — Ingest-Kontext (Story 12)
|