Docker мести coding агентите в microVM — задачата продължава след лаптопа

На 24 септември 2026 г. Docker представи Cloud Sandboxes като достъпна услуга за агенти в облачни microVM: сесиите са с едночасов срок по подразбиране и могат да продължат до 24 часа, а обявените цени са от 0,07 до 1,12 долара на час според размера на средата. Разработчикът може да започне в локален sandbox, да прехвърли файловата му система с командата sbx move и да продължи работата в облака след затваряне на лаптопа. Прехвърлянето създава нова среда от файлова снимка; то не запазва работещия процес на агента.

В репортажа на Tom’s Hardware от 25 септември е описана демонстрацията на WeAreDevelopers North America: Марк Кавадж пуска Claude в обикновен контейнер с монтиран Docker socket на хоста и агентът достига тайна извън контейнера, а при повторение на подхода в microVM sandbox, показано от Майкъл Ъруин, опитът се проваля; Кавадж казва: „Dobbiamo separare i container dal contenimento“ („Трябва да отделим контейнерите от изолацията“). Резултатът показва риска от конкретната конфигурация с достъп до хостовия socket. Той не означава, че всяка задача в microVM е защитена независимо от дадените на агента права.

Как работата преминава от лаптопа в облака

Командата sbx move пренася състоянието, записано във файловата система на sandbox, и създава нов sandbox с отделен идентификатор. Ръководството на Docker за прехвърляне уточнява, че изходната среда не се изтрива, промените в двете копия не се синхронизират и работещите процеси, паметта и отворените връзки не пътуват със снимката. При прехвърляне към облака локалната среда се спира, докато се създава снимката. За продължителна задача това означава агентът да може да възобнови работата си от записани файлове и инструкции в новата среда.

1. Разработчикът създава именуван локален sandbox, например със sbx create --name local-project claude, и поставя кода, който трябва да се прехвърли, във файловата система на sandbox. Ако проектът е само в директория от хоста, монтирана в локалната среда, тази директория остава извън снимката.
2. Със sbx move local-project --to cloud се създава облачно копие. При монтирана работна директория инструментът предупреждава, че файловете ѝ няма да бъдат включени; потвърждаването на операцията не променя това. Управляваните локални тайни и локалните мрежови правила също не се копират.
3. Разработчикът намира новата среда със sbx --cloud ls, осигурява нужните облачни удостоверения и стартира агентната работа там. За връщане използва sbx move с името или идентификатора на облачния sandbox и опцията --to local. Получената локална среда пак е отделно копие, а файловете ѝ не се появяват автоматично в работната директория на хоста.

Тази граница е съществена за проект с локални зависимости. Монтирани директории, външни томове и ресурси извън файловата система на sandbox изискват отделен начин за пренасяне или повторно свързване. Снимката запазва и платформата на източника: прехвърлянето не преобразува среда между linux/amd64 и linux/arm64. Ако новата среда няма съвместима платформа или нужните ресурси, командата сама по себе си няма да осигури работещо продължение на задачата.

Какво отделя microVM от хоста

Всеки sandbox работи в microVM със собствено ядро и Docker daemon. Така агентът няма нужда да получава хостовия Docker socket, за да използва Docker вътре в своята среда. В показаната демонстрация именно монтираният socket дава на агента в обикновения контейнер път към ресурс извън него; при microVM същият път не сработва.

Границата на виртуалната машина обаче не определя какво агентът има право да прави вътре в нея и през разрешените връзки. Cloud Sandboxes поддържа отделни тайни и мрежова политика за всеки sandbox. При управляваните тайни прокси подава необходимия ключ за заявка, без да показва стойността му на агента. Това защитава самата стойност, но агент с достъп до разрешена услуга все пак може да извършва действия чрез нея; обхватът на предоставените права остава решаващ.

Удостоверение, записано като обикновен файл след интерактивен вход вътре в sandbox, има различен статут от управлявана тайна: файлът влиза във файловата снимка и може да стигне до другата среда. Същото важи за чувствителни проектни файлове, оставени в нея. След прехвърляне към облака се прилага облачната мрежова политика, а не ограниченията от локалния sandbox; в обратната посока новата локална среда започва с локалната политика по подразбиране. Затова изолацията на хоста и ограничаването на достъпа до файлове, тайни и мрежови адреси са различни части от защитата.

Кога облачната среда издържа дълга задача

Cloud Sandboxes е подходяща за работа, която трябва да продължи без включен лаптоп, стига агентът да може да поднови изпълнението си след прехвърлянето. Средата може да се управлява отделно от локалната машина, а паралелни задачи могат да работят в отделни microVM. Това е полезно при продължителни промени по код или тестове, когато резултатът ще бъде прегледан по-късно, но не превръща файловата снимка в жива миграция на започнала сесия.

Срокът на облачната среда има практическо последствие: при изтичането му тя може да спре със запазено състояние или да бъде изтрита според поддържаното за профила действие и избраната настройка. При прехвърляне може изрично да се зададат срок чрез --ttl и действие чрез --on-timeout stop; ако спирането не е достъпно за конкретната среда, изричното искане се отхвърля. Екипът трябва да знае и къде агентът записва междинния си резултат, защото незаписаната работа няма как да бъде възстановена от файлова снимка.

Преди изходният sandbox да бъде премахнат, решаващото е новото копие да съдържа нужния код и да разполага с правилните облачни удостоверения и мрежов достъп. Ако агентът може да продължи от запазеното състояние, лаптопът вече не е условие задачата да се изпълнява; правата, които той получава в облака, остават условие за безопасното ѝ изпълнение.

Прочетете също:

• Claude Code срещу Codex: задачата е по-важна от общия победител
• AI агентите посегнаха към хакване, когато задачата стана невъзможна
• Microsoft Defender обединява хора и агенти, но ISOC още е preview