Gemini API rozšířil agenty o hooky, které smí zablokovat volání nástroje

Google 28. července 2026 rozšířil Managed Agents v Gemini API o několik novinek najednou: výchozí model Gemini 3.6 Flash, takzvané environment hooky, strop na spotřebu tokenů, naplánované spouštění podle cronu, přístup i na bezplatném tarifu a samostatné API pro správu sandboxů. Popisuje to firemní blog. Podle rozboru serveru The AI Navigator žádná z novinek sama o sobě nevypadá okázale, dohromady ale ukazují, jak má vypadat kontrolní vrstva nad autonomními agenty.

Jeden sandbox na jedno volání API

Managed Agents v Gemini API fungují tak, že jediné volání API vytvoří izolovaný linuxový sandbox v cloudu. Uvnitř něj model uvažuje, spouští kód, instaluje balíčky, pracuje se soubory a prochází web – bez toho, aby vývojář musel řešit vlastní orchestraci. Výchozím modelem se od aktualizace bez nutnosti měnit kód stal Gemini 3.6 Flash; jde ale explicitně zvolit i Gemini 3.5 Flash nebo úspornější Gemini 3.5 Flash-Lite přes pole agent_config.model.

Hooky před a po volání nástroje

Nejvýraznější novinkou jsou environment hooky. Do prostředí agenta stačí přidat soubor .agents/hooks.json a runtime pak spustí přiřazené skripty při událostech pre_tool_execution a post_tool_execution. Pole matcher bere regulární výraz, takže jde zacílit na víc nástrojů najednou nebo hvězdičkou na všechny:

{
  "security-gate": {
    "pre_tool_execution": [{
      "matcher": "code_execution|write_file",
      "hooks": [{"type": "command", "command": "python3 gate.py", "timeout": 10}]
    }]
  }
}

Když skript před spuštěním nástroje vrátí {"decision": "deny", "reason": "..."}, agent volání nástroje neprovede a důvod zamítnutí se dostane rovnou do kontextu modelu, který na to může zareagovat. Hook spuštěný až po volání – třeba na formátování kódu nebo audit – už provedenou akci vrátit nemůže. Podle firmy OffDeal, citované přímo v oznámení Googlu, díky tomu můžou hooky poprvé ověřovat výstupy – v jejich případě loga firem v investičních prezentacích – přímo uvnitř vzdáleného sandboxu, kam dřív jejich vlastní kontrolní kód neměl kam sáhnout.

The AI Navigator ale upozorňuje na meze: hooky zatím nepokrývají volání externích nástrojů přes MCP ani vlastní funkce, a když hook vrátí neplatnou odpověď, výchozí chování je akci povolit, ne zablokovat. Server také píše, že pokud konfigurace hooků leží v zapisovatelném místě uvnitř téhož prostředí, dost schopný agent do ní teoreticky může sám zasáhnout – proti tomu pomáhá jen konfigurace jen pro čtení nebo externí koncový bod mimo dosah sandboxu.

Strop na tokeny a spouštění podle cronu

Protože agent běží ve víckolovém autonomním cyklu, může spotřeba tokenů snadno utéct. Nové pole max_total_tokens v agent_config stanoví strop na celkovou spotřebu (vstupní, výstupní i „přemýšlecí“ tokeny dohromady); po jeho dosažení běh bezpečně pozastaví se stavem incomplete, prostředí sandboxu zůstane zachované a práce jde dokončit předáním previous_interaction_id s novým rozpočtem. Podle dokumentace Googlu, kterou cituje The AI Navigator, se jedna interakce běžně pohybuje mezi 100 000 a 3 miliony tokenů, u složitějších úkolů i mezi 3 a 5 miliony – strop je proto míněný jako hrubá pojistka, ne přesný cenový limit: kešované tokeny se do něj nepočítají a skutečná spotřeba ho může mírně přesáhnout, protože se kontroluje jen mezi jednotlivými kroky agenta.

Naplánované spouštění (scheduled triggers) sváže agenta, jeho prostředí, zadání a cron rozvrh do trvalého zdroje, který se spouští sám a při každém běhu používá tentýž sandbox, takže si soubory mezi jednotlivými spuštěními pamatuje. Nové Environments API navíc dovolí sandboxy vypsat, prohlédnout a smazat ručně, místo aby vývojář čekal na výchozí sedmidenní platnost. Managed Agents jsou od aktualizace dostupné i na bezplatném tarifu bez aktivní fakturace.

Kontrolní vrstva, ne hotová bezpečnostní hranice

Sandboxy mají podle dokumentace Googlu ve výchozím stavu neomezený odchozí přístup k síti, omezit ho jde jen vlastním seznamem povolených adres. The AI Navigator z toho vyvozuje, že hooky, strop na tokeny ani naplánované spouštění samy o sobě nedělají nasazení agenta bezpečným – jde spíš o soubor nástrojů, kterými si tým může sám vynutit, co agent nikdy nesmí udělat bez schválení, a jak poznat, že agent běžící podle rozvrhu pořád ještě někdo sleduje. Server v té souvislosti cituje i zprávu The GenAI Divide konsorcia MIT NANDA z roku 2025, podle které přibližně 95 % zkoumaných firemních nasazení generativní AI nepřineslo měřitelný dopad na hospodářský výsledek – hlavní příčinou podle té zprávy nebyly schopnosti modelů, ale integrace do provozu a chybějící organizační rámec kolem nich.