Google opísal runtime governance pre AI agentov v Gemini Enterprise Agent Platform

Čo Google mení

Google v texte publikovanom 15. septembra 2026 opisuje druhý diel série o „zero-trust“ agentoch. Oproti prvej časti, kde boli kontroly viazané najmä na deterministické pravidlá a build-time opatrenia, tu presúva bezpečnostné kontroly do runtime vrstvy platformy pre agentov v Gemini Enterprise Agent Platform. Podľa blogu sa tým governance oddeľuje od samotného kódu agenta a spravuje ju platformový alebo bezpečnostný administrátor. 1

Tri vrstvy runtime governance

Zdroj uvádza tri mechanizmy, ktoré Agent Gateway aplikuje medzi používateľom, modelom, agentom a nástrojmi. Prvou vrstvou je Model Armor, ktorý na vstupe filtruje prompt injection, jailbreaky, škodlivé URL a na výstupe rediguje citlivé údaje. Blog výslovne tvrdí, že pri zhode je požiadavka zablokovaná ešte pred spustením modelu a vracia sa 403, takže sa nespúšťa inferencia ani nespotrebujú tokeny. 1

Druhou vrstvou sú Semantic Governance Policies. Tie podľa Google vyhodnocujú navrhnutý tool call voči používateľskému zámeru, histórii konverzácie a textovým biznis pravidlám ešte pred vykonaním nástroja. V ukážke blog používa pravidlo, podľa ktorého refundácia digitálnych licencií nad 30 USD vyžaduje schválenie manažérom; navrhnuté volanie issue_refund(amount=120.00, item="Workplace User License") je preto zamietnuté a samotné vykonanie nástroja sa potlačí. 1

Treťou vrstvou je Agent Anomaly Detection, ktorý má sledovať správanie naprieč viacerými ťahmi relácie. Zdroj uvádza, že samostatne povolené refundácie po 20 USD môžu v súčte prekročiť hodnotu objednávky 149 USD, hoci každá jednotlivá transakcia prejde jednorazovou politikou. Práve tento typ kumulatívneho zneužitia má detekcia anomálií zachytávať z telemetrie relácie. 1

Praktický význam pre tímy stavajúce agentov

Praktická zmena nie je v novom type business logiky, ale v tom, kde sa vynucuje. Google tvrdí, že Semantic Governance funguje bez ohľadu na to, či agent volá nástroj priamo v kóde, cez API alebo cez MCP server. Pre tímy, ktoré stavajú agentov nad nástrojmi a backendmi, je to dôležitý architektonický bod: pravidlá nemusia byť zabudované iba v samotnom agentovi, ale môžu sa vynucovať v samostatnej platformovej vrstve. 1

Zdroj tiež opisuje closed-loop remediation: po náleze anomálie môže administrátor doplniť nové prirodzenojazykové pravidlo, ktoré sa začne vyhodnocovať pri ďalšom tool calle bez redeployu alebo reštartu agenta. To je podstatné najmä pri útokoch, ktoré sa ukážu až počas prevádzky a nie sú zachytiteľné jedným regexom alebo jedným testom. 1

Hranice toho, čo je doložené

Treba však odlíšiť technický opis od nezávislého overenia. Blog je primárny materiál výrobcu a pracuje s jedným demonštračným scenárom refund agenta. Pri Agent Anomaly Detection zdroj zároveň výslovne uvádza, že názvy detektorov, confidence hodnoty a tvar nálezu sú ilustratívne; repozitár navyše obsahuje lokálny „stand-in“ pre demonštráciu signálov. Text preto dobre vysvetľuje architektúru a mechanizmus, ale nedokladá všeobecnú účinnosť v produkcii, porovnanie s inými prístupmi ani stav dostupnosti týchto funkcií vo forme jasne označenej GA edície. 1

Pre čitateľa z vývoja je teda najpresnejšie čítať tento podklad ako odborný rozbor platformového návrhu runtime guardrailov pre AI agentov, nie ako nezávisle potvrdený výsledok nasadenia. 1