Представьте совершенно нормальную ситуацию. Я прошу ИИ-агента купить мне билет дешевле 10 тысяч рублей, разрешаю использовать банковскую карту и закрываю ноутбук. Через час агент приходит на сайт перевозчика. Сайт видит браузер без человека перед экраном и задаёт старый вопрос «Вы робот?». Правильный ответ звучит странно. Да, робот. Но робот пришёл сюда по моему поручению, с моими деньгами и с законным правом совершить конкретную покупку.
Вот почему проблема CAPTCHA стала гораздо интереснее, чем очередная история про нейросеть, которая научилась выбирать светофоры на картинках. Интернету теперь мало определить, человек перед ним или программа. Сайту нужны ответы сразу на три вопроса. Кто выполняет действие, от чьего имени программа действует и что именно владелец разрешил программе сделать. Я думаю, именно здесь проходит настоящая граница между старым вебом и вебом ИИ-агентов.
CAPTCHA проигрывает не потому, что ИИ стал человеком
Идея CAPTCHA изначально держалась на простом неравенстве. Человеку легко прочитать искажённый текст, найти автобус или перетащить объект, а программе трудно. Система превращала человеческое восприятие в дефицитный ресурс. Пока компьютерное зрение было слабым, модель работала достаточно хорошо.
Граница постепенно исчезла. На USENIX Security исследователи показали универсальный решатель Halligan на базе зрительно-языковой модели. На 2600 заданиях из 26 типов визуальных CAPTCHA система справилась с 60,7% проверок, а в эксперименте с ранее не встречавшимися заданиями из реальных CAPTCHA-сервисов результат достиг 70,6%. Более свежие экспериментальные системы уже обучают компьютерных агентов не просто распознавать изображение, а выполнять весь интерактивный сценарий с кликами, исправлением ошибок и повторными попытками.
Из подобных результатов иногда делают слишком сильный вывод, будто CAPTCHA уже бесполезна. Я бы так не говорил. CAPTCHA всё ещё повышает стоимость массовой автоматизации, отсекает примитивные скрипты и остаётся одним из сигналов антифрод-системы. Кроме того, современные reCAPTCHA, Turnstile и похожие решения давно оценивают не только ответ на картинку. Сервисы смотрят на свойства браузера, репутацию сети, историю взаимодействия, признаки автоматизации и другие сигналы риска.
Но как способ доказать «перед нами именно человек» визуальная головоломка становится всё менее убедительной. Ещё хуже CAPTCHA подходит для разрешённых ИИ-агентов. Хороший агент как раз должен уметь пользоваться сайтом без человека, поэтому успешно заблокировать такого агента означает помешать законному пользователю.
На SecurityLab мы уже разбирали PACT, инициативу Cloudflare, Mozilla, Google, Microsoft и других участников веб-экосистемы. Private Access Control Tokens предлагают заменить часть навязчивых проверок переносимыми анонимными свидетельствами доверия. Браузер может получить криптографическое подтверждение от стороны, которая уже располагает сильным сигналом легитимности, а затем предъявлять подтверждение другим сайтам без раскрытия личности и истории посещений.
Но PACT закрывает лишь часть новой проблемы. Такой токен может помочь ответить на вопрос «этому клиенту можно доверять чуть больше», однако не объясняет сайту, кто конкретно запустил автономного агента и разрешал ли пользователь купить три авиабилета за 180 тысяч рублей. Для такого сценария нужен другой слой.
Материал предназначен для легального и ответственного применения технологий идентификации и защиты. При разработке агентов и систем автоматизации нужно соблюдать законодательство своей страны, включая российское законодательство, правила сервисов и требования к обработке персональных данных. Описанные механизмы нельзя применять для несанкционированного доступа, слежки, взлома или незаконного обхода ограничений.
Интернету нужен не тест, а цепочка доверия
В привычной системе веб-сервис часто смешивает три совершенно разные сущности. Учётная запись показывает пользователя, сессионный токен даёт приложению права пользователя, а запрос выглядит так, будто пользователь самостоятельно нажал кнопку. Для обычного браузера подобное упрощение терпимо. Для автономного агента схема становится опасной.
| Что хочет узнать сайт | Какой механизм нужен | Чего механизм не доказывает |
|---|---|---|
| Есть ли за запросом реальный человек | Proof of personhood, доверенный токен, подтверждённая учётная запись | Кто именно выполняет текущую операцию |
| Какой агент отправил запрос | Собственная идентичность агента и цифровая подпись | Разрешил ли пользователь конкретное действие |
| Что агенту позволено сделать | Проверяемое делегирование полномочий | Что агент обязательно поведёт себя разумно |
Самый понятный строительный блок уже существует. HTTP-запрос можно подписать криптографическим ключом. Стандарт RFC 9421 определяет HTTP Message Signatures, а Cloudflare построила поверх подобного подхода Web Bot Auth. Автоматизированный клиент публикует открытый ключ, подписывает запросы закрытым ключом, а принимающая сторона проверяет подпись.
Упрощённый запрос выглядит примерно так.
Signature-Agent: "https://agent.example/.well-known/http-message-signatures-directory"
Signature-Input: sig1=("@method" "@authority" "@path");created=1770000000;keyid="agent-key"
Signature: sig1=:BASE64_SIGNATURE:Подпись меняет фундаментальную вещь. Заголовок User-Agent можно написать какой угодно, IP-адрес можно сменить или разделить между тысячами клиентов, а доказать владение закрытым ключом без самого ключа уже значительно сложнее. Сайт получает не предположение «похоже на известного бота», а криптографически проверяемое утверждение «запрос подписал владелец данного ключа».
Остаётся следующий вопрос. Чей ключ?
Здесь появляются проекты идентификации ИИ-агентов. В IETF Datatracker сейчас находятся несколько отдельных документов с названием Agent Identity Protocol. Формулировку «IETF разработала стандарт AIP» я бы считал неверной. Речь пока идёт об индивидуальных Internet-Draft. Datatracker прямо предупреждает, что подобные документы может отправить любой автор, IETF их не одобрила и формального статуса стандарта у них нет.
Но направление хорошо видно. Один из наиболее свежих вариантов AIP предлагает привязать действие к идентичности агента, источнику полномочий, цепочке делегирования и ограничениям. Другой вариант использует децентрализованные идентификаторы, токены возможностей и цепочки делегирования. Третий предлагает реестр агентов, собственные пары ключей и прокси, который проверяет полномочия перед вызовом инструмента.
Авторы расходятся в архитектуре, но решают одну и ту же проблему. Агент не должен притворяться пользователем и наследовать все его права. Агенту нужна собственная цифровая идентичность.
Похожую проблему рассматривает и NIST. В концептуальном документе об идентичности программных и ИИ-агентов институт отдельно перечисляет идентификацию, авторизацию, аудит, подтверждение происхождения действий и защиту от внедрения инструкций. Сам факт появления такой программы хорошо показывает, насколько плохо модель «пусть агент работает под учётной записью человека» подходит для автономных систем.
Кто разрешил роботу потратить мои деньги
Допустим, цифровая подпись доказала, что на сайт пришёл агент TravelBot-42. Информация почти бесполезна без ответа на вопрос, кто дал TravelBot-42 полномочия.
Здесь появляется делегирование. Пользователь не передаёт агенту пароль, банковскую сессию и безграничный токен доступа. Вместо этого пользователь подписывает ограниченное разрешение. Например, агенту можно искать билеты у определённых продавцов, купить один билет Москва - Санкт-Петербург стоимостью не выше 10 тысяч рублей, сделать покупку до вечера и не передавать полномочия другим агентам.
Логика такого разрешения в сильно упрощённом виде могла бы выглядеть так. Формат ниже иллюстративный и не является спецификацией AIP, AP2 или другого протокола.
{
"agent": "did:example:travelbot-42",
"principal": "user-credential-ref",
"scope": [
"ticket.search",
"ticket.purchase"
],
"max_amount": 10000,
"currency": "RUB",
"allowed_route": "Moscow-Saint-Petersburg",
"delegation": false,
"expires": "2026-08-25T20:00:00+03:00"
}Сайт проверяет подпись агента, затем проверяет разрешение пользователя, область действия, сумму, срок и другие ограничения. Даже если агент способен купить билет за 50 тысяч рублей, сервер должен отклонить операцию, потому что право на такую покупку пользователь не выдавал.
Платёжная индустрия уже строит именно такую инфраструктуру. FIDO Alliance сформировала рабочую группу по агентной аутентификации и развивает механизмы проверяемых пользовательских инструкций, аутентификации агентов и доверенного делегирования. В работу передали, в частности, Google Agent Payments Protocol и систему Verifiable Intent от Mastercard. FIDO прямо формулирует проблему как необходимость доказать, кто разрешил действие, при каких условиях и с какими ограничениями.
В AP2 центральную роль играют подписанные разрешения, или mandates. Агент может получить заранее заданные условия покупки, сформировать конкретную корзину, а затем связать разрешение на оплату именно с данной корзиной. Спецификация уже рассматривает два принципиально разных режима. В первом человек присутствует и подтверждает операцию. Во втором человека в момент покупки вообще нет, агент действует автономно в заранее разрешённых пределах.
Visa параллельно развивает Trusted Agent Protocol, где продавец получает возможность проверить криптографическую подпись агента, его намерение совершить коммерческую операцию и связанные с пользователем разрешения. Получается характерная картина. Единого победившего стандарта пока нет, зато практически все крупные проекты двигаются от бинарного «человек или бот» к тройке «идентичность, намерение, полномочия».
Именно здесь я вижу будущую замену CAPTCHA. Скорее всего, никакой одной «новой CAPTCHA» не появится. Вместо головоломки возникнет несколько невидимых слоёв доверия.
- Человек доказывает право выдавать полномочия. Для этого подойдут учётная запись, ключ доступа, цифровое удостоверение или механизм proof of personhood.
- Агент доказывает собственную идентичность. Запросы подписываются отдельным ключом, поэтому агент не растворяется внутри пользовательской сессии.
- Пользователь делегирует ограниченные права. Разрешение содержит срок, допустимые действия, бюджет, ресурсы и возможность дальнейшего делегирования.
- Сервис проверяет действие перед исполнением. Недостаточно знать агента, нужно сверить конкретную операцию с выданными полномочиями.
- Система сохраняет проверяемый журнал. При споре можно восстановить, какой агент действовал, какое разрешение предъявил и какую операцию выполнил.
Proof of personhood в такой архитектуре тоже не волшебная таблетка. Термин обычно означает доказательство существования уникального человека, а не обязательное раскрытие паспорта и настоящего имени. Разные системы предлагают государственные документы, подтверждения от других людей, учётные записи с репутацией, аппаратные ключи или биометрию.
У каждого варианта неприятный компромисс. Чем сильнее доказательство уникальности, тем выше риск превратить открытый интернет в пространство обязательной идентификации. Биометрия создаёт особенно чувствительные риски, потому что утёкший пароль можно поменять, а радужку глаза заменить нельзя. Централизованный удостоверяющий центр получает огромную власть решать, кого считать человеком. Децентрализованные варианты сталкиваются с атаками Сивиллы, продажей подтверждённых аккаунтов и проблемой «кто проверяет проверяющих».
PACT интересен именно попыткой разорвать связь между доверием и идентификацией. Сайт получает доказательство некоторого дефицитного или заслуженного доверия, но не обязательно узнаёт личность посетителя. Для обычного просмотра страниц подобной информации может оказаться достаточно. Для перевода денег или подписания договора уже нет.
Есть и ещё более неприятная проблема. Криптография умеет доказать, что действие совершил правильный агент. Криптография не умеет доказать, что агент принял правильное решение.
Если злоумышленник внедрил инструкцию в страницу, письмо или документ и заставил легитимного агента отправить секретные данные, цифровая подпись будет совершенно настоящей. Если пользователь выдал агенту слишком широкие права, безупречно работающая идентификация только поможет точно установить, какой авторизованный агент уничтожил базу. OWASP уже выделяет злоупотребление идентичностью и привилегиями как отдельный риск агентных приложений.
Поэтому следующий класс интернет-мошенничества, скорее всего, будет строиться не только на подделке личности. Злоумышленникам станет выгоднее красть делегированные разрешения, захватывать ключи агентов, подменять агента внутри цепочки, добиваться слишком широких полномочий или заставлять легитимного агента выполнить вредоносную операцию. В старой модели преступник пытался выдать себя за меня. В новой модели преступник может добиться, чтобы мой настоящий агент сам совершил нужное преступнику действие.
Что придёт на смену CAPTCHA
Можно ли сейчас отличить ИИ-агента от человека?
Надёжно определить природу клиента только по поведению всё сложнее. Сайты используют совокупность сигналов, включая свойства браузера, сеть, репутацию, поведение и признаки автоматизации. Криптографическая идентификация решает другую задачу и позволяет легитимному агенту самому доказать, кто его оператор.
Почему ИИ может проходить CAPTCHA?
Современные зрительно-языковые модели умеют распознавать объекты, читать искажённый текст, понимать инструкции и управлять интерфейсом. CAPTCHA больше не гарантирует прежнего разрыва между способностями человека и программы.
Что такое proof of personhood?
Proof of personhood представляет собой способ подтвердить, что за цифровым субъектом стоит уникальный реальный человек. Такая проверка не обязана раскрывать имя, однако сильная устойчивость к созданию множества фальшивых личностей почти всегда требует источника доверия или дефицитного подтверждения.
Что такое идентификация ИИ-агента?
ИИ-агент получает отдельный идентификатор и криптографический ключ. Агент подписывает действия, а сервис проверяет подпись по открытому ключу. Такая схема позволяет отличить конкретного известного агента от анонимного скрипта и не заставляет агента притворяться пользователем.
Может ли ИИ-агент покупать товары без человека?
Технически такой сценарий уже предусмотрен развивающимися платёжными протоколами. Пользователь заранее задаёт условия и подписывает разрешение, после чего агент может выполнить покупку в установленных пределах без дополнительного подтверждения в момент оплаты.
Заменит ли Agent Identity Protocol CAPTCHA?
Нет. AIP решает идентификацию, авторизацию и делегирование, тогда как CAPTCHA прежде всего помогает бороться с автоматизированным злоупотреблением. Кроме того, существующие AIP пока остаются индивидуальными Internet-Draft, а не утверждёнными стандартами IETF.
Исчезнут ли картинки со светофорами и гидрантами?
Постепенно их роль, вероятно, будет сокращаться, но полностью CAPTCHA в ближайшей перспективе не исчезнет. Головоломки останутся резервным сигналом против дешёвой автоматизации, пока браузеры, сайты и агенты не договорятся о более удобной инфраструктуре доверия.
Поэтому вопрос «как доказать, что ты человек в интернете» уже начинает устаревать. Иногда сайту вообще не нужен человек перед экраном. Сайту нужно убедиться, что автоматизированное действие имеет понятное происхождение, ограниченные полномочия и проверяемую связь с тем, кто эти полномочия выдал.
CAPTCHA пыталась определить природу посетителя. Следующее поколение защиты будет проверять право посетителя действовать. Разница кажется небольшой, но для интернета с автономными ИИ-агентами она меняет почти всё.
