Три способи, якими ШІ-агенти вже працюють у браузері

Які ШІ-агенти вже можуть діяти у браузерах працівників? Якщо агент почне переглядати сторінки, чи зможете ви відрізнити його від працівника? Багато команд безпеки поки не мають відповідей. Це не брак зусиль, а наслідок того, як швидко ШІ перейшов від відповідей на запитання до виконання дій.

ШІ-агенти працюють у браузерах із доступом до автентифікованих застосунків. Вони можуть взаємодіяти з браузером через інтерфейси налагодження, розширення, браузери з вбудованими агентами та нові стандарти на кшталт WebMCP. Кожен із цих підходів визначає, до чого агент має доступ, як фіксуються його дії та чи можуть їх виявити чинні засоби контролю.

1. Віддалене налагодження: застосунки керують браузером

Один зі способів керувати браузером за допомогою ШІ існує вже давно — це протокол Chrome DevTools (CDP).

CDP створили для перевірки, налагодження й автоматизації браузерів на Chromium. Він надає програмний доступ до переходів між сторінками, їхнього вмісту, мережевої активності та взаємодії з користувачем. Інструменти на кшталт Playwright і Puppeteer використовують його вже багато років. ШІ-агенти застосовують той самий підхід, щоб переходити сайтами, збирати інформацію, заповнювати форми й працювати з вебзастосунками.

Важлива відмінність у тому, що автоматизація може запускатися не в самому браузері. Зовнішній застосунок здатен під’єднатися до браузера з увімкненим налагодженням і керувати його вкладками. Якщо в браузері є автентифіковані сеанси, автоматизація може скористатися цим доступом.

Для більшості засобів безпеки браузер із увімкненим налагодженням, у якому відкрито корпоративні застосунки, виглядає як звичайний автентифікований сеанс.

Варто з’ясувати: які застосунки можуть запускати браузери з налагодженням або під’єднуватися до них? Чи дозволяють це ваші політики та до яких корпоративних сеансів мають доступ ці застосунки?

2. Розширення зі ШІ та браузери з агентами

Другий підхід — вбудувати агента безпосередньо в браузер.

Розширення, зокрема Claude in Chrome, можуть читати сторінки, перемикати вкладки, натискати кнопки й виконувати багатокрокові завдання. Для цього потрібні широкі дозволи — зокрема на сценарії, доступ до вкладок і API налагодження. Вони забезпечують потрібну функціональність, але водночас розширюють доступ розширення.

Браузери з вбудованими агентами, як-от Perplexity Comet і ChatGPT Desktop, інтегрують ШІ безпосередньо в роботу з вебсторінками. На такі можливості можуть не поширюватися дозволи для розширень, тож наявні засоби контролю розширень можуть бути неефективними.

Без повного переліку браузерів на пристроях у вашій організації може бути складно зрозуміти, які агенти там працюють. Особливо важливі два ризики.

Агенти діють від імені користувача. Коли агент завантажує документ або змінює налаштування внутрішнього застосунку, той бачить автентифікованого користувача, який виконує дозволену дію.

Без додаткових даних ні застосунок, ні його журнали аудиту можуть не відрізнити дії агента від дій працівника.

Агенти сприймають вміст як вхідні дані. Людина переглядає сторінку й сама її інтерпретує. Агент читає її та вирішує, що робити далі. Це створює ризик prompt injection: інструкції, вбудовані у вебсайти, документи або листи, можуть намагатися змінити поведінку агента.

У результаті програмне забезпечення інтерпретує недовірений вміст, маючи доступ, наданий довіреному користувачеві.

Коли ШІ-агент працює у вкладці з автентифікованим сеансом, засоби захисту кінцевих пристроїв і мережі не бачать, що саме він читає та робить.

3. WebMCP: сайти надають агентам інструменти напряму

Третій підхід змінює спосіб взаємодії сайтів з агентами.

WebMCP — новий вебстандарт, який розробляє група спільноти W3C Web Machine Learning за участю Google і Microsoft. Замість того щоб інтерпретувати сторінки й імітувати натискання, агенти можуть викликати структуровані інструменти, які надають самі сайти.

Наприклад, замість переходу на портал підтримки й заповнення форм агент міг би викликати інструмент для створення заявки. У 2026 році Chrome представив ранню попередню версію цієї можливості, а специфікацію й далі розвивають.

Такий підхід створює нову проблему довіри: сайти не лише показують вміст, а й визначають дії, доступні агентам.

Назви й описи інструментів, а також схеми їхніх вхідних даних впливають на те, які інструменти агент викликає. Ці визначення надходять із сайту, тому не слід вважати їх довіреними інструкціями. Зламаний або зловмисний сайт може використати оманливі описи чи функції, щоб вплинути на поведінку агента.

Кожен інструмент працює в контексті безпеки свого сайту, але агент, який взаємодіє з кількома сайтами, може переносити інформацію між ними. Важливо враховувати не лише те, що робить інструмент, а й те, які дані агент передає під час його виклику.

Варто з’ясувати: які корпоративні дані агенти можуть передавати інструментам сайтів, куди ці дані потрапляють і чи можете ви контролювати, якими інструментами вони користуються?

Що це означає для безпеки браузера

Усі три підходи мають спільну рису: програмне забезпечення взаємодіє із сайтами, використовуючи доступ, пов’язаний із браузерним сеансом користувача.

Тому безпека браузера більше не може виходити з припущення, що за кожним натисканням стоїть людина. Засоби контролю кінцевих пристроїв, мережі та застосунків залишаються важливими. Однак їх створювали для відстеження процесів, трафіку й входів у систему, а не того, що агент читає, вирішує та робить у вкладці з автентифікованим сеансом. Саме тут залишається прогалина.

Мета — не заборонити працівникам користуватися ШІ-агентами. Вони ставатимуть звичною частиною роботи. Завдання — переконатися, що засоби контролю, які вже діють у браузері, продовжують працювати, коли ним керує агент.

Нагадаємо, ШІ-агенти можуть аналізувати запити з урахуванням контексту й адаптувати відповіді до перебігу розмови. Докладніше — про те, як працюють автономні агенти та які бувають їхні типи.