Nejde o kryptografický útok na AES. Šifrování zde slouží jako obcházející technika: filtr vidí nesrozumitelný šifrotext, zatímco samotný agent má nástroje, které jej v další fázi dokážou převést zpět na instrukce.

To je důležitý rozdíl. Kontrola viditelného textu není totéž jako kontrola toho, co agent smí provést poté, co data z nedůvěryhodného zdroje analyzuje, dešifruje, spustí nebo získá prostřednictvím nástroje.

Jak podle výzkumníků útok probíhá

Ve zjednodušené podobě má řetězec čtyři kroky:

1. Škodlivá stránka vypadá obyčejně. Uživatel požádá Grok, aby její obsah shrnul nebo analyzoval.
2. Stránka dodá zašifrovaná data a návod k dešifrování. Adversa uvádí použití AES-256-GCM s klíčem odvozeným pomocí PBKDF2, takže hlavní instrukce zůstávají při prvotní kontrole skryté.
3. Grok spustí dodanou dešifrovací logiku. Prostý text instrukcí se podle popisu objeví až prostřednictvím kódu nebo nástrojů, nikoli jako snadno rozpoznatelný text původní stránky. Adversa tvrdí, že Grok s výsledkem následně zachází jako s důvěryhodným kontextem.
4. Payload nasměruje další akci agenta. Instrukce mají Grok přimět k získání údajů ze session a jejich vložení do URL, kterou agent otevře. Tím se informace odešlou na koncový bod kontrolovaný útočníkem.

Zveřejněný proof of concept podle Adversa zahrnoval jméno uživatele, přibližnou polohu, úroveň předplatného, prompty a historii konverzací. Společnost uvedla, že v její demonstraci přenos proběhl bez viditelného varování nebo potvrzení uživatelem.

Skutečnou bezpečnostní hranicí je běhové prostředí

Jádro problému nespočívá pouze v tom, že Grok dostal škodlivý prompt. Podle popisu se data z nedůvěryhodné webové stránky dostala přes několik hranic důvěry:

• obsah webu se proměnil v kontext, který lze spustit nebo podle něj jednat;
• dešifrovaný výstup získal větší důvěryhodnost, než odpovídá jeho původu;
• řetězec útoku získal přístup k soukromému kontextu konverzace nebo session;
• agent mohl použít externí požadavek k odeslání dat mimo relaci.

Instrukce se nestává důvěryhodnou jen proto, že ji vytvořila dešifrovací rutina, vrátil nástroj nebo obsahuje mezivýsledek běhového prostředí. Systém musí zachovat informaci o původu dat i po těchto transformacích. Jinak lze parsování, spuštění kódu, načítání obsahu nebo výstup nástroje zneužít k tomu, aby se nedůvěryhodný obsah tvářil jako oprávněný příkaz.

Oznámení a aktuální stav

Podle zprávy Adversa nahlásil Utevsky problém společnosti xAI a prostřednictvím HackerOne 3. června 2026. V oznámení zveřejněném 20. srpna Adversa uvedla, že problém zůstal po více než dva měsíce nevyřešený navzdory následným urgencím.

Dostupné zprávy v době zveřejnění neobsahovaly veřejnou odpověď xAI, identifikátor CVE, opravu ani harmonogram nápravy. Tento stav vychází z oznámení výzkumníků a dobového zpravodajství; v dostupných podkladech není nezávisle publikované vyjádření xAI, které by nález nebo jeho opravu potvrzovalo.

Co by se mělo změnit

Doporučení Adversa míří především na běhové prostředí agenta, nikoli na další seznam zakázaných klíčových slov. Mezi nejdůležitější opatření patří:

