Agent Anomaly Detection на Google е слой за надзор и одит на базата на логически заключения за автономни агенти, внедрени в Agent Runtime в платформата Gemini Enterprise Agent Platform и изградени с Agent Development Kit (ADK) за Python 1.2 или по-нова версия. Google препоръчва ADK 2.1.0 или по-нова версия. Функцията е налична в Private Preview.
Какво следи Agent Anomaly Detection
Agent Anomaly Detection оценява следите (traces), излъчвани от агентите, за да определи дали те работят извън предназначените им граници. Системата сигнализира за поведенчески аномалии, подозрителни намерения и нарушения на политиките за сигурност.
Всяко констатирано отклонение включва ниво на сериозност, обяснение на достъпен език за причината за задействане и препоръчителни действия. Констатациите се публикуват в Security Command Center за триаж и приоритетизиране наред с останалите констатации за сигурност.
Agent Anomaly Detection включва детектори за избрани рискове от OWASP agentic Top 10: злоупотреба с инструменти, злоупотреба със самоличност и привилегии, каскадни сривове при агентите и неконтролируеми агенти (rogue agents).
Злоупотребата с инструменти включва рискове като небезопасно верижно свързване на инструменти (unsafe tool chaining), манипулиране на параметри и индиректно инжектиране на подкани (indirect prompt injection). Злоупотребата със самоличност и привилегии включва неоторизирани действия, произтичащи от проблеми като динамично делегиране на доверие (dynamic trust delegation), фалшифициране на идентичност (persona forgery), ескалация на паметта и уязвимости от тип confused-deputy. Каскадните сривове при агентите включват безкрайни цикли на изпълнение, повторения с колебания (oscillating retries), разпространение на грешки и усилване чрез обратна връзка. Откриването на неконтролируеми агенти обхваща агенти, които изоставят декларираните си роли, заобикалят защитните механизми или се отклоняват от системните инструкции.
Системата засича и оперативни рискове като изчерпване на ресурсите и ескалиращо използване на токени.
„Активно работим върху възможността потребителите да дефинират какво означават аномалиите в контекста на техния бизнес. Това ще позволи на потребителите да пишат гъвкави детектори за аномалии на естествен език заедно с детерминистични правила, които сигнализират, когато агентите работят извън специфичните за предприятието бизнес насоки. Освен това потребителите ще могат да валидират точността на новата си персонализирана бизнес логика върху минал трафик“, обяснява Ачут Нараян Раджагопал (Achuth Narayan Rajagopal), старши софтуерен инженер в Google.
Изисквания и настройка
Трябва да бъдат изпълнени няколко предварителни изисквания за активиране на Agent Anomaly Detection чрез предоставяне с едно кликване.
Хранилищата за логове и наблюдаемост (logging and observability buckets) трябва да бъдат в същия мулти-регион в САЩ. Проследяването и записването на логове с OpenTelemetry трябва да са активирани чрез ADK, суровата телеметрия трябва да улавя подканите (prompt inputs) и върнатите резултати (response outputs), а enable_tracing не трябва да бъде изрично зададено на false.
Регионалните сервизни акаунти за сканиране трябва да имат достатъчен достъп за четене до хранилищата за логове и наблюдаемост. Log Analytics и Observability Analytics също трябва да бъдат активирани за хранилището за логове. Агентите трябва да имат активен поток от телеметрични данни, така че тяхната конфигурация да може да бъде потвърдена и те да могат да бъдат регистрирани.
Откритите агенти се появяват като наблюдавани агенти. Техните логове и следи не се анализират и не се начисляват разходи, докато не бъдат изрично активирани. Агенти, които не отговарят на изискванията, не се откриват.
Как се откриват аномалиите
За да се балансират скоростта на откриване, разходите и покритието, следите и логовете се анализират на слоеве. Лек първи преглед сканира целия трафик за статистически аномалии и маркира необичайни сесии. Базиран на LLM слой за логически заключения след това изследва подробно тези сесии.
За пример разгледайте Inventory Agent с инструмент list_inventory. Потребител заявява преглед на 100 артикула наведнъж, а агентът многократно извиква инструмента с различни офсети, за да извлече целия каталог.
Агентът може да не генерира грешки или явни нарушения на политиките. Независимо от това, неговата активност може да представлява необичаен модел на използване. Първият слой идентифицира сесията като статистическо отклонение въз основа на обема извиквания и повторенията. Вторият изследва целия обмен, идентифицира модела на извличане на големи пакети данни с промяна на офсета като системно събиране на данни (scraping) и връща заключение с обяснение на достъпен език. Когато даден случай се нуждае от по-детайлен преглед, трети слой на ниво извиквания анализира отделните изпълнения на инструментите, състоянията на изпълнение и историята на параметрите в следата от разговора.
Анализ на аномалии в сесията (Източник: Google)
В този пример системата генерира констатация за изчерпване на ресурсите (Resource exhaustion) с критична сериозност (Critical) и 95% вероятност. Констатацията включва обосновка и препоръчителни действия, като например ограничаване на честотата (rate-limiting) или блокиране на инструмента list_inventory за потребителя, ограничаване на масовия достъп до инвентара чрез проверки за оторизация и известяване при модели на пагинация с големи офсети.
Откриването се извършва асинхронно извън реалния път на изпълнение, така че не забавя анализираната заявка. Приложенията могат да извличат констатациите за аномалии чрез API и да използват обратно извикване (callback) от ADK или разширение (plugin), за да сравнят сериозността и вероятността с конфигурираните прагове, което им позволява да блокират последващи извиквания на инструменти или да спрат следващ ред от разговора, когато тези прагове бъдат надвишени.