ai-agents browser-automation playwright security webrtc

Облачный браузер: безопасная удаленная платформа браузера для любого ИИ-агента

Пример проектирования нейтрального по модели удаленного браузерного сервиса: шлюз, рабочие процессы, прямая трансляция через WebRTC, система утверждений, защита от SSRF, возможность повторного воспроизведения и все настройки конфигурации.

Издатель: REACTAPP.TOPДобавлено на сайт 28 окт. 2026 г.32 мин чтения7288 слов

Источники: Building a Secure, Agent-Neutral Cloud Browser

Агенты ИИ уже довольно хорошо справляются с анализом веб-страниц, однако управление реальным браузером остается сложнее, чем кажется. Нажатие кнопок — это простая часть. Браузерный агент, на котором могут полагаться люди, должен поддерживать активные сессии, справляться с всплывающими окнами и перенаправлениями, понимать динамические интерфейсы, обрабатывать загрузку и сохранение данных, позволять человеку взять управление на себя, защищать учетные данные, запрашивать разрешение перед принятием важных решений и после этого показывать, что на самом деле произошло.

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. Такие исключения должны быть четко определены, ограничены конкретными доменами и настроены через параметры развертывания, чтобы соответствующее имя хоста никогда не превращалось в общий путь к частной сети. Перенаправления, всплывающие окна, iframes, запросы от сервисных рабочих процессов и перенастройка DNS остаются в рамках одной сетевой политики, поскольку проверка только первого URL недостаточна.

Вставка команд и содержимое ненадежных страниц

Рабочий процесс браузера рассматривает содержимое страницы как данные, а не как инструкции. На странице может быть отображено сообщение «Игнорируйте предыдущие инструкции» или описание инструмента, утверждающее, что та или иная операция безопасна, но ни одно из этих утверждений не предоставляет никаких полномочий.

Инструменты, рекламируемые страницей через WebMCP, связаны с URL страницы, процессом генерации документа, идентификатором регистрации и наблюдаемой схемой, и их описания никогда не считаются достоверными. Параметр readOnlyHint, предоставляемый страницей, не позволяет пропустить процедуру утверждения, если только развертывание явно не доверяет именно этому источнику в данной цели. Семантические снимки также подчиняются тому же правилу: анализ содержимого осуществляется агентом, но предоставление полномочий браузеру — исключительно гейтвеем.

Загрузка, передача и буфер обмена

Загруженные файлы хранятся как артефакты, принадлежащие конкретной задаче, поэтому путь рабочего процесса не раскрывается. Для загрузки требуется выбранный файл, связанный с определенным событием, а также исходный путь внутри настроенной корневой директории загрузки. Символические ссылки обрабатываются, и их использование отклоняется, если они указывают на файлы вне разрешенной директории; прежде чем сохранить файлы, рабочий процесс проверяет, был ли выбран один файл или несколько.

У каждой задачи есть собственное состояние буфера обмена. Текстовые и ограниченные двоичные объекты MIME могут синхронизироваться через режим просмотра в реальном времени, причем разрешения браузера предоставляются ограниченно и снимаются после этого. В постоянном контексте браузера разрешение на доступ к буферу обмена, предоставленное одной задаче, не должно оставаться действительным для другой.

Жизненный цикл и очистка

Процедура очистки должна выполняться даже в том случае, если агент так и не завершит свою работу корректно. Сервис ожидает явного сигнала окончания этапа, который позволяет отличить завершённые, прерванные, остановленные или остановленные подагентами этапы, причём запускаемая им процедура очистки имеет определённые границы и является идемпотентной. Каждая вкладка может содержать одну из трёх меток:

активная вкладка, закрывающаяся по окончании этапа
результат работы, сохраняемый для пользователя
задача для передачи, оставляемая открытой для продолжения работы пользователем

Метки, связанные с конкретным этапом, удаляются сразу после выполнения соответствующей действия, поэтому вкладку необходимо специально сохранять снова в последующем этапе. Дополнительные процедуры очистки осуществляются за счёт сроков действия сессий, тайм-аутов при бездействии, истечения срока действия объектов, удаления утерянных профилей и плавного выключения шлюза.

Возможность наблюдения без утечки конфиденциальных данных

Логи шлюза фиксируют операционные события, связанные с созданием сессий, навигацией, принятием решений по правилам, передачей управления, изменениями данных, сбоями и процедурами очистки. Запись аудита должна содержать идентификаторы и результаты, а не учетные данные или содержимое страниц. URL-адреса по возможности сокращаются до безопасных частей, а запросы, значения форм, пароли, токены и личные данные маскируются или удаляются.

Полезные операционные сигналы включают:

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

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

Надежность и тестирование на нагрузку