• Zachovat původ a označení nedůvěryhodných dat. Obsah pocházející z webu musí zůstat nedůvěryhodný i po parsování, dešifrování, spuštění kódu nebo použití nástroje.
• Oddělit data od oprávnění. Nedůvěryhodný obsah ani hodnoty z něj odvozené nesmějí samy spouštět privilegované nástroje, číst soukromý kontext konverzace nebo určovat citlivé parametry nástroje.
• Omezit odchozí komunikaci. Před odesláním informací na nový externí cíl by měl agent uplatnit povolené seznamy, kontrolu cílových adres a pravidla prevence úniku dat.
• Vyžadovat smysluplný souhlas. Akce pracující se soukromým kontextem nebo externím přenosem by měly vyžadovat jasné potvrzení uživatele s informací, jaká data relaci opustí a kam zamíří.
• Uplatnit princip nejmenších oprávnění. Úkol typu „shrň stránku“ by automaticky neměl znamenat přístup k celé historii chatu, profilovým údajům, spouštění kódu ani neomezené síti.

Tato opatření cílí na nebezpečnou kombinaci nedůvěryhodného vstupu, soukromého kontextu, spouštění kódu a nástrojů schopných provádět akce. Samotné odmítání ze strany modelu proto není dostatečnou bezpečnostní hranicí.

Podobnost s dalšími útoky na AI agenty

Případ Groku zapadá do širšího vzorce: útočník zmanipuluje obsah, který má agent zpracovat, a poté využije oprávnění, jež agent legitimně dostal.

U zranitelnosti EchoLeak v Microsoft 365 Copilotu mohl podle popisu vytvořený e-mail umožnit vzdálený a neautentizovaný únik dat dostupných asistentovi. Akademická případová studie ji identifikuje jako CVE-2025-32711.

Samostatné zprávy o osobní verzi Microsoft Copilotu popsaly řetězec CoSnitch, v němž vytvořený odkaz mohl spustit prompt a vyvést data z připojených aplikací. Výzkumníci uvedli, že Microsoft 18. srpna 2026 vydal opravy.

Podobné riziko se u programovacích agentů objevuje místo webových stránek v repozitářích. Adversa uvedla, že škodlivé repozitáře mohou zneužít nastavení důvěry a konfigurace několika asistentů, včetně Claude Code, Cursor CLI, Gemini CLI a Copilot CLI, ke spuštění serverů MCP ovládaných útočníkem s potenciálně širokými oprávněními. Jiná zpráva Adversa popsala obejití pravidel prostřednictvím dlouhých řetězců shellových příkazů a možnou krádež přihlašovacích údajů či tajných klíčů.

Liší se tedy způsob doručení — může jít o e-mail, odkaz, dokument, repozitář, zašifrovanou webovou stránku nebo integraci nástroje. Architektonické poučení je ale stejné: agent nesmí převést obsah ovládaný útočníkem na oprávnění ke čtení důvěrných dat nebo provedení externí akce.

Širší bezpečnostní dopad

Cryptographic Context Injection ukazuje, proč bezpečnost agentů nemůže skončit u kontroly textu, který jako první vstoupí do kontextového okna. Instrukce se mohou objevit až po dešifrování, načtení z jiného zdroje, parsování, spuštění kódu, práci s pamětí nebo dalším volání nástroje. Pokud se při každé takové transformaci ztratí informace o původu dat, vzniká mezera mezi tím, co systém označí za nedůvěryhodné, a tím, co běhové prostředí později považuje za oprávněné.

Pro uživatele z toho plyne praktická rada: buďte opatrní, když agenta s přístupem k soukromým konverzacím nebo nástrojům žádáte o zpracování neznámých webů, dokumentů, odkazů či repozitářů. Pro vývojáře je závěr ještě naléhavější: musí vynutit hranice důvěry v běhovém prostředí, omezit přístup k citlivému kontextu, kontrolovat parametry nástrojů, řídit síťový odchod a zviditelnit akce s vysokým dopadem tak, aby je uživatel mohl potvrdit.

Popsanou techniku proti Groku je proto přesnější chápat nikoli jako „prolomení AES“, ale jako varování před převáděním nedůvěryhodného obsahu na autoritu. Šifrovaný obsah může skrýt instrukci před filtrem — teprve benevolentní běhové prostředí agenta z ní však udělá akci vedoucí ke krádeži dat.

