Custom AI агенти получават MicroVM модел за сигурност
Agent Compute Engine на Google Cloud е важен за екипите, които разработват custom AI agents, защото променя базовото допускане за средата на изпълнение. Вместо да третира агента като обикновен приложен код в контейнер, Google разглежда всяка сесия като недоверен код, който заслужава собствена хардуерно изолирана граница. За корпоративната AI сигурност това е съществена промяна.
Според техническия анализ на Google Cloud и първоначалния репортаж на Marktechpost, Agent Compute Engine дава на всяка агентна сесия собствен microVM, държи идентификационните данни извън sandbox средата и checkpoint-ва неактивните сесии до нула активни ресурси. По-голямата тема не е само скоростта. Става дума за архитектура на AI интеграциите, модел на идентичност и за това как могат да изглеждат сигурните AI automation agents в продукционна среда.
Какво представляват custom AI agents?
Custom AI agents са софтуерни агенти, създадени за конкретни задачи, които могат да разсъждават, да извикват инструменти, да изпълняват код, да навигират в системи и да предприемат действия в рамките на бизнес процеси. В този анонс терминът е важен, защото Google въвежда инфраструктура, проектирана специално за такива агенти, вместо да кара екипите да ги изпълняват върху контейнери или виртуални машини с общо предназначение.
Защо е важен моделът на Google с по един microVM за всеки агент?
Google обяви Agent Compute Engine тази седмица на AGNTCon и MCPCon, като customer preview е планиран през следващите месеци. Основният дизайн е прост: един хардуерно изолиран microVM за всяка агентна сесия, със собствен guest kernel, root достъп и собствен път за съхранение.
Това има значение, защото много проекти за разработка на AI агенти вече включват изпълнение на код, shell команди, браузърни сесии и външни API извиквания. При конвенционален контейнерен модел тези действия често са по-близо до споделени host ресурси и дългоживеещи идентификационни данни, отколкото екипите по сигурност биха приели. Google изрично приема, че sandbox средата може да бъде компрометирана чрез prompt injection или злонамерена употреба на инструменти.
Пазарът се разделя по три линии. Първо, някои доставчици оптимизират за удобство на разработчиците. Второ, други оптимизират за cloud плътност. Трето, по-малка група оптимизира за контрол върху blast radius. Agent Compute Engine попада в третата категория.
Google твърди, че услугата вече захранва Gemini за работни задачи. Компанията посочва още, че host слоят работи върху управлявани от Google системи с Titan silicon и Titanium IPU, с Cloud Hypervisor граница около всеки microVM. Също толкова важно е и това, което не е разкрито: няма публични цени, няма ACE-специфично време за стартиране, няма данни за плътност и няма точна дата за preview.
Как разделението между harness и sandbox променя архитектурата на AI интеграциите?
Google разделя агента на два компонента. Harness, на практика control plane, извиква модела и решава какво да се случи след това. Sandbox изпълнява кода, shell командите или действията в браузъра. Това разделение е по-значимо, отколкото изглежда на пръв поглед.
На практика то означава, че слоят за разсъждение и слоят за изпълнение вече не трябва да споделят една и съща граница на доверие. Harness може да остане извън sandbox средата, докато sandbox-ът се третира като disposable и недоверен. Това е по-чист модел за private AI solutions от масовия подход, при който един runtime получава широк достъп до инструменти, памет и идентификационни данни.
Мрежовият път допълнително подсилва това разделение. Google посочва, че microVM-ите нямат стандартен мрежов интерфейс, нямат default gateway и нямат директен VPC достъп. Трафикът преминава през virtio-vsock граница към локален proxy, след което достига до gateway извън възела, където се прилагат policy проверки, преди да бъде въведен реален credential. Това е по-близо до service-mediation модел, отколкото до обичаен runtime модел.
За корпоративните екипи, които проектират услуги за внедряване на AI автоматизация, неочевидният извод е, че инфраструктурата за агенти започва да прилича повече на zero-trust дизайн на натоварвания, отколкото на внедряване на чатбот. Това влияе върху мястото, където трябва да живее логиката за AI API integration, как се събират audit trail-ите и как корпоративните AI интеграции се сегментират според риска.
Защо идентификационните данни се изваждат изцяло от агентния възел?
Най-силното архитектурно решение в Agent Compute Engine не е самият microVM. То е отказът да се оставят полезни тайни в sandbox средата.
Google описва четири идентичности за агентни натоварвания: идентичност на потребителя, делегирана on-behalf-of идентичност, agent workload identity и agent workforce identity. Само краткоживеещата workload identity влиза в sandbox средата, като според информацията използва SPIFFE семантика. Тази идентичност е полезна главно за това да покаже кой sandbox е изпратил даден пакет. Тя не би трябвало да е достатъчна за директен достъп до backend системи.
Реалният backend credential се подменя по-късно от Agent Gateway след policy проверки. На практика Google премества момента, в който се използва секрет, извън compute възела. Това е съществен архитектурен избор за корпоративната AI сигурност, защото намалява стойността на евентуално изтичане на данни отвътре в runtime средата.
Точно тук custom AI agents се превръщат в проблем на идентичността, а не само на оркестрацията. Ако един агент може да действа от името на потребител, предприятието трябва да знае кои разрешения идват от човека, кои идват от собствения акаунт на агента и кои са дадени само за конкретната сесия. AWS прави сходни стъпки с AgentCore Runtime, а Microsoft обсъжда компромисите между изолация и lifecycle в Azure dynamic sessions. Приносът на Google е, че поставя това разделение на идентичностите в центъра на продуктовия разказ.
Какво променя checkpoint-ването при неактивност за AI automation agents?
Повечето агенти прекарват дълги периоди в изчакване: за отговор от модел, за решение от потребител или за външна система. Google твърди, че Agent Compute Engine checkpoint-ва неактивните microVM-и до нула активни ресурси и ги възстановява от snapshots, когато пристигне следващото извикване към инструмент.
Ако това работи така, както е описано, оперативният ефект може да бъде значителен. AI automation agents са скъпи, когато екипите ги осигуряват като винаги активни application workers. Те стават по-икономични, когато runtime средата може да запази състоянието, като в същото време сведе активното изчислително потребление почти до нула.
Google не е публикувала ключовите ACE показатели, но е споделила данни за своя open-source родствен продукт, Agent Substrate on GKE. Те включват до 10x по-висока изчислителна плътност спрямо традиционния compute, 500 активирания в секунда, под 500 ms latency при suspend-resume и над 1,000 dormant агента на host в benchmark с 200,000 агента.
Това са полезни ориентири, но не и директни доказателства за самия Agent Compute Engine. Все пак те подсказват накъде може да се придвижи икономиката на разработката на AI агенти: по-малко дългоживеещи workers, повече възстановими сесии и по-голяма зависимост от copy-on-write споделяне на паметта и предварително подготвени snapshots.
Как Agent Compute Engine се сравнява с AgentCore, Azure и E2B?
Сравнението е по-малко въпрос на директен feature parity и повече на това какво всяка платформа избира да разкрие публично.
| Platform | Isolation model | Idle handling | Credentials in sandbox | Availability |
|---|---|---|---|---|
| Google Agent Compute Engine | Cloud Hypervisor microVM за сесия | Checkpoint до нула активни ресурси | Няма, според Google | Preview през следващите месеци |
| Google Agent Substrate | Cloud Hypervisor microVM или gVisor | Snapshot и освобождаване на CPU/RAM | Чрез egress proxy модел | GKE non-production, GA allowlist |
| AWS AgentCore Runtime | Специализиран microVM за сесия | Таксуването за CPU обикновено пропуска I/O wait | Управлявани от AgentCore Identity | Наличен |
| Azure dynamic sessions | Hyper-V sandbox | Унищожават се след cooldown | Не е ясно разкрито | Наличност в няколко региона |
| E2B | Firecracker microVM | Pause запазва файлове и памет | Не е ясно разкрито | Наличен |
Най-силният диференциатор на Google е изричното твърдение, че в sandbox средата не живеят backend идентификационни данни. Най-слабата точка към момента е продуктовата неяснота. Купувачите все още нямат информация за цени, boot метрики или конкретна дата за preview. За сравнение, документацията на E2B е по-ясна относно поведението при възстановяване, а AWS е по-ясна относно general availability.
Какво трябва да валидират корпоративните екипи преди да приемат този модел?
Три въпроса са по-важни от самото заглавие на анонса.
Първо, кои натоварвания действително се нуждаят от microVM изолация? Употреба на браузър с висок риск, изпълнение на код и широки корпоративни AI интеграции са очевидни кандидати. Прости retrieval или form-filling потоци може да не оправдаят допълнителната сложност.
Второ, къде трябва да стои policy границата? Най-важното архитектурно решение може да е не толкова изборът на модел, колкото мястото, където се случват делегираното упълномощаване, обменът на токени и филтрирането на изходящия трафик.
Трето, колко архитектура трябва да се изгради около продукт в preview? Разумният ход е да се тества моделът, а не да се заковава всичко към всеки специфичен за Google детайл. Това означава първо да се докаже стойността на workload identity, възстановимите сесии и secretless sandbox средите, преди да се поеме ангажимент към runtime-а на един конкретен доставчик.
FAQ
Какво е Google Agent Compute Engine?
Това е compute услуга на Google Cloud за AI агенти, която изпълнява всяка агентна сесия в собствен хардуерно изолиран microVM. Google твърди, че sandbox средата не съдържа идентификационни данни и може да бъде checkpoint-вана при неактивност, което прави анонса особено релевантен за сигурни custom AI agents.
С какво Agent Compute Engine се различава от контейнерите?
Контейнерите обикновено споделят kernel и разчитат на софтуерна изолация в рамките на споделена host среда. Agent Compute Engine поставя всяка сесия в специализиран microVM със собствен guest kernel, което е по-подходящо за изпълнение на недоверен код и за изискванията на корпоративната AI сигурност.
Публикувала ли е Google цени или време за стартиране?
Не. Google не е публикувала цени, boot time, плътност или точна дата за preview на Agent Compute Engine. Компанията е споделила по-силни benchmark данни за Agent Substrate, но това е свързан продукт, а не самата управлявана услуга.
Защо моделът с четири идентичности е важен?
Защото разделя потребителя, делегираното упълномощаване, workload идентичността в sandbox средата и собствения акаунт на агента. Това разделение намалява полезността на всеки credential, взет отвътре от sandbox средата, и прави AI API integration потоците по-лесни за одитиране.
Трябва ли екипите да изберат първо Agent Compute Engine или Agent Substrate?
Екипите, които искат управляван път, могат да изчакат preview на ACE. Екипите, които искат по-ранни експерименти или повече контрол, могат първо да оценят Agent Substrate върху Kubernetes, особено за non-production тестване на архитектура за AI интеграции.
Ключови изводи
- Custom AI agents започват да получават специализирани runtime среди, вместо да бъдат третирани като обикновени приложни натоварвания.
- Основната иновация на Google не е само microVM изолацията, а и това, че държи полезните идентификационни данни изцяло извън sandbox средата.
- Checkpoint-ването при неактивност може съществено да промени разходния профил на AI automation agents, ако ACE се доближи до производителността на Substrate при възстановяване.
- Основният компромис е неяснотата: цени, плътност, време за стартиране и график за preview все още не са публични.
- Корпоративните екипи трябва първо да тестват архитектурния модел, а след това да решат дали управляваната услуга е достатъчно зряла за продукционна среда.
Martin Kuvandzhiev
Co-Founder & CEO, encorp.ai
CEO and Founder of Encorp.io with expertise in AI and business transformation
LinkedIn