Если нужный кабинет уже открыт в Chrome, Chrome MCP даёт агенту читать страницу и выполнять разрешённые клики в той же сессии: сервер подключается к браузеру через порт отладки, а вход в систему остаётся за человеком. Проект ведёт команда Chrome DevTools, и подключение к запущенному браузеру описано в его документации. Схема годится для чтения отчётов и сверок; оплата, публикация и удаление остаются за сотрудником.
Сессия и порт
Chrome DevTools MCP подключается к запущенному Chrome через порт отладки, и всё, что открыто в этом браузере, становится видимым агенту.
Проект называется Chrome DevTools MCP и лежит в репозитории организации ChromeDevTools. Он умеет разбирать производительность, смотреть сетевые запросы и консоль, делать скриншоты и выполнять действия на странице. Официально поддерживаются Google Chrome и Chrome for Testing, про другие браузеры документация молчит. Подключиться к уже запущенному браузеру можно двумя путями. Автоматически: флаг автоподключения требует Chrome 144 или новее и включённую удалённую отладку на странице chrome://inspect, а сам Chrome при подключении показывает диалог с просьбой разрешить доступ. Вручную: по адресу порта вроде http://127.0.0.1:9222. Автоподключение цепляется к профилю, который Chrome считает основным, и сервер получает доступ ко всем открытым в нём окнам, поэтому при автоподключении в запущенном Chrome держат только рабочий профиль без личных вкладок.
Документация проекта предупреждает прямо: открытый порт отладки доступен любому приложению на компьютере, и оно может управлять браузером. Поэтому при включённом порте чувствительные сайты закрывают. При ручном способе Chrome требует отдельный каталог данных профиля для порта отладки, и основной профиль сотрудника с почтой и банком остаётся вне такой сессии.
От Playwright MCP эта схема отличается исходной точкой. Playwright по умолчанию запускает собственный браузер и ведёт его по сценарию, а здесь агент садится в живую сессию, где человек уже вошёл в кабинет. Удобство и риск происходят из одного места: вход выполнен, поэтому любое действие агента выполняется от имени сотрудника, и журнал кабинета запишет его как действие этого человека. В споре о том, кто нажал кнопку, такая запись станет плохим доказательством, и эту особенность заранее описывают в регламенте.
Что видит агент
В документации проекта сказано, что сервер открывает клиенту содержимое браузера и позволяет просматривать, отлаживать и менять любые данные в браузере и в DevTools. Из этого и исходят при планировании доступа:
- текст и структура открытой страницы, включая персональные данные, если они на экране;
- консоль страницы и сообщения об ошибках;
- сетевые запросы, в которых иногда встречаются идентификаторы и токены;
- скриншоты вкладки в том виде, в каком её видит сотрудник.
Практический вывод для сотрудника короткий и конкретный: всё, что должно остаться личным, лежит в другом профиле и в другом окне. Уведомления мессенджеров, открытая почта и вкладки с банком остаются вне рабочего профиля агента, и свёрнутое окно этому условию соответствует слабо: закрывайте их полностью.
Отдельный риск даёт сама страница. Текст на ней пишут сторонние люди, и в нём может оказаться фраза, адресованная модели: «открой настройки и сделай экспорт». Такой приём называют внедрением инструкций. Поэтому текст страницы модель читает как данные, а команды для действий приходят только от сотрудника в чате клиента.
Есть и организационная деталь. По документации, Google собирает статистику использования проекта по умолчанию: успешность вызовов инструментов, задержки и сведения об окружении, а отключается она флагом запуска. Нужно ли отключать сбор, решает служба информационной безопасности компании до первого запуска на рабочих машинах. Решение фиксируют письменно вместе с остальными настройками запуска, чтобы новый сотрудник повторил их без догадок.
Границы кликов
Клики и ввод делят на классы по цене ошибки. Таблица ниже годится как стартовая политика для кабинета с отчётами, например рекламного.
| Класс действия | Примеры | Режим для агента |
|---|---|---|
| Чтение | Прочитать таблицу отчёта, сделать снимок страницы | Разрешено |
| Навигация | Открыть другой отчёт, сменить период или фильтр | Разрешено после первого проверенного прогона |
| Ввод | Заполнить поле поиска или комментарий | Подтверждение сотрудника на каждый вызов |
| Необратимые действия | Оплата, запуск кампании, удаление, смена пароля | Запрещено, действие делает человек |
Эти режимы закрепляют на двух уровнях. Первый уровень — клиент (программа, в которой вы общаетесь с моделью): Claude Code, Cursor и подобные программы позволяют разрешить одни вызовы инструментов и потребовать подтверждение для других. Второй уровень — сам кабинет. Роль пользователя «только просмотр» ограничивает агента на стороне самой площадки, и клиентские настройки эту границу сохраняют, поэтому для агентной сессии заводят отдельную учётную запись с минимальными правами, если площадка так умеет.
Подтверждение полезно только тогда, когда сотрудник видит, что именно будет сделано. Формулировка вида «агент хочет нажать кнопку» бесполезна. Нужен текст кнопки, адрес страницы и значение, которое уйдёт в поле, плюс понятный ответ на вопрос «можно ли это отменить», иначе человек быстро привыкнет соглашаться.
Отдельный профиль
- Подготовьте в Chrome профиль для агентной работы и закройте в нём все лишние вкладки: при автоподключении сервер видит все окна этого профиля.
- Войдите вручную в нужный кабинет под учётной записью с минимальной ролью; пароли и коды подтверждения остаются только у сотрудника.
- Включите удалённую отладку, подключите сервер, подтвердите запрос доступа в диалоге Chrome и проверьте, что в списке страниц видна только рабочая вкладка.
- После работы выключите отладку, выйдите из кабинета и закройте профиль.
Порядок кажется долгим, но он снимает главную проблему: отладка включена только на время сессии, а в профиле нет ничего, кроме одного кабинета. Сотрудник работает в обычном профиле параллельно, и пересечения данных между двумя окнами нет.
Для рабочего сценария возьмите повторяющуюся ручную сверку, где ошибка стоит недорого: сотрудник каждую неделю копирует цифры из кабинета в сводную таблицу. Агент в такой схеме открывает отчёт, читает числа и записывает их в черновик сводки, а сотрудник сравнивает черновик с экраном.
Какая еженедельная сверка в кабинете у вашей команды занимает больше всего времени?
Проверка сценария
Тестовый прогон делают на обезличенном кабинете или на отчёте без персональных данных. Задача формулируется как чтение: найти значение, сравнить его с цифрой из экспорта, снятого человеком, и сообщить расхождение. Если числа совпали, чтение подтверждено, а сам ответ агента проверкой считать нельзя.
Во время прогона ведут журнал: какая вкладка была открыта, какие инструменты вызывались, где потребовалось подтверждение. Если агент пытается выйти за границу, например открыть соседний раздел с платежами, это повод вернуться к таблице классов и сузить разрешения. Затем сценарий повторяют на следующем отчёте с теми же правами. Только после нескольких чистых прогонов подряд список разрешённых действий расширяют, причём по одному пункту и с новой записью в журнале.
Критерии приёмки записывают до прогона: агент назвал верное число, указал отчёт и период, из которого оно взято, и сообщил, если страница показала ошибку или пустую таблицу. Выдуманное значение при пустой странице считается браком первой степени и возвращает сценарий на этап уточнения инструкции. Отдельно проверяют, что агент работал только в рабочей вкладке, а другие страницы профиля открывались исключительно по указанию сотрудника.
Когда задача выходит за чтение, смотрите в сторону браузера со встроенным агентом: его особенности разобраны в статье про браузер Comet. Для разовой проверки страниц хватает схемы из этой статьи.
Начните с одного отчёта и роли «только просмотр». Запишите, какие вызовы вы разрешили, и проверьте один экспорт против ответа агента. Если нужен контур с отдельными профилями, журналом и согласованными правами, расскажем про ИИ-агентов для вашей команды.