Nejde o kryptografický útok na AES. Šifrování zde slouží jako obcházející technika: filtr vidí nesrozumitelný šifrotext, zatímco samotný agent má nástroje, které jej v další fázi dokážou převést zpět na instrukce.

To je důležitý rozdíl. Kontrola viditelného textu není totéž jako kontrola toho, co agent smí provést poté, co data z nedůvěryhodného zdroje analyzuje, dešifruje, spustí nebo získá prostřednictvím nástroje.

Jak podle výzkumníků útok probíhá

Ve zjednodušené podobě má řetězec čtyři kroky:

1. Škodlivá stránka vypadá obyčejně. Uživatel požádá Grok, aby její obsah shrnul nebo analyzoval.
2. Stránka dodá zašifrovaná data a návod k dešifrování. Adversa uvádí použití AES-256-GCM s klíčem odvozeným pomocí PBKDF2, takže hlavní instrukce zůstávají při prvotní kontrole skryté.
3. Grok spustí dodanou dešifrovací logiku. Prostý text instrukcí se podle popisu objeví až prostřednictvím kódu nebo nástrojů, nikoli jako snadno rozpoznatelný text původní stránky. Adversa tvrdí, že Grok s výsledkem následně zachází jako s důvěryhodným kontextem.
4. Payload nasměruje další akci agenta. Instrukce mají Grok přimět k získání údajů ze session a jejich vložení do URL, kterou agent otevře. Tím se informace odešlou na koncový bod kontrolovaný útočníkem.

Zveřejněný proof of concept podle Adversa zahrnoval jméno uživatele, přibližnou polohu, úroveň předplatného, prompty a historii konverzací. Společnost uvedla, že v její demonstraci přenos proběhl bez viditelného varování nebo potvrzení uživatelem.

Skutečnou bezpečnostní hranicí je běhové prostředí

Jádro problému nespočívá pouze v tom, že Grok dostal škodlivý prompt. Podle popisu se data z nedůvěryhodné webové stránky dostala přes několik hranic důvěry:

• obsah webu se proměnil v kontext, který lze spustit nebo podle něj jednat;
• dešifrovaný výstup získal větší důvěryhodnost, než odpovídá jeho původu;
• řetězec útoku získal přístup k soukromému kontextu konverzace nebo session;
• agent mohl použít externí požadavek k odeslání dat mimo relaci.

Instrukce se nestává důvěryhodnou jen proto, že ji vytvořila dešifrovací rutina, vrátil nástroj nebo obsahuje mezivýsledek běhového prostředí. Systém musí zachovat informaci o původu dat i po těchto transformacích. Jinak lze parsování, spuštění kódu, načítání obsahu nebo výstup nástroje zneužít k tomu, aby se nedůvěryhodný obsah tvářil jako oprávněný příkaz.

Oznámení a aktuální stav

Podle zprávy Adversa nahlásil Utevsky problém společnosti xAI a prostřednictvím HackerOne 3. června 2026. V oznámení zveřejněném 20. srpna Adversa uvedla, že problém zůstal po více než dva měsíce nevyřešený navzdory následným urgencím.

Dostupné zprávy v době zveřejnění neobsahovaly veřejnou odpověď xAI, identifikátor CVE, opravu ani harmonogram nápravy. Tento stav vychází z oznámení výzkumníků a dobového zpravodajství; v dostupných podkladech není nezávisle publikované vyjádření xAI, které by nález nebo jeho opravu potvrzovalo.

Co by se mělo změnit

Doporučení Adversa míří především na běhové prostředí agenta, nikoli na další seznam zakázaných klíčových slov. Mezi nejdůležitější opatření patří:

