Cloud Browser: Безпечна віддалена платформа браузера для будь-якого AI-агента
Проєкт-зразок нейтрального за моделлю сервісу віддаленого браузера: шлюз, робочі процеси, пряма трансляція через WebRTC, схвалення, захист від SSRF, повторна трансляція та кожен параметр налаштувань.
Агенти ШІ вже досить добре вміють аналізувати веб-сторінки, проте керування справжнім браузером залишається складнішим, ніж здається. Натискання кнопок — це проста частина. Браузерний агент, на якого можна покластися, має підтримувати сесії активними, справлятися з випливаючими вікнами та перенаправленнями, розуміти динамічні інтерфейси, обробляти завантаження та завантажувати дані, дозволяти людині взяти керування на себе, захищати облікові дані, запитувати дозволу перед виконанням значущих кроків та після цього показувати, що насправді сталось.
Cloud Browser — це рішення для всієї цієї проблеми: самостійна служба виконання браузера, якій байдуже, яка модель знаходиться на іншому кінці.
Його можуть використовувати десктопний агент, асистент для кодування в командному рядку, клієнт MCP чи спеціальний додаток. У цьому сервісі зовсім немає LLM. Агент вирішує, що має відбутися, тоді як Cloud Browser відповідає за браузер, межі безпеки, виконання, реальний перегляд, історію доказів та очищення.
Це розділення є найважливішим архітектурним рішенням у системі. Якщо замінити агента, платформа браузера залишається незмінною. Якщо оновити працівника браузера, агент не потребує переписування. Політика безпеки функціонує однаково, незалежно від того, який клієнт використовується.
У наступному розглядаються архітектура, межі довіри, модель взаємодії та інженерні рішення, які перетворюють автоматизацію браузера на щось, що може використовуватися корпораціями.
Загальна картина
Агент ШІ керує віддаленим браузером, тоді як людина може спостерігати, втрутитися, схвалити конфіденційні дії, переглядати скріншоти та пізніше повторити завдання. Основний алгоритм роботи навмисно простий:
User
|
v
AI agent or agent application
|
| HTTPS API or MCP
v
Cloud Browser gateway
|
v
Isolated browser worker
|
v
Website
Людина спостерігає та керує працівником через підписаний прямий екран WebRTC.
Чому Playwright недостатній
Playwright — це чудовий двигун автоматизації, але це не продукт браузера для кількох користувачів. Продакшн-сервіс мусить відповідати на багато запитань, яких Playwright ніколи не ставить:
- Хто є власником певного браузера?
- Яке завдання відповідає за певну вкладку?
- Чи може другий агент повторно використати ідентифікатор вкладки, який йому не надавали?
- Що відбувається, коли відбувається клік, але відповідь мережі зникає?
- Як хтось може увійти, не передаючи пароль до моделі?
- Що заважає браузеру отримати доступ до кінцевих точок метаданих у хмарі чи приватних мереж?
- Хто контролює ситуацію, коли одночасно підключені агент та людина?
- Як безпечно зберігати та завантажувати скріншоти?
- Які докази залишаються, коли дія провалюється?
Обмеження роботи двигуна чіткими межами обслуговування дозволяє платформі щоразу відповідати на всі ці запитання однаково.
Виконання без планування
Сервіс виконує запити та не планує їх. Він не буде самостійно вирішувати, чи слід здійснити покупку або надіслати повідомлення. Це забезпечує його корисність у різних агентах та чітко розділяє два набори обов’язків.
З боку агента:
- зрозуміти, чого хоче користувач
- визначити наступний крок
- інтерпретувати те, що наразі відображає браузер
- запитати користувача, якщо намір не зрозумілий
З боку хмарного браузера:
- автентифікувати того, хто звертається
- ізолювати сеанси та вкладки один від одного
- забезпечувати дотримання політики браузера
- перевіряти кожну ціль
- виконувати дії
Цілі та застарілі посилання
Бажаними цілями є семантичні елементи: кнопка, поле введення тексту, прапорець, елемент меню чи вузол доступності, які видно у поточному документі. Додатки на основі Canvas та сильно налаштовані інтерфейси все ще потребують координат, які є менш стабільними. У такому випадку Cloud Browser перевіряє місцезнаходження та надає деталі про елемент, який фактично знаходиться під вказівником.
Агент також може вказати роль чи видимий текст, які він очікує. Якщо елемент у цілі не відповідає, дія провалюється без виконання небажаних дій.
Сторінки постійно змінюються. Модальне вікно може з’явитися між спостереженням та дією, навігація може замінити весь документ, а поп-ап може стати активним продовженням. Щоб впоратися з цим, семантичні посилання прив’язуються до конкретної версії документа. Будь-яка зміна чи навігація усувають чинність попередніх посилань, а спроба використати старе призводить до помилки stale_target. У результаті утворюється безпечний цикл:
Observe -> choose one action -> validate -> execute -> observe again
Де знаходяться правила
Схвалення та мережеві правила не можуть знаходитися лише в одному інтерфейсі користувача, адже інший клієнт може під’єднатися безпосередньо та проігнорувати їх. Шлюз є авторитетною точкою застосування цих правил. Додатки-агенти можуть додавати ще більш суворі правила, але жоден з них не може послабити власні правила сервісу.
Архітектура системи
У зразковій реалізації є три основні пакети разом із деякими допоміжними сервісами.
Agent clients
|
+-- Desktop agent UI
+-- Claude or another MCP client
+-- Codex or another coding agent
+-- Custom application or SDK
|
v
MCP adapter or direct HTTPS client
|
v
Cloud Browser gateway
|
+-- authentication and delegated identity
+-- tenant and task isolation
+-- request validation
+-- idempotency
+-- policy and approvals
+-- session manager
+-- signed live-view service
+-- audit and observability
|
v
Worker scheduler
|
v
Browser worker
|
+-- Playwright and restricted CDP
+-- tabs and popups
+-- semantic state
+-- browser actions
+-- screenshots and artifacts
+-- downloads and uploads
+-- WebRTC video source
+-- secure form filling
|
v
Approved web destinations
Шлюз
Шлюз надає версійований контракт HTTPS. Він автентифікує звернулася сторону, визначає фактичну ідентичність користувача, перевіряє право власності на завдання, застосовує квоти, забезпечує дотримання політики та передає команду відповідному працівнику. Команди передаються у взаємопов’язаній оболонці, яка містить версію протоколу, ідентифікатор запиту, ідентифікатор завдання, необов’язковий ідентифікатор сеансу, назву команди та обмежені параметри. Команди, які змінюють стан, також потребують ключа ідемпотентності.
Результати та помилки повертаються у структурованому вигляді. Внутрішні деталі браузера не повинні витікати через випадкові записи стеку або прямі збої постачальника.
Адаптер MCP
Агенти, які підтримують MCP, під’єднуються через спеціальний простий адаптер. Chromium ніколи не запускається всередині нього, і він не містить жодних політик браузера. Його єдиною функцією є перетворення викликів інструментів на запити до шлюзу: відкриття вкладки (browser_open_tab), читання стану, натискання кнопок, зроблення скріншота чи завершення сеансу за допомогою відповідних інструментів типу browser_*. Таким чином кілька продуктів-агентів можуть ділитися одним шлюзом, і жодні елементи, специфічні для певного постачальника, не потрапляють у робочий процес.
URL-адреси з підписом для прямого перегляду блокуються адаптером від моделі. Агент отримує лише безневинні дані для відображення: чи існує прямий перегляд, яку вкладку він показує, хто має контроль та коли він закінчується. Лише надійний інтерфейс користувача отримує можливість прямого перегляду з підписом.
Робочий процес браузера
Кожен працівник керує реальним процесом чи контекстом браузера. Вкладки, навігація, семантична обробка даних, введення інформації, зйомка екрану, завантаження та завантаження файлів, робота з буфером обміну, діалогові вікна та події браузера — усе проходить через нього. Playwright виконує більшу частину автоматизації, а деякі операції лише для читання можуть активувати обмежені функції CDP. Відкритий доступ до CDP ніколи не надається як універсальне рішення.
Це обмеження має значення, оскільки необроблений CDP може отримати доступ до кукі, сховища даних, об’єктів для налагодження, дозволяти довільну обробку даних та доступ до внутрішніх компонентів браузера. Безпечний продукт надає лише ті функції, які необхідні для виконання завдання.
Менеджер сеансів
Менеджер сеансів контролює ланцюг авторитету:
tenant
-> principal
-> task
-> session
-> tab
-> operation
Непрозорі ідентифікатори є обмеженими цим ланцюгом. Ідентифікатор вкладки, виданий для одного завдання, не може використовуватися іншим завданням, навіть якщо обидва випадково користуються одним процесом браузера. Менеджер також керує лізингом, таймаутами бездіяльності, станом керування, збереженими вкладками, життєвим циклом профілю та його завершенням.
Профілі браузера та їхнє збереження
Існують три типи профілів. Тимчасовий профіль існує протягом короткочасної сесії та зникає після завершення завдання, що забезпечує найсильнішу ізоляцію за замовчуванням. Профіль завдання існує протягом одного завдання та залишається окремим від усіх інших завдань. Перманентний профіль дозволяє одному користувачеві зберігати куки та сесії веб-сайтів після завершення одного завдання для наступного.
Chrome дозволяє лише один активний процес на кожен каталог профілю, тому завдання, якими керує одна й та сама особа, можуть користуватися спільним процесом браузера, причому кожне завдання зберігає власні вкладки, вибрані елементи, активні фрейми, стан буфера обміну та параметри керування.
Постійні профілі вимагають суворішого контролю їх функціонування:
- Каталог профілю може читатися лише його власником.
- Основний том чи сервіс зберігання має шифрувати дані у спокої.
- Користувачам потрібен спосіб виходу з облікового запису та стирання збереженого профілю.
- Доступ обмежується конкретним користувачем та об’єктом.
- Читання історії перегляду вимагає прямого схвалення.
- Роботи ніколи не повертають сирі куки чи токени автентифікації агенту.
Життєвий цикл однієї команди
Кожна дія проходить через однакову передбачувану послідовність:
- Користувач сервісу автентифікується.
Коли виникає проблема з передачею даних після того, як браузер вже міг виконати дію, шлюз відповідає значенням outcome_unconfirmed. Тоді клієнту доводиться узгодити поточний стан браузера, замість того щоб сліпо повторювати цей крок. Це особливо важливо під час бронювання, надсилання форми чи повідомлення, адже автоматична спроба може призвести до дублювання дій у реальному світі.
Інтерактивний прямий перегляд через WebRTC
Важко довіряти хмарному браузеру, який ніхто не може бачити, тому Cloud Browser забезпечує інтерактивний прямий перегляд через WebRTC. Відео передається у вигляді медіаканалу, тоді як події, пов’язані з вказівником, клавіатурою, буфером обміну, статусом, схваленням та передачею контролю, надсилаються через упорядкований канал DataChannel. HTTP використовується лише для сигналізації типу „пропозиція-відповідь“, і не існує додаткового потоку зображень через WebSocket.
Надсилання скріншотів через протокол агента знову та знову було б повільнішим, тому маршрут WebRTC зменшує затримку та дозволяє швидкій взаємодії уникати звичайних відповідей інструменту. Координати вказівника відображаються в межах всього відео, включаючи смуги «letterbox». Події колеса миші нормалізуються та об’єднуються, швидкі клавіші відповідають платформі переглядача, а підтвердження дозволяють розрізнити запущені, доставлені, змінені, відхилені та все ще у процесі обробки вхідні дані.
Обмін контролем
Переглядач починає роботу в режимі спостереження, поки контроль знаходиться у агента. Користувач може отримати контроль, натиснувши на поверхню браузера або кнопку керування. Машина станів є чітко визначеною:
Agent control
-> handoff pending
-> user control
-> release pending
-> agent control
Any state
-> finalized
Хоча користувач зберігає контроль, вхідні дані агента блокуються. Контроль обмежується конкретним завданням та діє згідно з вибраним вікном, якщо сайт відкриває нове вікно. Старий кадр відео не може надати контроль, а затримане повідомлення не може тихо повернути його агенту, оскільки шлюз залишається авторитетом щодо поточного стану.
Захист самого переглядача
Посилання на пряму трансляцію — це короткочасна можливість, підписана HMAC та прив’язана до одного користувача, суб’єкта, завдання, сеансу та вкладки; вона припиняє свою дію після завершення завдання. Функція формування кадрів вимкнена за замовчуванням. Щоб вбудувати переглядач у надійний додаток агента, процес розгортання вказує кожен точний джерело у своїй політиці безпеки контенту; замінники, шляхи, облікові дані, запити та фрагменти відхиляються як джерела для формування кадрів.
Усе це запобігає ситуації, коли ворожий веб-сайт вбудовує програвач, створює невидимий шар зверху та обманом змушує користувача натиснути кнопки на кшталт „Взяти під контроль“ чи „Схвалити“.
Безпечний вхід
Пароль ніколи не повинен повертатися до моделі, потрапляти до часової шкали дій чи опинятися у журналі аудиту. Два способи входу допомагають дотриматися цієї умови.
Один із способів — це ручний контроль: агент передає браузер користувачеві, який входить у систему безпосередньо на сайті, а потім контроль знову повертається до агента.
Інший підхід — це спеціалізоване запитання для безпечної аутентифікації. У цьому випадку працівник знаходить конкретні видимі поля в поточному документі, а надійний переглядач відображає зашифровану форму з обліковими даними з вказанням точного походження призначення. Те, що вводить користувач, надсилається безпосередньо в сервіс заповнення форм та потрапляє у перевірені поля браузера. Запит прив’язується до походження, завдання, сеансу та вкладки, процесу створення документа, шляху до фрейму, селектора, очікуваного типу поля та короткого терміну дії. Модель бачить лише невразливі деталі статусу.
Входження через QR-код також можна здійснювати безпечно. Працівник фіксує видиме зображення QR-коду, підтверджує його можливість декодування, видаляє розшифрований контент та відображає зображення лише у захищеному прямому переглядачі. Значення, яке містить QR-код, ніколи не потрапляє до агента.
Схвалення перед виконанням значущих дій
Дозвіл на вхід на веб-сайт та дозвіл на виконання певної дії там — це окремі рішення. Дозвіл агенту відкрити сторінку ресторану не означає авторизацію на бронювання, а доступ до інтернет-магазину — авторизацію на покупку. Cloud Browser оцінює ризик під час виконання дії. Для таких дій може знадобитися схвалення:
- бронювання столика чи зустрічі
- покупка чого-небудь або оплата
- редагування облікових записів чи дозволів
- видалення будь-чого
- надсилання повідомлень від імені користувача
- зберігання облікових даних
- завантаження файлів
- надання дозволів браузеру
- надсилання конфіденційних даних
Кожне схвалення прив’язується до однієї конкретної дії, цілі, місця призначення, документа та набору категорій даних, тому воно стає недієздатним після зміни сторінки або при використанні іншої кнопки. Надсилання конфіденційних даних оцінюється окремо, незалежно від кінцевої дії. Введення електронної адреси у форму сторонньої організації може вимагати схвалення, прив’язаного до цього місця призначення, перш ніж кнопка „Надіслати“ запитає про окреме підтвердження. Користувач залишається тим, хто схвалює; Cloud Browser забезпечує дотримання правил, а додаток-агент формулює рішення.
Скріншоти, артефакти та повторна відтворення
Скріншоти допомагають швидко зрозуміти ситуацію, створюють постійні докази та дозволяють діагностувати проблеми. Функція збереження скріншота повертає зображення для негайного перегляду та ідентифікатор артефакта, причому жоден шлях до файлової системи сервера не потрапляє до агента. Артефакти належать відповідному завданню, швидко закінчують свою дію, мають обмеження за розміром та кількістю, надходять через підписані маршрути, можуть завантажуватися лише у налаштовані локальні каталоги та створюються з правами лише власника без можливості перезапису існуючих файлів.
Успішне переглядання веб-сторінок також дозволяє створювати часову шкалу скріншотів. Кожен запис містить час створення, ім’я хоста, джерело, короткий опис дії та необов’язковий артефакт у вигляді скріншота. Слайдер дозволяє користувачеві переглянути попередній стан браузера, а вибір опції LIVE повертає до поточної сесії WebRTC.
Критично важливі дії отримують спеціальне оброблення. Введення облікових даних ніколи не фіксується, а коли якась дія передає конфіденційну інформацію, хронологія може зберігати лише мінімальну кількість метаданих, навмисно не включаючи скріншот.
Функція повторного відтворення йде далі за межі візуальної зручності, адже вона дає відповіді на практичні запитання:
- Що було на екрані у агента безпосередньо перед кліком?
- Чи з’являвся якийсь поп-ап протягом цього процесу?
- Чи міг якийсь інший елемент знаходитися поверх цілі?
- Чи щось на сторінці змінилося після цього?
- Чи зависла задача на сайті чи чекала на схвалення користувача?
Поп-апи, перенаправлення та незручні сторінки
Реальні робочі процеси рідко залишаються в одній вкладці. Процес бронювання може відкрити поп-ап, постачальник ідентифікації може працювати через кілька джерел, офісний документ може намагатися запустити десктопний додаток, а сторінка зустрічі може пропонувати як посилання на додаток, так і веб-альтернативу. Cloud Browser розглядає такі переходи як події першого класу.
Якщо певна дія відкриває вікно, платформа повідомляє про нову вкладку, обирає її для виконання завдання та під’єднує до живого перегляду; коли контроль переходить до користувача, він також керує нею. Якщо сторінка намагається запустити нативний протокол, наприклад додаток для зустрічей, браузер повідомляє про те, що зовнішній додаток недоступний, замість того щоб вдаєти успішний клік. Якщо на сайті є безпечна веб-альтернатива, агент чи користувач можуть навмисно обрати її.
Ніщо в цій платформі не дозволяє обійти CAPTCHА, захисні вікна браузера, платні бар’єри, вимоги до довіри пристрою чи подібні механізми захисту. Коли вони з’являються, це фіксується як обмеження або передається користувачеві для рішення.
Безпека мережі та SSRF
Оскільки віддалений браузер також є клієнтом мережі, неконтрольоване навігування може зробити його інструментом SSRF. Місця призначення деталізуються та перевіряються перед підключенням. За замовчуванням такі запити блокуються:
- цілі типу loopback
- цілі типу link-local
- сервіс метаданих хмари
- приватні діапазони у стилі RFC1918
- простір для мультикасту та інші зарезервовані діапазони
- будь-які схеми URL, що не належать до підтримуваних
Списки дозволів та заборон для окремих користувачів можуть ще більше посилити цей захист.
Деякі корпоративні системи використовують розділений DNS або захищені веб-шлюзи, які спрямовують схвалені внутрішні імена хостів на приватні чи високоякісні адреси NAT. Такі винятки мають бути чітко визначені, обмежені лише надійними доменами та налаштовані через конфігурацію розгортання, щоб відповідне ім’я хоста ніколи не стало загальним шляхом до приватної мережі. Перенаправлення, вікна-спливи, іфрейми, запити service-worker та перепідключення DNS залишаються під дією однакової мережевої політики, оскільки перевірка лише першої URL є недостатньою.
Вставка команд та ненадійний вміст сторінки
Робочий процес браузера розглядає вміст сторінки як дані, а не як інструкції. Сторінка може відображати текст „Ігноруйте ваші попередні інструкції“ чи публікувати опис інструменту, у якому стверджується, що певна операція є безпечною, проте жодне з цих тверджень не надає жодних повноважень.
Інструменти, які сторінка рекламує через WebMCP, прив’язані до URL сторінки, процесу генерації документа, ідентифікатора реєстрації та спостережуваної схеми, і їхні описи ніколи не вважаються надійними. Параметр readOnlyHint, наданий сторінкою, не дозволяє оминути процедуру схвалення, якщо лише розгортання не надало прямого довір’я саме цьому джерелу з цією метою. Семантичні знімки дотримуються того ж правила: розуміння контенту залежить від агента, але надання повноважень браузеру — виключно від шлюза.
Завантаження, завантаження та буфер обміну
Завантажені файли зберігаються як об’єкти, що належать конкретному завданню, тому шлях до працівника не розкривається. Для завантаження потрібен вибірник файлів, прив’язаний до певної події, та шлях джерела всередині налаштованої кореневої директорії завантажень. Символічні посилання обробляються, і їх використання відхиляється, якщо вони вказують на місця поза схваленою директорією; крім того, перед встановленням файлів працівник перевіряє, чи вибірник обирає один файл чи кілька.
Кожне завдання має власний стан буфера обміну. Текст та обмежені бінарні елементи MIME можуть синхронізуватися через прямий переглядач; дозволи браузера надаються обмежено та скасовуються після цього. У постійному контексті браузера дозвіл на використання буфера обміну, наданий одному завданню, не повинен залишатися активним для іншого.
Життєвий цикл та очищення
Очищення має відбуватися навіть у разі, якщо агент так і не завершить свою роботу коректно. Сервіс отримує чіткий сигнал про кінець етапу, який визначає, чи був етап завершений, перерваний, зупинений чи зупинений підагентом, а запущене ним очищення є обмеженим та ідемпотентним. Кожна вкладка може мати один із трьох статусів:
- активна вкладка, яка закривається після завершення етапу
- результат роботи, який зберігається для користувача
- завдання, залишене відкритим для подальшої роботи користувачем
Статуси, прив’язані до конкретного етапу, скасовуються одразу після виконання відповідних дій, тому вкладку необхідно навмисно зберегти знову у наступному етапі. Додаткові процедури очищення включають закінчення терміну дії сеансу, таймаути бездіяльності, закінчення терміну дії даних, очищення „сирітських“ профілів та плавне закриття шлюзу.
Можливість спостереження без витоку приватних даних
Журнали шлюза фіксують операційні події, що стосуються створення сеансів, навігації, прийняття рішень за правилами, передачі керування, змін, збоїв та очищення даних. Запис аудиту має містити ідентифікатори та результати, а не облікові дані чи вміст сторінок. URL-адреси, де це можливо, скорочуються до безпечних частин, а запити, значення форм, паролі, токени та персональні дані маскуються або видаляються.
Корисні операційні сигнали включають:
- затримку в шлюзі та у працівниках
- кількість існуючих сеансів та браузерів
- підключені партнери WebRTC
- категорії відмов у дотриманні правил
- частоту старіння цілей
- результати, які залишилися непідтвердженими
- працівники, які не запускаються
- чи успішні з’єднання в режимі прямої трансляції
- створені та закінчені термін дії артефактів
- невдалі операції очищення
Користувач повідомляє, коли відео насправді переходить у стан відтворення, адже просте створення підписаної URL не доводить, що користувач може щось бачити.
Надійність та тестування на навантаження
Найнеприємніші збої в автоматизації браузера — це ті, які проявляються без жодних ознак: клік, який нічого не змінив, дані, введені двічі, поп-ап, якого ніхто не бачив, або дія, що повторюється після закінчення тайм-ауту. Тому серйозний набір тестів охоплює значно більше, ніж просте відтворення стандартного сценарію. Cloud Browser тестує саме ці аспекти:
- багато користувачів та сеансів одночасно
- розділення завдань та результатів їх виконання
- мутації, які мають бути ідемпотентними
- посилання на застарілі документи
- обробка поп-апів
- цілі всередині iframes та shadow roots
- поновлення з’єднань через WebRTC
- конфлікти під час зміни керування
- сторінки, які зайняті або тимчасово зависають
Тести на навантаження мають поєднувати справжні процеси Chromium із кількома програвачами WebRTC одночасно. Юніт-тести добре охоплюють логіку правил та протоколу, але конфлікти під час запуску браузера, стрімінгу відео, фокусування, вибору поп-апів та передачі даних вводу проявляються лише за реалістичного навантаження.
Модель розгортання
Референтна архітектура може працювати як один вузол, хоча її інтерфейси призначені для більшої системи керування виробництвом. Базове розгортання поєднує ці елементи:
TLS ingress
-> Cloud Browser gateway
-> isolated browser workers
-> encrypted profile and artifact volume
Браузер має працювати від імені користувача без особливих привілеїв у відповідному профілі seccomp, з обмеженими ресурсами CPU та пам’яті, а також достатньою кількістю спільної пам’яті для Chromium. Контейнери є практичним початком, а у середовищах з високим ризиком можуть обирати по одній мікро-ВМ на кожного працівника браузера для кращої ізоляції.
У корпоративних розгортаннях зазвичай додають:
- Механізм входу OIDC для самостійної консолі
- Аутентифікацію від машини до машини для агентів
- Ідентифікацію кінцевого користувача, яку передають надійні бекенди
- Redis для зберігання розподілених токенів доступу та ключів ідемпотентності
- PostgreSQL або спеціалізовану платформу для аудиту подій
- Шифроване сховище даних для артефактів
- Запланувальник, який розміщує працівників
- Сервери TURN, які видають тимчасові креденції WebRTC
- Менеджер секретів із можливістю їх обміну
- Регіональне маршрутизування та контроль резиденції даних
До шлюзу має бути можливий доступ ззовні лише через HTTPS. Звичайний HTTP підходить лише для розробки в режимі локального обміну даними.
Конфігурація, елемент за елементом
Файл env визначає мережеву ідентичність шлюзу, поведінку браузера, параметри зберігання, рівень ізоляції та межі політики. Його слід розглядати як конфігурацію для розгортання, а не як вихідний код додатку. Наведений нижче приклад можна безпечно показувати, оскільки його значення є ілюстративними та не містять реальних токенів чи секретів підпису:
CB_HOST=127.0.0.1
CB_PORT=8787
CB_PUBLIC_URL=http://127.0.0.1:8787
CB_TOKENS=replace-with-a-long-random-token:tenant-example:agent-service:delegate
CB_MAX_SESSIONS_PER_PRINCIPAL=8
CB_LIVEVIEW_SECRET=replace-with-a-separate-random-signing-secret
CB_LIVEVIEW_FRAME_ANCESTORS=http://localhost:8088,http://127.0.0.1:8088
CB_HEADLESS=true
CB_SERVICE_WORKERS=allow
CB_BROWSER_CHANNEL=chrome
CB_EXTENSION_PATHS=
CB_PROFILE_MODE=persistent
CB_PROFILE_DIR=./var/profiles
CB_ARTIFACT_DIR=./var/artifacts
CB_AUDIT_FILE=./var/audit.log
CB_USER_AGENT=
CB_ALLOW_ORIGINS=
CB_BLOCK_ORIGINS=
CB_TRUSTED_PRIVATE_ORIGINS=*.company.example
CB_ALLOW_CGNAT_NAVIGATION=true
CB_REQUIRE_APPROVAL=false
CB_ALLOW_LOOPBACK_NAVIGATION=true
CB_SYNTHETIC_MEDIA_DEVICES=true
CB_HOST
Це мережевий інтерфейс, на якому прослуховує шлюз.
CB_HOST=127.0.0.1
З використанням 127.0.0.1 сервіс відповідає лише локальній машині, що є найбезпечнішим варіантом під час розробки з інтерфейсом агента, адаптером MCP та шлюзом на одному комп’ютері. Контейнеру може знадобитися 0.0.0.0, щоб його мережа або проксі для входу могли під’єднатися, але це не є причиною публікувати порт у Інтернеті; шлюзи в промисловому середовищі залишаються за захистом автентифікованого TLS, правил брандмауера та авторизації на рівні сервісу. Також зазначимо, що CB_HOST визначає місце, де прослуховує процес, а не URL-адреси у посиланнях для прямого перегляду, якими керує CB_PUBLIC_URL.
CB_PORT
Це TCP-порт, який використовує шлюз.
CB_PORT=8787
Будь-яке число від 1 до 65535 підходить, а значення за замовчуванням у розробці — 8787. Цей порт не повинен використовуватися на обраному інтерфейсі. Якщо зворотний проксі чи контейнер використовує інший зовнішній порт, CB_PORT залишається внутрішнім портом прослуховування, тоді як CB_PUBLIC_URL вказує адресу, яку бачать ззовні.
CB_PUBLIC_URL
Публічна базова URL — це та адреса, яку використовує шлюз для створення підписаних посилань на пряму трансляцію.
CB_PUBLIC_URL=http://127.0.0.1:8787
Це більше, ніж просто мітка, адже інтерфейс користувача отримує можливості переглядача, які походять від неї, тому до неї має бути можливість отримати доступ з браузера, який відображає прямий перегляд. Локальна розробка підтримує HTTP з поверненням до самого себе:
CB_PUBLIC_URL=http://127.0.0.1:8787
Для віддаленої розгортки потрібен HTTPS-сервер, доступний ззовні:
CB_PUBLIC_URL=https://browser.example.com
Не включайте до цього URL шляхи, запити, імена користувачів, паролі та інші конфіденційні дані, а також припиніть використання протоколу TLS на надійному вході чи безпосередньо біля шлюза. Ще одна підступність: 127.0.0.1 завжди означає машину, на якій ви знаходитеся. Припустимо, інтерфейс агента працює на ноутбуці, а шлюз розташований на сервері в іншому місці. Посилання, створене з використанням 127.0.0.1, буде вести назад до ноутбука та ніколи не дістанеться до шлюза.
CB_TOKENS
Ця змінна містить список облікових даних сервісу, які приймає шлюз. Кожен запис виконується за одним форматом:
<bearer-token>:<tenant-id>:<service-principal>[:scope]
Довірені облікові дані серверного бекенду виглядають так:
CB_TOKENS=replace-with-a-long-random-token:tenant-example:agent-service:delegate
Коми розділяють кілька записів. Перше поле — це токен-носій, який надходить у заголовку HTTP Authorization; його довжина має становити щонайменше 20 символів, його потрібно генерувати за допомогою криптографічно безпечного випадкового джерела та зберігати у менеджері секретів. ID орендаря є найзовнішнішою межею ізоляції, тому сесії, завдання, профілі, вкладки та артефакти ніколи її не перетинають. Ім’я принципала вказує сервіс, який тримає облікові дані, і без делегування сесії працюють під цим принципалом.
Необов’язковий діапазон delegate дозволяє надійному бекенду надсилати заголовок X-Cloud-Browser-Principal із назвою справжнього кінцевого користувача. Сесія тоді належить цьому користувачеві, тоді як журнал аудиту окремо фіксує, який бекенд діяв від його імені. Право на делегування мають лише надійні серверні додатки. Десктопний клієнт чи звичайний токен користувача не повинні мати такого права, оскільки інакше вони можуть претендувати на ідентичність іншого користувача в межах тенанта.
Як налаштовані, так і представлені токени піддаються хешируванню перед порівнянням у постійному часі, що зменшує ризик витоку інформації через довжину токена, але не робить витягнутий токен безпечним. Негайно замініть токен, якщо він з’явився у скріншоті, репозиторії, записі терміналу чи заявці на підтримку. Також не використовуйте його знову як CB_LIVEVIEW_SECRET, оскільки ці два елементи захищають різні функції та потребують окремого створення.
CB_MAX_SESSIONS_PER_PRINCIPAL
Це встановлює максимальну кількість одночасних сеансів, які може мати один активний користувач.
CB_MAX_SESSIONS_PER_PRINCIPAL=8
Допустимі значення коливаються від 1 до 128, з значенням за замовчуванням 8. Цей ліміт захищає від випадкових навантажень браузера та неконтрольованих агентів, а також запобігає тому, щоб один користувач вичерпав загальну пропускну здатність; він діє разом із лімітом сеансів на рівні шлюзу. Оптимальне значення залежить від об’єму пам’яті працівника, потужності CPU, режиму профілю та очікуваного рівня одночасності. Навіть якщо постійний профіль використовує спільний процес браузера для виконання завдань користувача, кожне завдання все одно споживає ресурси табу, стрімінгу, артефактів та шлюзу.
CB_LIVEVIEW_SECRET
Це ключ HMAC, який підписує функції живого перегляду.
CB_LIVEVIEW_SECRET=replace-with-a-separate-random-signing-secret
Кожен елемент підписаного токена (tenant, principal, task, session, tab, expiry) покривається підписом, тому зміна будь-якого з них робить його недійсним. Для розгортання, до якого можна отримати доступ ззовні, потрібен власний секрет довжиною 32 символи або більше; на практиці це означає принаймні 32 випадкові байти у форматі hex або Base64, завантажені з менеджера секретів. Витік секрету дозволить зловмиснику з достатньою кількістю метаданих сеансу підробити функції переглядача. Перезапуск секрету робить недійсними нещодавно перевірені підписи, створені за допомогою старого ключа, тому його потрібно синхронізувати з терміном закінчення сеансу живого перегляду. Тримайте це значення подалі від агентів, сторінок браузера, пакетів клієнта, журналів та репозиторіїв.
CB_LIVEVIEW_FRAME_ANCESTORS
Цей параметр визначає, які надійні веб-додатки можуть вбудовувати підписаний переглядач у iframe.
CB_LIVEVIEW_FRAME_ANCESTORS=http://localhost:8088,http://127.0.0.1:8088
Гейтвей перетворює цей список на директиву frame-ancestors у політиці безпеки вмісту браузера. Якщо значення порожнє, браузер надсилає frame-ancestors 'none' та X-Frame-Options: DENY, тож сторінка працює як окрема, але не дозволяє вбудовування. Якщо вказано конкретні джерела, лише ці саме можуть використовувати її у форматі фрейму, а X-Frame-Options: DENY не використовується, оскільки цей старіший заголовок не може вказувати кілька джерел та суперечитиме списку дозволених.
Вказані значення мають бути точними HTTP або HTTPS-джерелами; шляхи, облікові дані URL, запити, фрагменти та вайлдкарти відхиляються. Схема, хост та порт також мають значення, тому наступні три є різними джерелами:
http://localhost:8088
http://127.0.0.1:8088
https://agent.example.com
Це налаштування не стосується CORS. Воно захищає потужну сторінку переглядача від clickjacking, тому вкажіть лише ті інтерфейси, яким дійсно потрібно відображати живий браузер.
CB_HEADLESS
Це визначає, чи запускає працівник браузер без вбудованого вікна робочого столу.
CB_HEADLESS=true
Якщо встановлено true, Chromium або Chrome працює без графічного інтерфейсу, і користувачі спостерігають та керують процесом через пряму трансляцію WebRTC, а не через локальне вікно Chrome. Сервери та контейнери зазвичай потребують саме цього, оскільки це дозволяє економити ресурси комп’ютера та забезпечує автоматизацію незалежно від нативної сесії відображення. Якщо встановлено false, браузер запускається з графічним інтерфейсом та потребує функціонального дисплея — зазвичай віртуального, як-от Xvfb, або образу для стрімінгу робочого столу в Linux; у macOS він відкриває окреме вікно браузера, якщо тільки архітектура працівника не відрізняється. Зміна цього параметра ніколи не змушує Cloud Browser перебрати керування вже відкритим особистим вікном Chrome. Вона впливає лише на те, як запускається власний керований браузер працівника.
CB_SERVICE_WORKERS
Цей параметр визначає, чи можуть веб-сайти реєструвати та запускати сервісних працівників.
CB_SERVICE_WORKERS=allow
Виберіть allow або block; block є безпечним стандартним варіантом. Прогресивні веб-додатки, додатки для зустрічей, офісні програми та сайти з інтенсивним кешуванням часто залежать від сервісних працівників, і без них вони можуть не функціонувати, застрягти на екрані завантаження або виглядати замороженими. Увімкнення цих функцій покращує сумісність, але збільшує обсяг мережевих операцій та завдань щодо зберігання даних у браузері, тому спочатку переконайтеся, що запити сервісних працівників все ще дотримуються правил навігації, правил виходу, захисту від втрати даних та політики користувача. Виберіть allow для перевіреного додатку, який це потребує, але ніколи не використовуйте цей варіант як універсальне рішення.
CB_BROWSER_CHANNEL
Цей параметр дозволяє вибрати канал браузера, встановлений у системі, замість Chromium, вбудованого в Playwright.
CB_BROWSER_CHANNEL=chrome
Допускаються чотири канали: chrome, chrome-beta, chrome-dev та msedge. Якщо залишити це поле порожнім, буде використовуватися налаштований виконуваний файл Chromium або пакет Playwright. Справжні версії Chrome чи Edge іноді є необхідними, коли компанія перевіряє надійність пристрою, централізовано керує браузерами, впроваджує політики чи видає сертифікати клієнтам. Вибір chrome не завантажує звичайний профіль користувача Chrome, оскільки профілі все одно походять з CB_PROFILE_MODE та CB_PROFILE_DIR, тому Cloud Browser не може безшумно приєднатися до особистої інтерактивної сесії. Канал має бути встановлений на хості робочого процесу, а для надійності пристрою також можуть знадобитися відповідні профілі, реєстрація ОС, сертифікати, політики чи розширення; саме це налаштування не створює корпоративної надійності.
CB_EXTENSION_PATHS
Список каталогів розпакованих розширень браузера, розділений комами.
CB_EXTENSION_PATHS=
Залиште це порожнім, щоб не завантажувати розпаковані розширення. Вказані шляхи передаються керованому браузеру через прапорці завантаження розширень, що працює лише за умови CB_HEADLESS=false та значення CB_PROFILE_MODE як task або persistent; тимчасові контексти та звичайні безголові запуски не можуть безпечно підтримувати це. Завантаження розпакованих розширень призначене для розробки та контрольованих тестів. Компанії, що працюють у продакшені, повинні примусово встановлювати схвалені розширення через політику Chrome або Edge, фіксувати ідентифікатори та оновлювати джерела, а також перевіряти права доступу. Оскільки розширення працює з привілеями браузера та може спостерігати або змінювати веб-активність, його походження, шлях оновлення, права доступу та власник мають бути об’єктом перевірки безпеки.
CB_PROFILE_MODE
Цей параметр визначає, як ізолюється стан браузера та як довго зберігається стан входу.
CB_PROFILE_MODE=persistent
Режим може бути ephemeral, task або persistent. У режимі ephemeral створюється тимчасовий браузерний контекст без каталогу профілю, який можна було б використовувати знову, що забезпечує найсильнішу стандартну ізоляцію та підходить для анонімного серфінгу чи роботи, яка не має залишати слідів входу. У режимі task створюється каталог профілю лише для однієї задачі: куки та стан зберігаються протягом усього часу виконання задачі, а після її завершення профіль видаляється. У режимі persistent один профіль використовується для задач того самого користувача та ефективного принципала, тож куки та сеанси веб-сайтів зберігаються після завершення нових задач та перезапуску шлюзу, хоча кожна задача зберігає окреме володіння вкладками, обрану вкладку, буфер обміну, прямі трансляції, дані та контрольні лізинги. Режим persistent є найзручнішим, але водночас і найбільш ризикованим; слід використовувати зашифроване зберігання, суворі права доступу до каталогів, чіткі процедури виходу та очищення профілю, а також обмежений режим бездіяльності.
CB_PROFILE_DIR
Кореневий каталог, у якому зберігаються дані браузера, пов’язані з профілем.
CB_PROFILE_DIR=./var/profiles
Відносний шлях визначається відносно робочої директорії процесу шлюза. У контейнерах потрібно розмістити захищений об’єм саме тут, якщо профілі мають залишатися активними після заміни контейнера. Шлюз сам створює піддиректорії, специфічні для користувача та принципала, і ніколи не використовує шляхи до профілів, обрані агентами. Директорії мають бути доступними лише власнику та ніколи не повинні надаватися для завантаження. Не налаштовуйте цей параметр на профіль Chrome реальної особи; копіювання або одночасне відкриття активного профілю може пошкодити його та вразити працівника непов’язаними даними про перегляд.
CB_ARTIFACT_DIR
Місце, де зберігаються скріншоти, завантаження, експортований контент, зображення для повторного відтворення та інші обмежені артефакти, що належать завданню.
CB_ARTIFACT_DIR=./var/artifacts
Відносні шляхи знову визначаються від робочої директорії шлюза. Агенти отримують ідентифікатори об’єктів замість шляхів, і кожне завантаження перевіряє інформацію про користувача, основного суб’єкта, завдання, термін дії та власника. Зробіть директорію читабельною лише для облікового запису сервісу Cloud Browser, обмежте термін існування об’єктів, їх кількість та розмір, видаляйте закінчені терміном файли, зашифруйте дані на зберіганні та уникайте необмеженого зберігання тимчасових об’єктів у резервних копіях. Профілі та об’єкти мають різні призначення: скріншот може надійти користувачеві, тоді як профіль браузера ніколи не слід розглядати як об’єкт для завантаження.
CB_AUDIT_FILE
Шлях до обмеженого журналу аудиту у форматі JSON Lines.
CB_AUDIT_FILE=./var/audit.log
Кожен рядок — це структурована подія, пов’язана зі створенням сеансу, виконанням команди, відхиленням запиту, передачею керування, результатом підключення у режимі прямої трансляції, знищенням сеансу чи невдачею при очищенні даних. Фіксуйте, хто та що сталось, а не значення форм чи вміст сторінок; приховуйте або опускайте облікові дані, токени, запити та конфіденційні дані користувачів. У продакшні розглядайте локальний формат JSONL як формат для розробки чи передачі даних та надсилайте події на надійну платформу аудиту, яка забезпечує політику зберігання, контроль доступу, захист цілісності даних, сповіщення та розслідування з урахуванням особливостей користувачів.
CB_USER_AGENT
Необов’язкове значення для перевизначення рядка User-Agent браузера.
CB_USER_AGENT=
Краще залишити порожнім. Браузер створює звичайну ідентичність Chrome на основі версії браузера та надає відповідні підказки клієнту, уникаючи розбіжностей між заголовком запиту, navigator.userAgent та navigator.userAgentData. Самостійно введена рядок перевизначає лише User-Agent, без створення відповідних підказок, і деякі постачальники ідентичності та детектори ботів помічають цю розбіжність. Не використовуйте його для того, щоб представити старий браузер як новіший або обійти політику безпеки сайту; зберігайте його для задокументованої вимоги сумісності та перевіряйте повну ідентичність браузера пізніше.
CB_ALLOW_ORIGINS
Список дозволених доменів для навігації користувача.
CB_ALLOW_ORIGINS=
Якщо список порожній, дозволяються публічні HTTP та HTTPS-адреси, якщо тільки не втручається інша політика, тоді як адреси приватної мережі, метадани, локальні посилання, зарезервовані та непідтримувані адреси все одно проходять через механізм захисту мережі. Як тільки у списку з’являються записи, кожна навігація мусить відповідати принаймні одному правилу, сформульованому як точний початковий адресний рядок на кшталт https://portal.example.com, суфікс з маскою на кшталт *.example.com або просто ім’я хоста на кшталт portal.example.com. Якщо має значення протокол чи порт, слід використовувати точний початковий адресний рядок. Маска покриває основне ім’я хоста та його піддомени, тому варто бути обережними з їх використанням. Наявність у списку дозволених адрес не надає авторизації приватному IP-адресу, оскільки класифікація DNS та політика довірених приватних початкових адрес оцінюються окремо.
CB_BLOCK_ORIGINS
Явний список заборонених адрес для навігації.
CB_BLOCK_ORIGINS=
Правила використовують ті самі три формати, що й список дозволених адрес, і спочатку перевіряється саме цей список, тому все, що відповідає обом спискам, блокується. Типовими прикладами є конфіденційні кінцеві точки адміністрування, непідтримувані додатки, відомі небезпечні адреси чи піддомени, які необхідно виключити з більш широкого списку дозволених адрес. Класифікація мережі застосовується навіть у разі, якщо список порожній.
CB_TRUSTED_PRIVATE_ORIGINS
Назви корпоративних хостів, які можуть відповідати приватним чи CGNAT-адресам.
CB_TRUSTED_PRIVATE_ORIGINS=*.company.example
Причина його існування — це конфігурації split-DNS, де ім’я хоста схваленої компанії резолюється по-різному у VPN чи внутрішній мережі. Правила використовують синтаксис списку навігації. Обмежте їх доменами, які належать організації, та утримайтеся від додавання загальних замінників чи імен хостів лише через неправильну роботу певного додатку. Довірені значення можуть дозволяти цілі RFC1918 чи CGNAT, але ніколи не loopback, link-local, метадані хмари, multicast чи зарезервовані адреси. Розглядайте це як виняток SSRF; платформі потрібен контроль над DNS, вихідним трафіком та власністю кожного довіреного суфікса.
CB_ALLOW_CGNAT_NAVIGATION
Дозволяє навігацію до діапазону NAT класу оператора, 100.64.0.0/10.
CB_ALLOW_CGNAT_NAVIGATION=true
За замовчуванням значення — false. У деяких корпоративних мережах VPN або захищений веб-шлюз надає публічні чи внутрішні послуги за адресами у просторі CGNAT. Увімкнення цього параметра дозволяє це робити та може скасувати обмеження браузера щодо доступу до локальної мережі, які б блокували доступ до сторінки за синтетичною адресою. Це є більш широким підходом, ніж просте довіряння одному імені хоста, тож використовуйте CB_TRUSTED_PRIVATE_ORIGINS, якщо потрібні лише відомі корпоративні домени. Діапазони RFC1918, loopback, link-local, metadata, multicast та резервовані залишаються закритими, але можливості мережевого доступу все одно значно зростають, тому увімкніть його лише в контрольованому корпоративному середовищі.
CB_REQUIRE_APPROVAL
Увімкнює загальний механізм схвалення шлюза для команд, які класифікуються як значущі.
CB_REQUIRE_APPROVAL=false
З значенням true команди, що мають наслідки, затримуються до отримання точної згоди у момент виконання. З значенням false блокування знімається, що є розумним вибором, якщо довірена додаткова програма вже застосовує більш суворі правила. Однак безпека не вимикается. Визнані ризики, такі як передача конфіденційних даних, їх видалення, оплати, бронювання, повідомлення від імені когось, зміни облікових записів чи дозволів, доступ до історії та інструменти некласифікованих сторінок, все одно вимагають згоди. Контроль — це інший аспект: дії агента залишаються заблокованими, поки користувач керує браузером. Для самостійного продукту, яким користуються кілька агентів, зазвичай розумніше залишити активованим контроль через шлюз, оскільки тоді безпека не залежить від правильного застосування політик кожним клієнтом.
CB_ALLOW_LOOPBACK_NAVIGATION
Переключувач розробки, який дозволяє браузеру працівника відвідувати адреси типу loopback (localhost, 127.0.0.1 або ::1).
CB_ALLOW_LOOPBACK_NAVIGATION=true
За замовчуванням значення — false. Від цього отримують користь автоматизовані тести та локальні веб-додатки, що знаходяться на тій самій машині, що й працівник. Це не дозволяє віддаленому браузеру отримати доступ до ноутбука користувача, оскільки у віддаленому середовищі 127.0.0.1 є віддаленим адресним простором. Уникайте ввімкнення цього параметра без необхідності у продакшн-середовищі: доступ через луп-адресу може розкрити внутрішні адміністративні порти, сервери розробки, інтерфейси для дебаггінгу та сервіси, створені з припущенням, що ненадійний веб-контент не зможе до них достучатися. Навіть увімкнувши цей параметр, ім’я хоста має резолюватися лише на луп-адреси, тож змішана відповідь DNS не може перетворити цю виняткову ситуацію на загальне обхідне рішення.
CB_SYNTHETIC_MEDIA_DEVICES
Надає керованому браузеру штучний мікрофон та камеру.
CB_SYNTHETIC_MEDIA_DEVICES=true
Також за замовчуванням false. Браузери без вікна часто не відображають пристрої медіа, а деякі сайти для зустрічей та запису перевіряють наявність мікрофона чи камери перед продовженням роботи, тому сторінка здається застряглою, якщо їх не знайдено. Штучні пристрої дозволяють пройти ці перевірки: мікрофон залишається без звуку, а камера відображає тестовий візерунок замість справжнього відео. Ніщо тут не фіксує фізичний мікрофон чи камеру будь-кого, і це ніколи не слід описувати таким чином. Якщо працівник приєднується до реальної зустрічі, вимкніть його камеру, якщо тільки не потрібно транслювати тестовий візерунок. Сайт все одно може запитати про дозвіл, і надання його є окремим рішенням з точки зору політики, відокремленим від пропозиції використання пристрою.
Читання прикладу як однієї конфігурації
У сукупності зразок конфігурації описує локальну налаштування для розробки:
- Шлюз приймає лише локальні з’єднання на порту
8787.
8088 за будь-яким ім’ям хоста.Це функціонує як профіль локальної інтеграції, але не є базовою конфігурацією для продакшну. Перед запуском: перемістіть публічну URL у формат HTTPS, регулярно змінюйте всі секрети та зберігайте їх поза файлом, вимкніть режим loopback, обмежте винятки для CGNAT та приватних джерел, перевірте доступ service-worker, увімкніть політику схвалення гейтвею, розмістіть профілі та артефакти у зашифрованому керованому сховищі та надсилайте події аудиту на надійну платформу.
Підключення агента
Агент, який підтримує MCP, може запустити адаптер як локальний процес та налаштувати його на спілкування з гейтвеєм. Справжні облікові дані не потрапляють до системи контролю версій, тому використовуйте такі замінники:
{
"mcpServers": {
"cloud-browser": {
"command": "node",
"args": ["/path/to/cloud-browser/packages/mcp/src/index.js"],
"env": {
"CB_GATEWAY_ENDPOINT": "https://browser.example.com/v1/browser",
"CB_GATEWAY_TOKEN": "retrieve-from-your-secret-manager",
"CB_DOWNLOAD_ROOTS": "/approved/output"
}
}
}
}
Типова взаємодія відбувається ось так:
Agent: browser_open_tab(url)
Cloud Browser: tab identifier, page metadata, safe live-view metadata
Agent: browser_get_state(tab)
Cloud Browser: revision-bound semantic state
Agent: browser_click(fresh target)
Cloud Browser: confirmed receipt, updated state, evidence
User: take control through signed viewer
Cloud Browser: block agent input
User: release control
Cloud Browser: restore agent input
Agent: browser_finalize_session()
Cloud Browser: close working tabs, revoke authority, expire artifacts
У чому різниця між цим та інструментом браузера всередині одного агента
Багато продуктів типу агентів постачають власні інструменти браузера. Cloud Browser призначений стати браузерною платформою для багатьох агентів, а його цінність полягає у поєднанні таких характеристик:
- він залишається нейтральним щодо використовуваної моделі
- сесії зберігаються віддалено
- інтеракція є як семантичною, так і візуальною
- WebRTC дозволяє спостерігати та керувати
- дані облікових записів обробляються безпечно
- шлюз забезпечує контроль схвалень
- скріншоти слугують доказами та для повторного відтворення
- артефакти прив’язані до конкретних завдань
- очищення відбувається згідно з детермінованим життєвим циклом
- вбудовані механізми корпоративної ідентичності, політик та аудиту
Суть у всьому цьому полягає ось у чому:
Один раз продемонструйте процес роботи, а потім запустіть його через будь-якого штучного інтелектуального агента, при цьому людина все ще може зупинити наступні кроки.
Уроки з процесу створення
Браузер — це не найскладніша частина; справжньою проблемою є авторитет системи. З процесу дизайну випливло шість уроків.
Живий перегляд — це не просто відеоплеєр, а елемент безпеки: у ньому знаходяться контролі, схвалення, облікові дані та наміри користувача, тому його URL, політика форматування, термін дії та стан керування потребують такої ж уваги, як і функції API.
Надсилання повідомлення — це не те саме, що завершення взаємодії. Клацання може надійти, а сторінка просто проігнорувати його, тому введення даних потребує підтвердження, перегляду сторінки після цього та окремих позначок для статусів „надіслано“, „змінено“ та „ще очікується“.
Сліпі спроби є ризикованими. Там, де дія браузера може мати реальні наслідки, необхідні ідемпотентність та механізми узгодження.
Постійні сеанси роблять продукт кориснішим, але водночас і більш ризикованим. Ізольуйте їх за ідентифікатором та поєднуйте з функціями виходу, зберігання інформації, історії дій та очищення.
Ставтеся до вмісту сторінки та інструментів, наданих нею, як до ненадійних. Сайт може описати дію, але не має права її схвалювати.
Наостанок, наявність обмежених доказів полегшує довіру до автоматизації. Завдяки часовій шкалі скріншотів та підсумкам дій користувачі, розробники та оператори можуть зрозуміти причину невдачі.
Яке це створює ситуація
Агентам потрібні браузери, але компанії хочуть чогось більшого, ніж просто скрипти. Вони прагнуть платформи з чітким визначенням власника, терміновою дією повноважень, безпечною передачею обов’язків між людьми, захищеним процесом входу, схваленням будь-яких дій перед їх впливом, можливістю спостереження за результатами та надійним очищенням.
Cloud Browser перетворює Playwright та Chromium на таку платформу, розділяючи планування від виконання, агентів від облікових даних та можливостей браузера від повноважень користувача. Саме це розділення дозволяє повторно використовувати дизайн: замінивши агента, модель чи інтерфейс, межі безпеки навколо браузера залишаються незмінними. Це основа, необхідна для того, щоб люди могли справді довіряти автоматизації браузерами.