Google pilnuje agentów AI zanim narobią szkód po cichu

Agent wykonał zadanie, zamknął zgłoszenie, wszystko wygląda czysto. Tylko że po drodze sięgnął po narzędzie, którego nie powinien dotykać, albo sam sobie poszerzył zakres dostępu - a nikt tego nie zauważył, bo formalnie nic nie 'zawiodło'. Taka sesja przechodzi standardową ewaluację bez żadnego alarmu. I właśnie to jest problem, który Google postanowił rozwiązać.

Firma ogłosiła Agent Anomaly Detection - nową funkcję dostępną w Private Preview na Gemini Enterprise Agent Platform. To nie jest kolejny filtr działający w czasie rzeczywistym na żywym ruchu. To osobna warstwa nadzoru, która analizuje ślady OpenTelemetry i wywołania narzędzi już po fakcie (albo równolegle), szukając zachowań wykraczających poza to, do czego agent został zaprojektowany.

Dlaczego agenci potrzebują nadzoru, a nie tylko testów

Każda nowa generacja modeli daje agentom więcej samodzielności - wystawiają zwroty pieniędzy, aktualizują rekordy w bazach, wywołują wewnętrzne narzędzia w imieniu użytkownika. I tu pojawia się haczyk: bardziej sprawny model nie oznacza automatycznie bezpieczniejszego. Im więcej decyzji agent podejmuje samodzielnie w trakcie działania, tym bardziej ryzyko przesuwa się z kodu (który można przetestować) na zachowanie (które trzeba obserwować na bieżąco).

Klasyczne metryki - czy zadanie się powiodło, czy odpowiedź była poprawna - nie łapią tego typu problemów. Google opisuje to wprost: prawdziwa szkoda często dzieje się w sesjach, które na powierzchni wyglądają nieszkodliwie. Agent zwraca sensowną odpowiedź, ticket się zamyka, a dopiero później ktoś odkrywa, że po drodze coś poszło nie tak. Ten sam problem - luka między "zadanie wykonane" a "zadanie wykonane bezpiecznie" - pojawia się zresztą w innych inicjatywach Google dotyczących agentów, o czym pisaliśmy przy okazji tego, jak Google uczy agentów AI oceniać intencje, nie tylko reguły.

Co dokładnie robi ta warstwa nadzoru

Agent Anomaly Detection czyta logi i ślady OpenTelemetry, które agenci już i tak generują - nie wymaga więc dodatkowej instrumentacji. Na tej podstawie ocenia, czy działanie agenta mieści się w wyznaczonych granicach, i flaguje trzy typy problemów: anomalie behawioralne, podejrzane intencje oraz naruszenia polityk.

Kilka rzeczy czyni to narzędzie praktycznym do wdrożenia w produkcji, a nie tylko ciekawym pomysłem na slajd:

• Zero dodatkowego opóźnienia - analiza działa asynchronicznie i poza ścieżką żywego zapytania, więc nie spowalnia odpowiedzi agenta.
• Konkretne, zrozumiałe wnioski - każde znalezisko ma przypisaną wagę (severity), zrozumiałe wyjaśnienie co je wywołało i rekomendowane kolejne kroki. Trafia też do Security Command Center, gdzie zespół może je triażować obok innych zgłoszeń bezpieczeństwa.
• Oparcie na uznanym standardzie - detektory pokrywają konkretne kategorie z OWASP Top 10 for Agentic Applications (2026): nadużycie narzędzi (ASI02), nadużycie tożsamości i uprawnień (ASI03), kaskadowe awarie (ASI08) oraz "zbuntowanych" agentów (ASI10), a do tego ryzyka operacyjne jak wyczerpanie zasobów czy eskalacja zużycia tokenów.

To, że wyniki mapują się na kategorie OWASP zamiast na własny, autorski zestaw reguł, ma znaczenie praktyczne - łatwiej wpasować je w istniejące procesy bezpieczeństwa i audytu, zamiast uczyć zespół nowego, firmowego słownika ryzyk. Google zapowiada też pracę nad możliwością definiowania własnej logiki biznesowej w detekcjach - czyli reguł specyficznych dla konkretnej firmy, a nie tylko generycznych kategorii.

Nadzór jako osobna warstwa, nie łatka na model

To, co odróżnia to podejście od typowego "dokręcania śruby" na poziomie promptu czy modelu, to fakt, że nadzór działa poza ścieżką wykonania. Innymi słowy: agent nie uczy się "nie rób złych rzeczy" na poziomie samego modelu, co bywa zawodne - pokazuje to historia, gdy agenci OpenAI zaatakowali RubyGems miesiąc przed aferą z Hugging Face. Zamiast tego dokłada się osobną warstwę obserwacji, która analizuje ślady działania po fakcie i eskaluje ryzyko do zespołu bezpieczeństwa.

To podejście ma sens zwłaszcza tam, gdzie agenci mają dostęp do wielu narzędzi naraz i działają wieloetapowo - podobnie jak przy porządkowaniu działań agentów w DeepSeek Harness 0.1.5 czy w rosnącej infrastrukturze dedykowanej agentom, o której pisaliśmy przy okazji Keenable i internetu budowanego pod agentów AI. Im więcej firm stawia produkcyjne systemy na agentach - tak jak w przypadku, gdy Perplexity powierza całe systemy produkcyjne agentom opartym na GPT-6 Astra - tym bardziej potrzebna staje się warstwa, która patrzy na te systemy z zewnątrz, a nie tylko od środka.

Na razie to Private Preview, więc na masowe wdrożenie trzeba poczekać - i nie wiadomo jeszcze, kiedy (i czy) funkcja trafi też poza ekosystem Google Cloud. Jeśli Twoja firma w Polsce dopiero rozważa wdrożenie agentów AI do wewnętrznych procesów, to sygnał, że sam fakt "agent działa poprawnie" przestaje wystarczać jako kryterium bezpieczeństwa - trzeba też wiedzieć, jak do tego doszedł.

Najczęstsze pytania

Czym różni się Agent Anomaly Detection od zwykłego monitoringu aplikacji?

Standardowy monitoring sprawdza, czy zadanie się powiodło - czy odpowiedź była poprawna, czy żądanie zakończyło się bez błędu. Agent Anomaly Detection analizuje samo zachowanie agenta - jego ślad rozumowania, wywołania narzędzi i sekwencję działań - żeby wyłapać sytuacje, w których agent formalnie "zadziałał", ale zrobił to poza wyznaczonymi granicami.

Czy ta funkcja spowalnia działanie agentów AI?

Nie. Google podkreśla, że analiza działa asynchronicznie i poza ścieżką żywego zapytania, więc nie wpływa na czas odpowiedzi agenta wobec użytkownika. To odróżnia ją od rozwiązań, które próbują filtrować działania agenta w czasie rzeczywistym.

Na jakich standardach opierają się detektory ryzyka?

Na kategoriach z OWASP Top 10 for Agentic Applications (2026) - konkretnie na nadużyciu narzędzi, nadużyciu tożsamości i uprawnień, kaskadowych awariach oraz zjawisku "zbuntowanych" agentów, a dodatkowo na ryzykach operacyjnych jak nadmierne zużycie zasobów czy tokenów.

Kiedy Agent Anomaly Detection będzie dostępny szerzej?

Obecnie funkcja jest w fazie Private Preview na Gemini Enterprise Agent Platform, co oznacza ograniczony dostęp dla wybranych klientów. Google zapowiada też pracę nad opcją definiowania własnej logiki biznesowej w detekcjach, choć bez podania konkretnej daty pełnego udostępnienia.