Автономният агент за обслужване на клиенти и връщане на стоки с отворен код на Google, изграден с помощта на комплекта за разработка на агенти (ADK) и Gemini, демонстрира как разработчиците могат да прилагат принципите за сигурност от тип „нулево доверие“ към ИИ агенти, които взаимодействат с чувствителни системи и предприемат действия в реалния свят.

Проектът тества подход, при който се приема, че ИИ агентът може да бъде манипулиран или компрометиран, и поставя контроли за сигурност около него, за да ограничи неговите действия.

Архитектурата използва предпазни мерки извън модела за проверка на действията, ограничаване на генерирания от ИИ код и блокиране на потенциално опасни заявки.

Агентът за поддръжка на клиенти показва защо тези контроли са важни. По време на нормална работа той чете заявката за връщане на клиент, генерира Python скрипт за изчисляване на пропорционалните удръжки за възстановяване на запасите, записва одобреното възстановяване на сумата в база данни и предоставя потвърждение.

Google демонстрира атака, при която клиент с поръчка за 149 долара инструктира агента да възстанови 10 000 долара и да изпълни Python код, който разкрива променливите на средата. Агент, използващ споделена връзка с базата данни и изпълняващ код в неизолирана среда, би могъл да разреши плащането, да разкрие API ключове или да компрометира хост сървъра.

Дизайнът на Google третира модела като компонент, който може да бъде подведен или подложен на „jailbreak“ (преодоляване на защитите). Системната подкана (system prompt), указваща на агента никога да не възстановява сума, по-голяма от стойността на поръчката, не осигурява надеждна граница на сигурност. Инжектирането на подкани (prompt injection) може да заобиколи подобни инструкции, докато фината настройка на подканите (prompt tuning) и актуализациите на модела могат да променят начина, по по който той реагира.

Референтната архитектура използва три слоя за сигурност извън модела: криптографски подписи за промени в базата данни, изолирани среди за генерирания код и семантичен шлюз (Semantic Gateway), който проверява входните данни и действията спрямо детерминистични правила.

Всеки запис в базата данни, който променя състоянието, се подписва от агента, отговорен за него, и базата данни проверява подписа преди извършване на трансакцията. Това осигурява криптографско авторство, свързващо промяната в базата данни с подписващата идентичност на агента, и прави откриваема всяка последваща намеса.

За производствени внедрявания в Google Cloud, Google препоръчва на всеки агент да се присвоява собствен сервизен акаунт (service account) и да му се предоставят разрешения за подписване с асиметричен ключ в услугата Cloud Key Management Service (KMS), поддържана от хардуерен модул за сигурност (HSM). В предложената от Google конфигурация частният ключ се генерира вътре в HSM и не го напуска.

Демонстрацията с отворен код използва HMAC ключ за симулиране на Cloud KMS за локално тестване. Независим фонов одит може да проверява целостта на записите в базата данни. Ако атакуващ промени възстановяване от 149 долара на 10 000 долара директно в базата данни, подписът няма да съвпадне с променения зловреден код и одитът ще задейства предупреждение.

Изпълнението на код създава друг риск за сигурността. Автономният агент може да генерира Python за изчисления, парсване на данни или обработка на логове. Инжектирането на подкани може да насочи тази възможност към код, предназначен да извлича променливи на средата и API ключове или да се свързва със сървър, контролиран от атакуващия.

Примерът на Google изпълнява генерирания код в изолирана среда (sandbox) на потребителско пространство gVisor с деактивиран мрежов достъп и ограничения за паметта, използването на процесора и времето за изпълнение. Изолираната среда отделя генерирания код от хоста и спира изходящия мрежов трафик, докато петсекунден таймаут прекратява прекомерно дългото изпълнение.

Третият слой използва семантичен шлюз (Semantic Gateway) между агента и системите, на които той може да повлияе. Шлюзът прилага детерминистични проверки на входящите подкани и изходящите повиквания към инструменти (tool calls), преди моделът да бъде извикан или да бъдат изпълнени актуализации на базата данни. Тези проверки могат да идентифицират номера на кредитни карти и тайни, да съвпадат с определени шаблони за заобикаляне на защитата и да налагат лимити на трансакциите.

Заявка за игнориране на инструкциите за безопасност и възстановяване на 10 000 долара, например, може да бъде блокирана преди действието да се случи. Google препоръчва тези политики да се третират като софтуерни договори и да се използват автоматизирани тестове, за да се гарантира, че предпазните мерки продължават да работят след промени в подканите или миграция на модела.

При производствени внедрявания съответните услуги могат също да бъдат поставени в периметър на VPC Service Controls, добавяйки граница, предназначена да предотврати изтичане на данни извън периметъра на проекта, ако работният товар на агента бъде компрометиран.

„Изграждането на автономни агенти не изисква приемане на неограничен риск“, пишат Шубхам Сабу и Ерик Донг от Google. „Чрез преместване на границите на сигурността в хардуерно обезпечена идентичност, изолиране на ядрото в потребителското пространство и детерминистична валидация на входа и изхода, вие помагате на модела да се справя с динамичното разсъждение, докато основната инфраструктура налага строги ограничения.“

Референтната реализация с отворен код може да бъде тествана локално, включително със сценарии за атаки, предназначени да изпробват контролите за сигурност. Разработчиците могат също да стартират базирана на браузър интерактивна среда за атаки (Live Attack Playground) и да използват документацията за ADK на Google, за да започнат да изграждат инструменти и сесии за агенти.