ИИ-агент, управляющий браузером внутри уже авторизованной сессии, для серверной части приложения выглядит как обычный пользователь — даже если он выполняет действия сам. Это ломает сразу три привычных принципа: отдельную идентичность агента, минимальные права и независимый аудит. О таком эксперименте с агентом Rehearsal, созданным компанией Token, сообщает The Hacker News; для российских команд это прямой повод пересмотреть безопасность ИИ-агентов до того, как они получат доступ к CRM, облачным консолям и внутренним системам.
Rehearsal отвечает на вопросы в платформе Token не текстовой подсказкой, а действием: открывает вкладки, задаёт фильтры и заполняет формы. По описанию Token, это типичный браузерный UI-агент, работающий в сессии пользователя. Проблема в том, что cookie сессии подтверждает личность человека, но не сообщает приложению, кто именно двигает курсор: сам владелец аккаунта или автономный помощник. Сервер видит легитимный запрос с допустимыми правами — и на этом его знание о контексте заканчивается.
Для IAM- и security-команд это неприятная, но важная деталь. В классической модели сервисный аккаунт можно ограничить ролью, токеном, сроком жизни и набором разрешений. Браузерный агент заимствует уже открытую человеческую сессию вместе со всеми её правами. Если сотрудник имеет возможность удалить объект, выгрузить данные или изменить настройки, агент технически получает ту же возможность. В аудит-логе действие легко останется просто действием пользователя, хотя решение приняла модель или цепочка автоматизации.
Эксперимент, который специально нарушил правила
Token смогла частично закрыть эти пробелы только потому, что контролирует и приложение, и собственного агента. Во время работы Rehearsal интерфейс затемняется и блокируется, чтобы пользователь видел, кто управляет вкладкой. Компания фиксирует все шаги агента в рамках сессии, включая заблокированные действия. Самому агенту урезали полномочия: он работает с дашбордами в режиме чтения, не сохраняет изменения без подтверждения человека, не заполняет поля с секретами и не пытается повторять запросы, отклонённые платформой.
Агент ориентируется в интерфейсе по accessibility labels — подписям, которые обычно нужны для доступности. Это полезный инженерный приём, но не универсальная защита. Сторонний браузерный агент в чужой CRM или консоли облачного провайдера не знает, какое поле содержит секрет, а какая кнопка безвозвратно удаляет данные. В свою очередь, приложение часто не знает, что перед ним вообще агент. Получается вполне рабочая автоматизация, в которой обе стороны действуют почти вслепую.
Автор материала предлагает разделить роли человека и агента не на уровне красивой политики в Confluence, а в самом протоколе доступа. Для осмысленного решения об авторизации приложению нужны три сигнала: идентичность агента, проверяемая связь с человеком, от имени которого он действует, и задача с более узкими правами, чем права этого человека. Без последнего пункта подпись агента мало что меняет: система узнает, кто сделал запрос, но всё равно даст ему слишком широкий доступ.
Стандарты появляются, но не складываются в единую цепочку
В отрасли уже есть отдельные элементы этой схемы. Браузеры начинают вводить защитные ограничения для агентного просмотра: Chrome, по данным Token, запрашивает одобрение человека перед чувствительными операциями вроде платежей или массовой рассылки писем, ограничивает набор сайтов под задачу и помечает посещения агента в истории. Microsoft позволяет администраторам включать агентный браузинг для конкретных сайтов и останавливать его перед вводом паролей и данных банковских карт.
Параллельно Google и Microsoft развивают в рабочей группе W3C черновик WebMCP. Идея в том, чтобы сайт публиковал действия как инструменты для агента и заранее помечал их как безопасные для чтения либо значимые. Тогда модели не нужно угадывать семантику кнопки по DOM и экрану. Ещё один черновик, Web Bot Auth в IETF, должен позволить сайту проверить, какой агент отправил запрос. Но каждый механизм решает только часть задачи. Браузер может знать, что действует агент, но не обязательно передаёт это приложению. WebMCP запускается в сессии пользователя и сам по себе не уменьшает его права. Web Bot Auth идентифицирует агента, однако не описывает делегирование от конкретного человека.
Именно здесь безопасность ИИ-агентов перестаёт быть задачей только для разработчиков моделей. Командам, которые внедряют copilots и браузерные расширения, стоит инвентаризировать агентные браузеры, расширения и endpoint-агенты, сопоставить их с владельцами и пользователями, а затем проверить, к каким идентичностям и системам у каждого из них есть доступ. Отдельно нужно искать сценарии обхода существующих ограничений: агенту не требуется взламывать учётную запись, если он уже работает в доверенной сессии сотрудника с расширенными правами.
Для необратимых и чувствительных операций разумнее включать step-up-проверку: запрос passkey, повторное подтверждение или иной явный шаг человека. Это касается удаления данных, смены прав, экспорта клиентской базы, платежей и изменения конфигураций. Критичным SaaS-поставщикам стоит задать два конкретных вопроса: различают ли их аудит-логи действия агента и человека и поддерживают ли они делегирование с ограничением по задаче. Ответ «у нас есть журнал активности» здесь недостаточен, если журнал не показывает, кто фактически управлял сессией.
Агенты приходят в рабочие процессы быстрее, чем браузеры, приложения и стандарты успевают договориться о едином контексте. Пока идентичность агента, полномочия пользователя и границы конкретной задачи не передаются вместе, каждую такую сессию стоит считать делегированным доступом: обнаруживать, ограничивать и проверять. Иначе удобный помощник станет самым вежливым способом обойти принцип минимальных привилегий.
