Представь себе такую ситуацию: ты просишь своего AI-агента забронировать билет на самолет, проверить электронную почту или обновить CRM. Для этого ему нужен доступ к твоим онлайн-аккаунтам. Но как ему войти в систему безопасно, не надоедая тебе постоянными запросами пароля?
Агенты могут выполнять множество задач от имени пользователя. Для этого им часто нужен доступ к сторонним сервисам: сайтам, базам данных, внешним API. Хотя иногда агент может подключаться к таким сервисам программно, во многих случаях по-прежнему требуется классический вход и взаимодействие с пользователем.
В предыдущей статье мы рассмотрели риски с точки зрения безопасности, особенно когда браузеры управляют учетными данными пользователя, что может привести к уязвимостям: https://blog.logto.io/agent-auth#chatgpt-operator-agent-auth-experience
Хотя такой подход вызывает обоснованные вопросы с точки зрения безопасности, как мы уже обсуждали, сложно игнорировать удобство для пользователя. Противоречие между удобством и безопасностью делает эту тему особенно интересной для дальнейших технических исследований.
В этой статье я расскажу, как некоторые агенты уже решают задачу, которую можно назвать «вход и аутентификация через браузер».
Мы детально рассмотрим подход Manus к решению этой задачи, оставшиеся риски и перспективы аутентификации в средах, где работают агенты.
Подход Manus: «Вошел один раз — оставайся в системе»#
Manus создал функцию под названием Cloud Browser (Облачный браузер), которая работает как удалённый изолированный компьютер, функционирующий полностью в облаке. Это как приватный браузер твоего агента, у которого есть важная особенность: он запоминает состояние входа даже между разными устройствами и заданиями.
Вот как это работает:
- Ты вручную входишь на сайт через Cloud Browser. Это требуется только один раз для каждого сайта.
- Manus сохраняет данные твоей сессии: cookies, local storage, все, что нужно, чтобы оставаться авторизованным.
- Данные дважды шифруются: сначала локально, затем еще раз в облаке. Ничего не хранится в открытом виде.
- Когда агенту нужно снова зайти на сайт, Manus автоматически внедряет сессию в новый изолированный контейнер. Сайт считает, что ты всё ещё авторизован.
- Ты можешь синхронизировать данные между устройствами и в любой момент вручную очистить сессии через настройки.
Это похоже на то, как если бы ты дал агенту безопасный ключ-карту, которая работает везде — но только в его собственной запертой комнате.
Локальные браузеры (например, Chrome) и облачные браузеры под управлением агентов#
Ты можешь спросить: «Чем это отличается от использования Chrome? Почему облачный браузер под управлением агента кажется более рискованным?» Давай разберёмся, почему так.
- Почему обычно безопасно доверять Chrome свои учетные данные
- Почему доверять их облачному браузеру агента рискованно
- Кто здесь «первая сторона», а кто «третья сторона» в каждом контексте
Основные различия: Локальный браузер vs. облачный браузер агента#
| Аспект | Локальный браузер (например, Chrome) | Обычный облачный браузер агента |
|---|
| Расположение | Выполняется на твоём личном устройстве | Работает удалённо в облаке |
| Контроль | Полностью под твоим контролем | Под контролем кода или AI-агента |
| UI (обратная связь) | Ты взаимодействуешь напрямую (видимые поля, автозаполнение) | Есть интерфейс и пользовательский контроль, но многие действия автоматизированы программно агентом. |
| Хранение | Учетные данные защищены ОС (например, macOS Keychain) | Учетные данные или cookies могут храниться в памяти или логах, что повышает риск утечки. |
| Граница безопасности | Защищено ОС + песочницей браузера | Требует собственной изоляции, уязвим при ошибках или утечках агента |
| Модель доверия | Ты доверяешь Chrome, потому что он работает рядом с тобой и создан для пользователя | Ты доверяешь разработчикам агента, которые могут не обеспечивать достаточную защиту |
Почему Chrome безопаснее для хранения паролей#
-
Ты — оператор
Chrome — это интерфейс первой стороны: ты контролируешь его, видишь, что он делает, и он принадлежит твоей вычислительной среде. Ты вводишь пароль осознанно, браузер делает все прозрачно.
-
Прочная интеграция с системой безопасности
Chrome сохраняет пароли с использованием защищённого хранилища ОС, часто требует биометрию или вход в устройство для разблокировки. Автозаполнение работает только в ожидаемых (безопасных) случаях.
-
Минимальная делегация
Ты не «отдаёшь» пароли Chrome навсегда — он просто запоминает то, что ты ввел, с твоего разрешения. Ты — главный участник домена.
Почему облачные браузеры агентов рискованны#
-
Они действуют от твоего имени, но не на твоих глазах
Облачные браузеры обычно управляются автоматически. Когда ты передаешь им данные для входа, они авторизуются за тебя, часто без интерфейса или обратной связи. Это создает проблемы прозрачности и надёжности.
-
Риски при хранении
Если ты передаешь агенту логин и пароль в открытом виде, они могут попасть в логи, кэш или остаться в памяти. Без строгого контроля доступности это — угроза безопасности.
-
Нечеткая граница доверия
Можно доверять провайдеру агента, но, в отличие от Chrome, тут нет защиты на уровне ОС и «железа». В случае компрометации сервера либо ошибочной реализации агента твои учетные данные могут утечь.
Первая сторона vs. третья сторона#
Разберемся, что означает «первая» и «третья» сторона и почему Chrome считается первой, а облачный браузер агента — нет.
| Роль | Chrome | Облачный браузер агента |
|---|
| Ты (Пользователь) | Оператор первой стороны | Владелец учетных данных |
| Браузер/Приложение | Интерфейс первой стороны (ты взаимодействуешь напрямую) | Делегат (третья сторона), действующий от твоего имени |
| Обработка учетных данных | ОС + Chrome (надёжная местная цепочка доверия) | Внешний сервис агента (слабое разграничение доверия) |
| Хранение | Локально, под защитой ОС | Удалённо — на облачных серверах или бэкэнде |
Доверять Chrome просто — ты сам вводишь пароль в приложение, которое ты контролируешь, а операционная система добавляет свои уровни защиты. Google не хранит твой пароль на своих серверах.
Однако Manus объясняет:
Мы сохраняем ваши данные для входа в виде зашифрованных файлов и загружаем их на наши защищенные серверы. К этим данным относятся:
Это значит, что твои данные для входа хранятся на серверной стороне Manus. Пользователь должен доверять разработчикам агента, что не всегда соответствует лучшим практикам в области информационной безопасности.
Передавая пароли облачному браузеру агента, ты фактически осуществляешь делегирование. Даже при ручном использовании такого браузера сервис, куда ты входишь, всё равно считает это третьей стороной. Ты полагаешься на чужую инфраструктуру, процессы безопасности и этику — а это уже риски доверия и безопасности.
В таких случаях безопасность нужно обеспечивать с помощью протоколов, а не просто верить бренду либо обещаниям компании.
В чем Manus силен (и где есть риски)#
Что работает:#
- Действительно бесшовные сессии: Тебе не нужно входить заново даже на другом устройстве.
- Безопасность в интересах пользователя: Всё зашифровано от конца до конца, полный контроль над тем, что хранится.
- Честность и прозрачность: Manus не использует твои данные для входа для аналитики и обучения моделей.
А где остерегаться:#
- Атаки типа «повтор сессии»: если кто-то украдёт твой файл сессии, он сможет выдать себя за тебя.
- Несовпадение отпечатков устройств: некоторые сайты используют продвинутые методы связывания сессий с устройством; повтор сессии в песочнице может не сработать.
- Не обойти CAPTCHA: для некоторых сайтов с серьёзной защитой и CAPTCHA действия через Cloud Browser могут быть отмечены как бот и запретить прохождение.
- Соответствие закону: перенос сессий между странами или устройствами может вызвать вопросы приватности и регулирования.
- Доверие к системе: ключи шифрования должны быть отлажены и хорошо защищены.
Другие способы входа через агентов#
Метод Manus — умный, но не единственный. Вот что ещё используют для входа через агентов:
Ввод паролей вручную#
Самый простой способ, когда агент сам «пишет» логин и пароль, как человек. Это легко реализовать, но чревато утечкой: если пароль всплывёт, любой получит доступ. Поэтому разработчики почти всегда избегают этого метода.
Если его и применяют, то обязательно с vault или секрет-менеджерами — они позволяют хранить cookies или учетные данные более безопасно, добавляя дополнительную защиту.
OAuth-токены#
Золотой стандарт делегированного доступа. Ты проходишь аутентификацию через OAuth, агент получает токен с ограниченными правами — его легко отозвать. Это безопасно, удобно и гибко, но работает только для сайтов с поддержкой OAuth.
Программные методы (например, API-ключи)#
Некоторые сервисы выдают API-ключи для программной работы. Это безопаснее, чем вводить пароль, но такие ключи часто обладают слишком широкими полномочиями, и требуют внимательного управления.
Каждый способ — это баланс между удобством и безопасностью. Повтор сессии в стиле Manus — более гибкий вариант, чем OAuth в ряде случаев, но менее надёжный в плане безопасности.
В идеале в таких сценариях Manus мог бы интегрироваться с определёнными сайтами (например, список поддерживаемых ресурсов), и пользователь заранее давал бы согласие на работу агента через OAuth, не требуя хранения паролей и повторов сессий.
К чему всё идёт: агенты как доверенные профессионалы#
Когда агенты будут становиться умнее, потребуется всё более продвинутая аутентификация — и без «маскировки под человека».
Куда движемся:
- Доступ через API: вместо кликов агент вызывает защищённый API с токеном.
- Краткоживущие, ограниченные разрешения: никаких токенов «бог-режима», только строго необходимые права и на ограниченное время.
- Аппаратная безопасность: сессии и секреты хранятся в защищённых аппаратных средах, а не просто в программах.
- Личный хранилище токенов: у тебя будет защищённый кошелёк токенов, ключей и сессий, который ты доверяешь только своим агентам.
В двух словах: агенты перестанут быть просто «ботами» и станут «авторизованными операторами» с настоящими доступами.
Что такое Vault и почему это важно#
Если всё это кажется сложным... На мой взгляд, с ростом браузерной автоматизации такой функционал должен идти рука об руку с профессиональным инструментом для безопасной и прозрачной работы с учетными данными и сессиями.
Именно поэтому важны инструменты вроде Vault или систем управления ключами (EKM).
Vault — это решение для управления секретами, позволяющее:
- Надёжно хранить токены, API-ключи и «секреты»
- Выдавать динамические, краткоживущие ключи и пароли
- Контролировать доступ и вести полные логи действий
- Автоматически ротировать (заменять) секреты и моментально отзывать доступ
- Интегрироваться с CI/CD и облачными приложениями
В мире агентов Vault становится «мозгом» безопасности. Агент запрашивает доступ через Vault и сам никогда не хранит пароли. Даже если что-то утечет, токен быстро протухнет, а твои настоящие ключи — в безопасности.
Заключение#
Manus создает удобный и продуманный подход к входу агентов: безопасный повтор сессии на разных устройствах, полный контроль за пользователем. Это серьёзный шаг вперёд, но и напоминание о деликатности login-флоу. Стоит помнить об атаках на сессии, особенностях виртуальных сред и управлении ключами.
Будущее ясно: агенты будут делать для нас всё больше, но им нужны надёжные доступы. Такие инструменты, как Vault, станут не только хранилищем «секретов», но и гарантом доверия.
Когда у твоего AI появляются ключи к твоей цифровой жизни — тебе важно знать: кто их выдал, на сколько времени, и что этим ключом можно открыть.
Logto вводит Vault для безопасного хранения сторонних API-токенов, чтобы агенты безопасно получали доступ к внешним сервисам — например, к соцсетям Google или удалённым MCP-серверам. В будущем планируется поддержка хранения более широкого набора данных: учётных записей, ключей и других секретов.
Кроме того, Logto — это комплексная платформа для аутентификации, авторизации и управления идентификацией. Если ты создаёшь AI-агента с нуля, Logto создан для AI-разработчиков, предоставляя безопасность, гибкость и инфраструктуру для управления идентификацией в среде с агентами.