Самые опасные сбои в автоматизации браузера — это те, которые происходят незаметно: клик, не приведший ни к чему, данные, отправленные дважды, всплывающее окно, которого никто не увидел, или действие, повторенное после истечения времени ожидания. Поэтому серьезный набор тестов выходит далеко за рамки стандартного пути навигации. Cloud Browser тестирует следующие аспекты:

множество пользователей и сессий одновременно
разделение задач и результатов их выполнения
мутации, которые должны быть идемпотентными
обращение к устаревшим документам
обработка всплывающих окон
цели внутри iframes и shadow roots
переподключение WebRTC
конфликты при смене контроля
страницы, находящиеся в процессе обработки или временно замороженные

нажатия клавиш, поступающие в определенном порядке

поля для одноразовых кодов

безопасный процесс входа

разрешения на работу с конфиденциальными данными

скриншоты, предотвращающие повторную передачу

попытки выйти за пределы корневой директории загрузки

защита от SSRF и некорректного перемещения между ресурсами

восстановление сессий

очистка при прерывании работы

Тесты на нагрузку должны одновременно использовать реальные рабочие процессы Chromium и множество просмотрщиков WebRTC. Единичные тесты хорошо покрывают логику правил и протоколов, но проблемы с синхронизацией при запуске браузера, стриминге видео, управлении фокусом, выборе всплывающих окон и передачей данных проявляются только при реальной нагрузке.

Модель развертывания

Справочная архитектура может работать как один узел, хотя её интерфейсы предназначены для более крупной системы управления в производственных условиях. Базовая схема развертывания объединяет эти компоненты в единую структуру:

TLS ingress
  -> Cloud Browser gateway
    -> isolated browser workers
      -> encrypted profile and artifact volume

Браузер должен работать от имени пользователя с ограниченными правами в соответствующем профиле seccomp, при этом у него должны быть ограниченные ресурсы процессора и памяти, а также достаточно общей памяти для Chromium. Контейнеры представляют собой практический старт, а в более рискованных средах может быть выбрана одна микро-ВМ на каждого рабочего процесса браузера для более строгой изоляции.

В корпоративных решениях обычно добавляют:

вход через OIDC для автономной консоли
аутентификацию между устройствами для агентов
идентификатор конечного пользователя, передаваемый надежными бэкендами
Redis для хранения дистрибутированных лицензий и ключей идемпотентности
PostgreSQL или специализированную платформу для аудита событий
шифрованное хранилище объектов для артефактов
планировщик, отвечающий за размещение рабочих процессов
серверы TURN, выдающие краткосрочные учетные данные WebRTC
менеджер секретов с возможностью их обновления
региональное маршрутизирование вместе с механизмами контроля за местоположением данных

автомасштабирование, основанное на количестве активных сессий и числе партнеров в 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. Этот лимит предназначен для защиты от случайных атак браузеров и неконтролируемой активности агентов, а также для того, чтобы один пользователь не мог исчерпать общую пропускную способность; он дополняет ограничение по количеству сессий на уровне шлюза. Оптимальное значение зависит от объема памяти и мощности процессора рабочего процесса, режима работы и ожидаемого уровня одновременных операций. Даже если постоянный профиль использует один и тот же процесс браузера для выполнения разных задач пользователя, каждая из этих задач все равно потребляет ресурсы, связанные с вкладками, стримингом, результатами обработки и шлюзом.

`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, но никогда необратный адрес, локальные адреса, метаданные облаков, мультикаст или зарезервированные адреса. Рассматривайте это как исключение 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`

Переключатель разработки, позволяющий браузеру работника обращаться к адресам лупбэка (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 под любым именем хоста.

Рабочие процессы запускают настоящий Google Chrome без видимого окна.

Включены как сервисные рабочие процессы, так и синтетические медиа-устройства, что обеспечивает совместимость приложений.

У каждого пользователя есть постоянный профиль браузера.

Общедоступные сайты, как правило, открыты.

Некоторые домены компании могут перенаправляться на частные или CGNAT-сети.

Включены исключения для навигации в режиме loopback и CGNAT.

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

Этот профиль работает в качестве локального профиля интеграции, но не является базовой конфигурацией для производства. Перед запуском: переведите публичный URL в формат HTTPS, регулярно меняйте все секретные данные и храните их вне файла, отключите локальное подключение, сузьте исключения для 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 в такую платформу, разделяя планирование и выполнение, агентов и учетные данные, а также возможности браузера и полномочия пользователей. Именно это разделение позволяет использовать дизайн повторно: заменив агента, модель или интерфейс, границы безопасности вокруг браузера остаются прежними. Это основа, необходимая для того, чтобы люди могли действительно доверять автоматизации с помощью браузера.

← Все статьи Прислать бриф