Historii chatu lze podvrhnout: AI agent pak útočí sám

Darktrace v oznámení ze 24. září 2026 z britské Cambridge představila Signal Labs a první laboratorní zjištění o podvržené historii konverzace programátorských AI agentů; její ředitel pro AI Tim Bazalgette řekl: „Permissions and static guardrails describe intent, but they don't describe behavior.“ Upravený záznam předchozí relace může agenta přesvědčit, že už dostal souhlas k bezpečnostnímu testu, a ten pak může použít své skutečné nástroje k útoku v testovaném prostředí.

Útočník k tomu potřebuje možnost změnit lokálně uloženou relaci, kterou agent při pokračování práce načte. Rozbor Hexon popisuje, jak se falešná schválení a údajné dřívější kroky mohou v takové relaci změnit ve zdánlivě věrohodné zadání. Zveřejněné výsledky pocházejí z kontrolovaného výzkumu, nikoli z doloženého průniku do zákaznického prostředí výrobců dotčených nástrojů.

Jak se podvržený záznam změní v pokyn

Programátorský agent při obnovení práce nedostává jen nový požadavek. Jeho prostředí sestaví kontext také ze starších zpráv uživatele a asistenta, volání nástrojů a jejich výsledků. Pokud lze uložený záznam přepsat, může útočník vytvořit souvislou minulost, v níž uživatel údajně vymezil cíle bezpečnostního testu a agent s nimi souhlasil. Nový příkaz pak vypadá jako pokračování rozpracované úlohy.

Rozhodující okamžik nastává při načtení relace: text o někdejším souhlasu dostane v kontextu podobnou váhu jako skutečný průběh práce. Agent může z takového záznamu odvodit, že síťový průzkum či práce s přihlašovacími údaji patří do povoleného rozsahu. Kontrola právě zadávaného promptu tuto cestu nezachytí, protože škodlivé tvrzení už čeká v historii, kterou prostředí k promptu připojí.

Samotná podvržená zpráva agentovi žádné nové systémové oprávnění nepřidělí. Dopad závisí na tom, co už jeho nástroje smějí dělat: spouštět příkazy, číst soubory, připojovat se k síti nebo používat dostupné účty. Právě spojení falešné minulosti s těmito pravomocemi mění chybný závěr modelu v reálnou akci.

Co se podařilo u Claude Code, Codexu, Kiro-CLI a Pi

Technický rozbor Erica Rozona uvádí, že zkoumané verze Anthropic Claude Code, OpenAI Codex, AWS Kiro-CLI a open source Pi neověřovaly, zda uložené odpovědi asistenta skutečně vytvořil model. Jednoduchá ukázka u Kiro-CLI změnila jedinou odpověď v lokální databázi SQLite. V dalším pokusu výzkumníci vložili 78 smyšlených tahů předchozí konverzace; požadavek, který agent původně odmítl, po načtení upravené historie vykonal.

Výsledek útočných úloh závisel na spojení agentního prostředí a modelu. Kiro-CLI s kombinací Claude Opus 4.6 a Claude Sonnet 4.5 v izolované laboratorní síti dospěl k ovládnutí celé domény Active Directory. Ve stejném testovacím prostředí toho dosáhl také Claude Code se Sonnet 5. Při pokusu s Opus 5 v Claude Code naopak ochranné mechanismy zabránily odpovědi.

U Codexu výzkumníci popsali odeslání citlivých informací e-mailem při použití GPT 5.6 Sol. Pokusy přimět Codex k průniku do laboratorní sítě s variantami GPT 5.6 Luna, Terra a Sol zastavily ochranné mechanismy. Přijetí podvržené historie tedy ještě neurčovalo výsledek každého následného požadavku: model mohl jednu akci vykonat a jinou odmítnout.

Tyto rozdíly jsou podstatné pro čtení výsledků. Popsané ovládnutí domény je výsledkem konkrétní kombinace prostředí, modelu a laboratorní sítě, nikoli vlastností samotného nástroje při každém spuštění. Společným problémem zkoumaných prostředí bylo to, že předchozí odpovědi asistenta mohly vstoupit do nového kontextu bez ověření jejich původu.

Řetězec může začít instalací balíčku

Výzkum popisuje také možnou cestu, jak by se útočník k historii dostal. Vývojář by nainstaloval škodlivý softwarový balíček, například podvržený server MCP; jeho kód by změnil lokální záznam relace a přidal příběh o již povoleném bezpečnostním testu. Součástí balíčku by mohl být proces, který agentovi po obnovení relace zadává další úkoly přes běžně nainstalované agentní prostředí.

Tento řetězec je scénářem možného zneužití, zatímco vykonání útočných úloh výzkumníci předvedli v sandboxu. V obou případech je důležitá stejná hranice: proces schopný zapisovat do historie může ovlivnit rozhodování agenta, který má širší přístup k nástrojům. Počáteční přístup k souboru relace a pravomoci agenta proto určují, jak daleko by se takový útok mohl dostat.

Obrana musí rozdělit paměť, souhlas a výkon

Pro provozovatele agentů z výsledků plyne několik oddělených kontrol. Zabezpečení aktuálního zadání řeší jen jednu cestu do kontextu; uložená relace, ověření souhlasu a samotné volání nástroje mají vlastní hranice důvěry.

• Uložená historie: omezit účty a procesy, které mohou měnit soubory relací. Změny zaznamenávat tak, aby je agent ani běžný projektový skript nemohl zpětně přepsat.
• Původ zpráv: při obnovení relace ověřovat autora, pořadí a integritu záznamů včetně odpovědí připisovaných modelu. Tvrzení o dřívějším souhlasu v přepisu samo souhlas neprokazuje.
• Oprávnění nástrojů: zpřístupnit shell, síť, soubory a přihlašovací údaje jen v rozsahu konkrétní úlohy. Rozhodnutí o povolení akce má vycházet z pravidel mimo text konverzace.
• Schválení a audit: u citlivé nebo nevratné akce ověřit aktuální souhlas pro konkrétní cíl. Audit má spojit načtenou relaci s požadavkem na nástroj, rozhodnutím o povolení a skutečným výsledkem.

Kryptografické podepisování odpovědí modelu a jejich následné ověřování by umožnilo zjistit, zda zprávu připisovanou modelu někdo změnil; zavedení takové ochrany závisí na poskytovatelích agentních prostředí a modelových služeb. Provozovatel může mezitím omezit zápis do relací i dosah nástrojů. Pokud audit ukáže citlivý příkaz opřený o údajné starší schválení, rozhodující bude záznam o tom, kdo souhlas skutečně udělil mimo uložený chat.