Docker posílá AI agenty do cloudu, tajné klíče jim ale neukáže

Docker podle svého oznámení 24. září 2026 zpřístupnil Cloud Sandboxes pro kódovací AI agenty na spravované infrastruktuře; cloudová relace může trvat nejvýše 24 hodin. Prostředí používá izolaci pomocí microVM stejně jako místní Docker Sandboxes a práci z notebooku lze předat do cloudu příkazem sbx move. Proxy při odchozím požadavku doplní spravovaný přístupový údaj, takže agent nemusí vidět jeho hodnotu.

Podle reportáže Tom’s Hardware Docker na konferenci WeAreDevelopers předvedl, jak se agent Claude v běžném kontejneru dostal k tajnému údaji přes připojený socket hostitelského Dockeru, zatímco v sandboxu stejný postup selhal; prezident firmy Mark Cavage rozdíl shrnul slovy „Dobbiamo separare i container dal contenimento“. Ukázka se týkala konkrétní konfigurace se zpřístupněným socketem, nikoli každého běžného kontejneru. Právě tento detail rozhoduje o tom, co demonstrace vypovídá o ochraně hostitele.

MicroVM chrání hostitele před cestou přes Docker socket

Kontejner využívá jádro hostitelského systému. Sandbox s microVM má vlastní jádro i vlastní Docker daemon, takže příkazy agenta běží za další hranicí vůči stroji, na němž je prostředí spuštěno. Kódovací agent přitom může instalovat balíčky, spouštět testy a volit další příkazy bez jednotlivého potvrzení vývojáře. U takové úlohy záleží na tom, zda přístup k Docker daemonu vede jen do sandboxu, nebo také k hostiteli.

V předvedené konfiguraci měl kontejner připojený socket hostitelského Dockeru. Takové připojení dává procesu uvnitř kontejneru cestu k daemonu, který spravuje prostředky mimo něj; v demonstraci ji agent využil k získání údaje mimo původní kontejner. Samotná izolace procesu v kontejneru tuto výslovně otevřenou cestu neuzavře. V sandboxu se stejný pokus o přístup k hostitelskému socketu nezdařil.

Hranice microVM se týká hlavně přístupu k hostiteli a k dalšímu prostředí mimo sandbox. Agent však dál pracuje se zdrojovým kódem a se službami, které mu byly povoleny. Má-li přímo v pracovních souborech citlivý údaj nebo může volat nástroj s rozsáhlými právy, izolace stroje neurčí, jak tyto prostředky použije. Bezpečnostní účinek proto závisí také na obsahu sandboxu a oprávněních dostupných zevnitř.

Přesun zachová soubory, nikoli rozběhnutou úlohu

Podle technického srovnání Dockeru příkaz sbx move pořídí kopii souborového systému a vytvoří samostatný cílový sandbox; nepřenáší paměť ani běžící procesy a původní prostředí ponechá na místě. Přesun tedy není nepřerušené pokračování stejného procesu na jiném stroji. Agent může navázat na uložené soubory, ale rozpracovaná operace závislá pouze na stavu v paměti se musí znovu spustit nebo obnovit ze záznamu.

Rozdíl je vidět také na zdrojovém kódu. Místní sandbox může používat složku připojenou z notebooku nebo soukromý klon navázaný na hostitelský repozitář. Cloudový sandbox k cestám na notebooku přístup nemá; potřebné soubory musí být v přenášeném souborovém systému, samostatně zkopírované nebo znovu získané z repozitáře. Pokud byl kód dostupný pouze prostřednictvím připojené hostitelské složky, samotný přesun jeho obsah do cloudu nepřinese.

Oddělené zůstávají i úložiště spravovaných klíčů, svazky a síťové zásady místního a cloudového prostředí. Přenesený sandbox používá příslušné cloudové údaje a pravidla, nikoli automatickou kopii těch lokálních. Opačný případ představuje token zapsaný do souboru uvnitř sandboxu: s kopírovaným souborovým systémem se může dostat do cíle. Právě rozdíl mezi spravovaným klíčem a klíčem uloženým v souboru určuje, co při přesunu skutečně putuje do cloudu.

Skrytá hodnota klíče neomezuje všechny jeho možnosti

U klíče uloženého ve správě služby agent sestaví požadavek a proxy k němu přidá přístupový údaj až při odeslání. Hodnota tak nemusí být v proměnné prostředí ani v souboru, který agent přečte. To zužuje možnost, aby ji přímo opsal do odpovědi či odeslal jinam. Platí to pro klíč předaný přes proxy, nikoli pro údaj, který někdo vložil přímo do repozitáře, konfigurace nebo přístupné relace.

Agent může přesto využít oprávnění, jež spravovaný klíč poskytuje. Pokud smí volat určité API, proxy odešle požadavek s platným údajem a cílová služba jej může přijmout jako autorizovaný. Případné čtení nebo změna dat pak závisí na rozsahu tokenu a na tom, co API povoluje. Skrytí řetězce klíče samo neposuzuje účel požadavku; podobně microVM sama nepozná, zda povolený nástroj provádí žádoucí akci.

Cloud má vlastní síťová pravidla

Před dlouhým spuštěním rozhoduje zejména rozsah odchozího přístupu. Místní pravidla se při přesunu nekopírují, takže v cloudu je nutné vymezit cíle pro model, repozitář, správce balíčků a další připojené služby samostatně. Podstatný je také výchozí režim cílového prostředí: příliš široce povolená doména může agentovi otevřít více operací, než vyžaduje úloha. Síťová zásada pracuje s dosažitelnými cíli, nikoli s úsudkem o vhodnosti každé odpovědi agenta.

Cloudové sandboxy nepodporují místní filtrování podle metody HTTP a cesty v URL. Pravidlo povolující doménu proto nedokáže samo rozlišit čtení od zápisu na různých koncových bodech téhož API. Pro citlivou službu je důležité zúžit oprávnění samotného tokenu a možnosti nástroje, přes který agent službu používá. Docker při přesunu na ztrátu takového místního omezení upozorňuje a v příslušné situaci vyžaduje potvrzení.

Stejnou pozornost zaslouží propojené nástroje. Agent může přes schválenou bránu vyvolat operaci, kterou správce sandboxu zamýšlel pro jiný účel; síťová izolace hostitele ji nezastaví, jestliže ji povolené rozhraní samo nabízí. Kontrola před spuštěním proto zahrnuje cílové domény, rozsah přístupových údajů, práva připojených nástrojů a skutečně povolené i odmítnuté spojení v cloudovém sandboxu. Každá z těchto hranic omezuje jinou část dosahu agenta.

Dlouhá práce běží bez notebooku, dokud trvá cloudová relace

Cloudové prostředí se hodí pro úlohu, která už má všechny potřebné soubory a dokáže průběžný postup ukládat. Výpočetní prostředky spravuje Docker, takže pokračování po zavření notebooku není závislé na tom, zda místní počítač zůstane zapnutý. Služba zároveň umožňuje spouštět samostatné sandboxy pro souběžné úkoly; každý má vlastní běhové prostředí a pravidla. Přesun však vyžaduje, aby na nové straně bylo možné úlohu obnovit ze stavu, který se skutečně zkopíroval.

Cloudový sandbox má nastavenou dobu života a akci po jejím vypršení. Pro práci ponechanou bez dozoru je to stejně důležité jako dostupný výpočetní výkon: rozběhnutý agent potřebuje čas na dokončení a výsledky musejí být uložené tam, odkud je bude možné získat. U úlohy delší než nastavená relace rozhodne uložený mezivýsledek o tom, zda na ni půjde po ukončení sandboxu navázat.