Как AI-агенты подтверждают, что вы — это вы

Что произошло

В 2024–2025 годах крупные разработчики выкатили инструменты, которые позволяют AI-агенту действовать за пользователя: заходить в сервисы, заполнять формы, совершать покупки. У OpenAI это Operator и режим работы в браузере, у Anthropic — Claude с функцией управления компьютером (Computer Use), у Google — линейка агентных возможностей в Gemini. Как только агент начинает нажимать кнопки на реальных сайтах и тратить реальные деньги, встаёт вопрос, на который раньше отвечал сам человек: как сервис на другом конце убедится, что действие санкционировано вами, а не запущено чужим скриптом.

Это не абстракция. Если агент от вашего имени оформляет возврат, меняет тариф или подтверждает платёж, то система защиты, рассчитанная на живого человека с капчей и SMS-кодом, либо ломается, либо начинает мешать. Верификация личности при работе с агентом — отдельная инженерная и юридическая задача, и единого стандарта под неё пока нет.

Почему старые способы не работают

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

• Капча. Она специально отсеивает автоматизацию. Агент, который проходит капчу за вас, формально нарушает её смысл, а сервис не может отличить полезного агента от вредоносного бота.
• Одноразовые коды. SMS или коды из приложения приходят вам, а не агенту. Чтобы агент их использовал, ему нужно дать доступ к вашей почте или телефону — это резко расширяет поверхность атаки.
• Сессии и куки. Агент часто работает в изолированном браузере. Ваша авторизованная сессия туда не переносится сама, а если переносится — вы фактически отдаёте агенту полный доступ к аккаунту без ограничений.

Отсюда три разные модели, которые сейчас конкурируют за то, как это должно работать.

Модель 1. Агент действует в вашей сессии

Самый простой и самый рискованный путь. Вы логинитесь сами, а агент управляет уже открытым браузером. Так устроены многие браузерные агенты. Плюс — ничего нового настраивать не нужно. Минус — у агента столько же прав, сколько у вас, и никакого технического разграничения «это можно, а это нельзя» нет. Ошибка модели или подмена инструкции через prompt injection¹ означает действие от вашего лица без вашего ведома.

Модель 2. Делегирование через токен с ограниченными правами

Здесь на сцену выходит подход в духе OAuth: вы выдаёте агенту токен, который разрешает строго определённый набор действий и живёт ограниченное время. Агент не знает вашего пароля, а сервис видит, что запрос пришёл от делегата с урезанными полномочиями. Это ближе к тому, как приложения годами получают доступ к вашему Google-календарю, не зная пароля от почты.

Модель 3. Отдельная идентичность агента

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

Вопрос не в том, умеет ли агент нажать кнопку. Вопрос в том, кто отвечает за последствия нажатия — и чем это доказывается, если что-то пошло не так.

Сравнение подходов

Где проходит граница чувствительных действий

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

Проблема в том, что чем больше подтверждений, тем меньше смысла в автономном агенте. Идеального соотношения нет, и каждый сервис проводит границу по-своему.

Кому это пригодится и кому нет

Пригодится:

• Разработчикам, которые встраивают агента в сервис с платежами или персональными данными — им придётся выбрать модель делегирования заранее, а не после инцидента.
• Бизнесу с повторяющимися операциями: заказы, бронирования, обработка заявок, где рутину можно отдать агенту под ограниченным токеном.
• Пользователям, готовым один раз настроить права агента и получать экономию времени на однотипных задачах.

Пока не стоит полагаться:

• На агента для действий с необратимыми последствиями без подтверждения — крупные переводы, юридически значимые подписи, отправка документов в госорганы.
• Тем, кто не готов разбираться, какие именно права выданы агенту. Модель «дал доступ к аккаунту и забыл» — это открытая дверь.
• Сервисам, где регулирование прямо требует личного присутствия и биометрии человека: здесь агент как делегат может просто не пройти по закону.

Что с этим делать сейчас

1. Проверьте, в какой из четырёх моделей работает ваш агент. Если он просто действует в вашей открытой сессии — считайте, что у него полный доступ.
2. Ограничивайте область действий: отдельный аккаунт, отдельная карта с лимитом, отдельный токен под конкретную задачу.
3. Требуйте подтверждения на всём, что связано с деньгами и данными. Автономность заканчивается там, где начинается необратимость.
4. Ведите журнал действий агента, если платформа это позволяет — это единственный способ разобраться, кто и что сделал, при споре.

¹ Prompt injection — атака, при которой во входные данные (например, текст на веб-странице) встраивается скрытая инструкция, заставляющая агента выполнить действие, которого пользователь не просил.