Google оголосила про впровадження багаторівневої архітектури безпеки для браузерних ІІ-агентів Chrome, які працюють на базі моделі Gemini. Нова модель захисту орієнтована на сценарії, коли агент самостійно взаємодіє з вебом: відкриває сайти, аналізує їхній вміст, клікає на елементи інтерфейсу, заповнює форми та виконує складні послідовності дій від імені користувача.
Чому браузерні ІІ-агенти потребують посиленої безпеки
Ключова загроза для автономних ІІ-агентів у браузері пов’язана з непрямими prompt injection-атаками (indirect prompt injection). У цьому випадку шкідливі інструкції вбудовуються безпосередньо в контент веб-сторінки й намагаються змусити модель виконати дії, що суперечать інтересам користувача: розкрити облікові дані, змінити платіжні реквізити, авторизуватися на фішинговому ресурсі або ініціювати небажані транзакції.
Промпт-інжекти вже виділяються окремим класом ризиків у профільних документах, зокрема в OWASP Top 10 for LLM Applications, де вони розглядаються як один з основних векторів атак на системи з використанням LLM. Поява в браузері автономних ІІ-агентів з доступом до реального вебу робить питання їх ізоляції, контролю та моніторингу критично важливим як для приватних користувачів, так і для корпоративного сектору.
Багаторівнева архітектура безпеки Chrome для агентів Gemini
Ізольований «критик» Gemini як компонент підвищеної довіри
Центральний елемент нової моделі — окрема ізольована інстанція Gemini, що виступає в ролі «критика» або високодостовірного системного компонента. На відміну від основного агента, цей «критик» не взаємодіє безпосередньо з потенційно шкідливим веб-контентом, а аналізує лише метадані запитуваної операції та опис цілей користувача.
Перед виконанням небудь дії в браузері запит проходить через незалежну перевірку: «критик» оцінює, чи відповідає крок початковому завданню та чи не містить він очевидних ризиків. Якщо дія виглядає підозрілою, Chrome або змушує агента переглянути свій план, або повертає контроль користувачу. Така схема фактично реалізує принцип «подвійного контролю», коли рішення ухвалюють дві незалежні логічні сутності.
Origin Sets: сегментація доступу ІІ-агента до веб-ресурсів
Другий рівень оборони реалізовано через механізм Origin Sets, який задає чіткі межі, з якими доменами та елементами може працювати агент. Увесь сторонній контент, включно з iframe, за замовчуванням блокується, доки не буде явно дозволений політикою доступу.
Таке розмежування джерел істотно знижує ризик перехресного витоку даних між сайтами і обмежує масштаб потенційного компрометування агента. Навіть якщо зловмиснику вдасться реалізувати prompt injection на одному ресурсі, використати його для атаки на інші домени буде значно складніше, оскільки агент фізично не матиме до них доступу без окремого дозволу.
Ручне підтвердження критичних дій користувачем
Для високоризикових сценаріїв Google додала додатковий, «людський» рівень перевірки. Коли ІІ-агент намагається виконати дію, пов’язану з банківськими порталами, платіжними сервісами або доступом до збережених паролів у Password Manager, Chrome автоматично ставить операцію на паузу.
У таких випадках остаточне рішення приймає користувач: лише після явного підтвердження агент може продовжити виконання дій. Цей механізм грає роль своєрідного «kill switch» для сценаріїв, пов’язаних з фінансовими транзакціями, авторизацією та доступом до особливо чутливих облікових записів.
Виявлення prompt injection та автоматизований red teaming
Окремий компонент архітектури — вбудований у Chrome класифікатор непрямих prompt injection-атак. Він аналізує вміст сторінок на наявність прихованих інструкцій, здатних змінити поведінку ІІ-агента, і працює поряд із системою Safe Browsing та локальними антифрод-механізмами браузера.
Для безперервної перевірки ефективності захисту Google застосовує автоматизовані інструменти red teaming’у, які генерують тестові сайти й сценарії атак на LLM. Вони моделюють, зокрема, ланцюжки з відкладеними наслідками: викрадення облікових даних, несанкціоновані фінансові операції, маніпуляцію історією дій агента. Отримані метрики успішних атак дозволяють інженерам оперативно доопрацьовувати моделі безпеки та розгортати оновлення Chrome в автоматичному режимі.
Bug bounty до 20 000 доларів і значення для ринку безпеки ІІ
Для нової архітектури Google запускає цільову bug bounty-програму з винагородою до 20 000 доларів США за виявлення способів обходу захисту ІІ-агентів. Це має мотивувати дослідників безпеки активніше аналізувати нові механізми, відповідально розкривати знайдені вразливості та сприяти підвищенню стійкості екосистеми.
Для індустрії кібербезпеки штучного інтелекту такий крок є важливим сигналом: провідні вендори розглядають prompt injection та інші специфічні атаки на LLM не як теоретичну, а як практичну та актуальну загрозу. Масове впровадження подібної багаторівневої моделі захисту в популярному браузері може фактично задати новий стандарт для розробників, які інтегрують ІІ-агентів у споживчі та корпоративні застосунки.
На боці користувача та організацій залишається відповідальність за базову цифрову гігієну: регулярне оновлення Chrome, обережність під час роботи з фінансовими сервісами, обмеження прав доступу розширень, уважне ставлення до завдань, які делегуються ІІ-агентам. Варто розглядати нову архітектуру безпеки як потужний, але не єдиний бар’єр: підсилити його допоможуть внутрішні політики доступу, навчання співробітників та власні процедури тестування ІІ-рішень. Чим активніше розвиватиметься екосистема захисних інструментів і досліджень у галузі безпеки LLM, тим безпечнішим стане повсякденне використання штучного інтелекту у веб-додатках та корпоративному середовищі.