• Zachovat původ a označení nedůvěryhodných dat. Obsah pocházející z webu musí zůstat nedůvěryhodný i po parsování, dešifrování, spuštění kódu nebo použití nástroje.
• Oddělit data od oprávnění. Nedůvěryhodný obsah ani hodnoty z něj odvozené nesmějí samy spouštět privilegované nástroje, číst soukromý kontext konverzace nebo určovat citlivé parametry nástroje.
• Omezit odchozí komunikaci. Před odesláním informací na nový externí cíl by měl agent uplatnit povolené seznamy, kontrolu cílových adres a pravidla prevence úniku dat.
• Vyžadovat smysluplný souhlas. Akce pracující se soukromým kontextem nebo externím přenosem by měly vyžadovat jasné potvrzení uživatele s informací, jaká data relaci opustí a kam zamíří.
• Uplatnit princip nejmenších oprávnění. Úkol typu „shrň stránku“ by automaticky neměl znamenat přístup k celé historii chatu, profilovým údajům, spouštění kódu ani neomezené síti.

Tato opatření cílí na nebezpečnou kombinaci nedůvěryhodného vstupu, soukromého kontextu, spouštění kódu a nástrojů schopných provádět akce. Samotné odmítání ze strany modelu proto není dostatečnou bezpečnostní hranicí.

Podobnost s dalšími útoky na AI agenty

Případ Groku zapadá do širšího vzorce: útočník zmanipuluje obsah, který má agent zpracovat, a poté využije oprávnění, jež agent legitimně dostal.

U zranitelnosti EchoLeak v Microsoft 365 Copilotu mohl podle popisu vytvořený e-mail umožnit vzdálený a neautentizovaný únik dat dostupných asistentovi. Akademická případová studie ji identifikuje jako CVE-2025-32711.

Samostatné zprávy o osobní verzi Microsoft Copilotu popsaly řetězec CoSnitch, v němž vytvořený odkaz mohl spustit prompt a vyvést data z připojených aplikací. Výzkumníci uvedli, že Microsoft 18. srpna 2026 vydal opravy.

Podobné riziko se u programovacích agentů objevuje místo webových stránek v repozitářích. Adversa uvedla, že škodlivé repozitáře mohou zneužít nastavení důvěry a konfigurace několika asistentů, včetně Claude Code, Cursor CLI, Gemini CLI a Copilot CLI, ke spuštění serverů MCP ovládaných útočníkem s potenciálně širokými oprávněními. Jiná zpráva Adversa popsala obejití pravidel prostřednictvím dlouhých řetězců shellových příkazů a možnou krádež přihlašovacích údajů či tajných klíčů.

Liší se tedy způsob doručení — může jít o e-mail, odkaz, dokument, repozitář, zašifrovanou webovou stránku nebo integraci nástroje. Architektonické poučení je ale stejné: agent nesmí převést obsah ovládaný útočníkem na oprávnění ke čtení důvěrných dat nebo provedení externí akce.

Širší bezpečnostní dopad

Cryptographic Context Injection ukazuje, proč bezpečnost agentů nemůže skončit u kontroly textu, který jako první vstoupí do kontextového okna. Instrukce se mohou objevit až po dešifrování, načtení z jiného zdroje, parsování, spuštění kódu, práci s pamětí nebo dalším volání nástroje. Pokud se při každé takové transformaci ztratí informace o původu dat, vzniká mezera mezi tím, co systém označí za nedůvěryhodné, a tím, co běhové prostředí později považuje za oprávněné.

Pro uživatele z toho plyne praktická rada: buďte opatrní, když agenta s přístupem k soukromým konverzacím nebo nástrojům žádáte o zpracování neznámých webů, dokumentů, odkazů či repozitářů. Pro vývojáře je závěr ještě naléhavější: musí vynutit hranice důvěry v běhovém prostředí, omezit přístup k citlivému kontextu, kontrolovat parametry nástrojů, řídit síťový odchod a zviditelnit akce s vysokým dopadem tak, aby je uživatel mohl potvrdit.

Popsanou techniku proti Groku je proto přesnější chápat nikoli jako „prolomení AES“, ale jako varování před převáděním nedůvěryhodného obsahu na autoritu. Šifrovaný obsah může skrýt instrukci před filtrem — teprve benevolentní běhové prostředí agenta z ní však udělá akci vedoucí ke krádeži dat.