Grab postavil infrastrukturu pro bezpečné spouštění autonomních AI agentů

Bezpečnostní tým singapurského Grabu vyvinul platformu Palana, která řeší problém, se kterým se firmy při nasazování AI agentů teprve začínají potýkat: jak izolovat neprediktabilní chování modelů na úrovni infrastruktury. Autonomní agenti totiž na rozdíl od klasického softwaru píší kód za běhu, volají API podle vlastního uvážení a jsou zranitelní vůči prompt injection útokům. Palana tyto rizika omezuje pomocí izolovaných Kubernetes namespaces, řídící roviny oddělené od běhového prostředí a proxy vrstvy, která zprostředkovává přístup k citlivým datům přes HashiCorp Vault.

Proč běžící AI agent vyžaduje jinou bezpečnostní architekturu než klasická aplikace

Deterministický software pracuje podle předem napsaného kódu. Vývojář ví, které API endpoint aplikace zavolá, jaké secrets potřebuje a jak reaguje na vstupy. U autonomních agentů tato předvídatelnost mizí. Model může za běhu vygenerovat SQL dotaz, zavolat neočekávaný API endpoint nebo napsat skript, který změní chování workloadu. Prompt injection pak útočníkovi umožňuje přimět agenta, aby provedl akce mimo záměr tvůrce.

Grab tyto scénáře neřešil běžným code review nebo statickou analýzou, protože kód agenta vzniká dynamicky. Místo toho posunul bezpečnostní kontrolu o vrstvu níž — na úroveň infrastruktury. Palana běží nad Kubernetes a každému agentovi přiřadí izolovaný namespace s vlastními síťovými pravidly a politikami přístupu k secrets. Agent nemůže přímo číst citlivá data z proměnných prostředí ani volat libovolné služby — vše prochází proxy vrstvou, která kontroluje oprávnění proti Vaultu.

Jak Palana odděluje řízení agenta od jeho vykonávacího prostředí

Klíčový prvek architektury je out-of-process control plane. Řídící logika agenta — orchestrace úkolů, rozhodování o dalších krocích, volání modelu — běží odděleně od workloadu, který agent skutečně spouští. Když agent potřebuje například přistoupit k databázi nebo zavolat interní API, control plane pošle požadavek proxy službě. Ta ověří, zda má agent v daném namespace oprávnění k dané operaci, načte credentials z Vaultu a teprve pak povolí připojení.

Secrets nejsou nikdy vystaveny přímo agentovi. Nejsou v environment variables, nejsou v konfiguračních souborech workloadu. Proxy je načte just-in-time, použije je pro autentizaci a ihned je zahodí. Pokud útočník získá kontrolu nad agentem přes prompt injection, nevidí hesla ani API klíče — vidí jen zamítnuté požadavky na operace, ke kterým agent nemá oprávnění.

Kde má smysl izolovat agenty na úrovni infrastruktury místo code review

Palana je užitečná tam, kde firma chce spouštět agenty v produkčním prostředí a nemůže si dovolit, aby jeden kompromitovaný agent ohrozil ostatní služby. To platí hlavně pro interní nástroje s přístupem k citlivým datům — agenty, kteří generují SQL dotazy nad zákaznickými databázemi, automatizují DevOps úkoly nebo spravují infrastrukturu podle přirozeného jazyka.

V těchto scénářích nelze předpokládat, že všechny prompt injection útoky zachytíte na úrovni modelu. Input filtering a guardrails pomáhají, ale nejsou dokonalé. Palana poskytuje fallback vrstvu: i když útočník přesvědčí agenta, aby zkusil exfiltrovat data, infrastruktura mu zablokuje přístup na síťové úrovni. Agent může selhat bezpečně — bez úniku credentials nebo lateral movement do jiných částí systému.

Co platforma neřeší a kde zůstává odpovědnost na straně týmu

Palana izoluje workloady, ale neřeší kvalitu logiky agenta ani správnost jeho výstupů. Pokud agent napíše SQL dotaz, který smaže data, infrastruktura mu v tom nezabrání — dotaz má platné oprávnění. Platforma chrání před úniky a laterálním pohybem, ne před chybami v reasoning nebo halucinacemi modelu.

Tým musí také předem definovat, k jakým službám a datům má agent přístup. To vyžaduje promyslet use case a nastavit granulární politiky ve Vaultu a Kubernetes network policies. Bez té práce Palana poskytne izolaci, ale ne užitečnou funkcionalitu. Grab publikoval implementaci jako otevřený návod, nikoliv jako produkt na jedno kliknutí — očekává se vlastní integrace s infrastrukturou firmy.

Pro týmy, které už provozují Kubernetes a Vault, je Palana konkrétní odpověď na otázku, jak spouštět autonomní agenty v produkci bez toho, aby jeden kompromitovaný workload ohrozil celý systém. Řeší problém, který u deterministického softwaru není třeba řešit, protože tam víte dopředu, co kód udělá. U agentů to nevíte — a proto má smysl kontrolu posunout na vrstvu, která funguje nezávisle na tom, co model vygeneruje.