Нет, с ИИ-агентами так не получается.
Однако, обо всем по порядку.
В этом блоге мы много раз обращались к теме ИИ-агентов, стремительный прогресс которых может существенно изменить положение дел для тех, кто предоставляет услуги верификации всего на свете.
Нельзя сказать, что успехи ИИ-агентов опережают график, предсказанный многочисленными футурологами и прорицателями, условно говоря «кокотайлами». Нет, темпы развития примерно соответствуют предсказаниям. Но в ходе практической работы вскрываются все новые проблемы, трудности и методы их решения и обхода, которые не были видны предсказателям длинных трендов.
Конкретно в нашей отрасли услуг верификации появилась новая аббревиатура KYA (Know Your Agent), за которой много чего скрывается.
Для начала заметим, что сама аббревиатура — рождение маркетингового гения и сразу сбивает с толку. Она построена по образцам KYC (клиента) и KYB (бизнес), но переворачивает субъектно-объектную цепочку в обратную сторону. KYC и KYB — это, условно говоря, призыв к сервисным компаниям, которые предоставляют прикладные услуги клиентам и бизнесам. Для ответа на этот вызов они обращаются к профессионалам, вроде нашей компании IDX, отдавая эту функцию обеспечения защиты от фрода на аутсорсинг.
Призыв «Знай своего агента» вообще-то бессмысленный, тот, кто «нанял» агента, должен знать его по определению, поскольку сам должен его обучать и инструктировать для выполнения возложенных на него задач. За аббревиатурой KYA скрывается новый вызов для сервисных компаний — распознавать в онлайне обращения ИИ-агентов и принимать решения о возможности предоставления им сервиса. Поскольку ИИ-агенты пока еще своей субъектности не имеют, они должны нести с собой все верительные грамоты (credentials) своего принципала/суверена, который нанял его для выполнения задания. Таким образом, своим агента вправе называть пославший его, а не тот сервис провайдер, к кому агента послали. Правильнее было бы использовать призыв «Знай их агентов» (KTA), но уже поздно. Маркетинг такой маркетинг. С учетом этого буквоедского замечания будем продолжать использовать уже ушедшую в народ аббревиатуру.
Возможно, кто-то скажет, что рано пока писать о верификации ИИ-агентов. Даже объем этого понятия пока не устоялся. И действительно, с помощью группы наших ассистентов, которые скрываются под псевдонимом Perplexity, мы зафиксировали, что под общим названием «верификация» развиваются как минимум пять разных механизмов: регистрация технической идентичности, привязка к человеку или организации, делегирование полномочий, проверка результата и накопление репутации. Ключевое слово — как минимум. Действительно, термин не устоялся, но бежать впереди паровоза приятно и полезно — в любом случае прослывешь буревестником прогресса, а если что-то угадаешь — попадешь в «кокотайлы». Поэтому продолжим.
Мы сначала посмотрим, что делается в части разработки стандартов, в которых понятие верификации ИИ-агентов будет определено строго, а потом посмотрим, что делают лидеры рынка услуг верификации, пытаясь отнести предмет рассмотрения к одной из пяти перечисленных категорий, там глядишь, и расширим этот список.
Теория вопроса
В теоретической части видны два главных тренда.
ERC-8004 — Trustless Agents.
Технический стандарт, соавторами которого стали люди из MetaMask, Ethereum Foundation, Google и Coinbase. Стандарт сформирован на платформе публикации Ethereum и естественным образом входит в семейство спецификаций для смарт-контрактов и стандартизированных механизмов в Ethereum; ERC-20 (токены) и ERC-721 (NFT) — самые знакомые примеры. Технически это спецификация интерфейсов смарт-контрактов на EVM (Ethereum Virtual Machine).
Стандарт описывает, как должны быть устроены три ончейн-реестра (Identity, Reputation, Validation) — то есть набор интерфейсов языка описания смарт-контрактов Solidity в среде EVM, которые любой желающий может развернуть в сети Ethereum (и в идеале — везде, где совместима EVM).
То есть, ERC-8004 создает открытый on-chain-слой для обнаружения агентов, их идентичности, репутационных сигналов и внешней валидации. При этом, ERC-8004 — не сертификат безопасности, а инфраструктура реестров. Регистрация не подтверждает реальную личность владельца, законность полномочий или неизменность модели.
Идентификационный реестр построен на ERC-721 — каждый агент получает уникальный agentId, то есть стандарт технически наследует и совместим с уже существующими стандартами ethereum-экосистемы (ERC-721, и в перспективе — с ERC-20/x402 для платежей).
Здесь следовало бы написать лирическое отступление о коде статуса 402 в HTTP. Код 404 все знают, а вот про код 402 я узнал сравнительно недавно и восхитился дальновидностью разработчиков HTTP, которые еще в самом первом RFC2068 в далеком 1997 году зарезервировали этот код с пометкой «Для будущего использования». Так он с этим клеймом и кочевал до наших дней через все версии спецификации HTTP вплоть до последнего RFC9119 (2022 год). И только теперь с x402 от Coinbase и подобными протоколами это будущее наконец наступило применительно к платежам между AI-агентами. Но это отступление от темы и дань моему далекому, но не позорному прошлому, когда мы делали первую в России платформу для процессинга смарт-карт для давно уже не существующих банков.
Репутационный реестр позволяет публиковать числовые отзывы, теги, endpoints, URI и хеш дополнительных данных. Расчет итогового доверия оставлен внешним агрегаторам; защита от Sybil-атак и оценка надежности автора не стандартизированы.
Реестр валидации нужен для того, чтобы агент или клиент мог инициировать проверку результата, а валидатор — записать оценку и ссылку на доказательства. Возможны повторное исполнение со ставкой (stake-secured re-execution), zkML доказательства, TEE (Trusted Execution Environment) или экспертная проверка, но ERC-8004 не определяет квалификацию валидатора, экономику staking/slashing и правила разрешения споров (dispute resolution).
Этим стандартом не определяется целый ряд вещей, которые очень хотелось бы иметь для постановки и выполнения задач верификации ИИ-агентов:
Принадлежность владельца к юридическому лицу и его полномочия представлять организацию.
Соответствие агента требованиям AML/CFT, EU AI Act или ISO/IEC 42001.
Право распоряжаться банковским счетом или совершать конкретный платеж.
Неизменность модели, системного промпта, набора инструментов и endpoint.
Безопасность от prompt injection, tool poisoning и утечки секретов.
Действующий мандат пользователя на конкретное действие.
Так что, продолжаем наблюдать за этим треком развития технических стандартов.
FIDO Alliance
FIDO (Fast IDentity Online) Alliance — это старинная организация, которая разрабатывает стандарты аутентификации и выпускает их спецификации аж с 2013 года. Понятно, что в ней сидят все главные игроки рынка, но есть и неожиданные — TikTok, например. В каком-то смысле это концептуальный предшественник движению самостийной идентификации (Self-sovereign identity), о которой мы здесь писали.
Здесь надо бы написать еще одно лирическое отступление о том, как FIDO и SSI дополняют друг друга. Сопоставление их деятельности многое проясняет. Но это тоже отступление в сторону.
В интересующем нас направлении верификации ИИ-агентов FIDO строит модель с участием человека: сервис должен проверить, кто уполномочил агента, какие инструкции были выданы и соответствует ли конкретное действие пользовательскому намерению.
FIDO Alliance сформулировала три рабочих направления: проверяемая инструкция пользователя, аутентификация агента и делегирование коммерческих платежей (trusted delegation for commerce). Цель — дать запрашивающей стороне проверяемый ответ, действительно ли агент действует от имени аутентифицированного пользователя и в установленных пределах.
Проверяемая инструкция (verifiable user instructions)
Мандат должен связывать пользователя, агента и разрешенное действие. Практически значимые поля: тип операции, сумма и валюта, получатель или категория, срок действия, случайный код (nonce), условия пошаговой аутентификации и возможность отзыва.
Аутентификация агента (agent authentication)
Сервису необходимо отличать непосредственное действие пользователя от автономного запроса агента и проверять удостоверяющие данные агента без передачи ему пользовательского passkey. Сам факт аутентификации не должен давать неограниченные полномочия: действие проверяется против мандата.
Расчеты между агентами (trusted delegation for commerce)
Платежный сценарий требует связать исходное намерение и итоговую транзакцию, которые могут различаться по времени и контексту. FIDO рассматривает вклад Google AP2 (Agent Payments Protocol) и Mastercard Verifiable Intent, а также работу платежной группы с участием Mastercard и Visa.
Практика лидеров отрасли
Теперь разберемся, что же делают лидеры рынка, которые никогда не ждут окончательного оформления стандартов и тоже бегут впереди паровоза. На то они и лидеры.
Sumsub
Мы всегда очень внимательно следили за тем, что делает компания SumSub и старались не отставать от этого явного лидера.
Ещё в июне Sumsub выпустила пресс-релиз о том, что стала первой платформой верификации, которая даёт ИИ-агентам — включая Claude, ChatGPT и другие модели — доступ не только к повседневным операциям, но и ко всему слою конфигурации платформы. Технически это MCP (Model Context Protocol) — интеграция плюс набор open-source «agent skills»: ИИ-агент может взять комплаенс-политику компании (PDF с таблицами рисков и условной логикой) и автоматически развернуть из неё полностью настроенную среду Sumsub — то, что раньше делалось руками за дни, теперь занимает минуты. Чувствительные действия при этом идут через изолированный sandbox и требуют человеческого одобрения.
А 21 июля Sumsub выпустила второй, куда более концептуальный релиз: компания объявила о трансформации в первую на рынке AI-Powered Trust Infrastructure. Формулировка ключевая — это уже не «мы улучшили продукт», а «мы теперь другая категория продукта», то есть, компания совершила решительный разворот, заодно переделав и свой сайт до неузнаваемости.
Cуть разворота объясняется следующим образом. Доверие изменилось — бизнес больше не может ограничиваться верификацией клиента только в момент онбординга, вместо этого нужно непрерывно понимать риск на протяжении всего взаимодействия. Отсюда и смена рамки: Trust Infrastructure — следующая эволюция комплаенс-операций, переход от инструментов онбординга и антифрода к единой системе, которая непрерывно оркестрирует верификацию, AML-комплаенс и риск-оценку.
Практическая мотивация тоже озвучена прямо: без такой инфраструктуры компаниям нужно иметь 5–9 отдельных инструментов для управления identity, fraud и compliance, а запуск в новой юрисдикции может занимать до полугода. То есть разворот подаётся как консолидация фрагментированного рынка частных решений в единый слой.
Сайт компании формулирует ещё резче — почти философски для B2B-лендинга: «Trust infrastructure — это слой принятия решений позади цифрового доверия. Он связывает сигналы, workflows, правила, кейсы, отчёты и ИИ, которые помогают командам решать, кому доверять, когда действовать и как оставаться в рамках комплаенса».
Sumsub одновременно делает три вещи:
Строит инфраструктуру, которая верифицирует людей и бизнесы для машин (агенты настраивают комплаенс за людей).
Позиционирует себя как «слой принятия решений о доверии» — то есть претендует на роль арбитра доверия вообще, не только проверок для идентификации.
При этом пускает ИИ-агентов в свой конфигурационный слой — то есть агенты не просто объект верификации, а инструмент, который выстраивает саму систему верификации.
Это создаёт интересный виток: кто верифицирует агента, который конфигурирует систему верификации людей и агентов? Компания подчёркивает наличие человека в контуре (sandbox + одобрение), но сам факт, что операционная логика доверия делегируется модели, а не просто исполняется ею — это и есть та концептуальная развилка, которая интересна нам в контексте верификации ИИ-агентов как таковой.
Persona
Persona даёт ещё более чистый и явный кейс, чем Sumsub — и, что важно для нас, это принципиально другая философия «верификации агентов».
Уже в январе 2026-го Persona прямо формулирует свою миссию как построение верифицированного identity-слоя для эры агентного ИИ. Основатель и CEO Рик Сонг пишет, что идентичность перестала быть точечной проверкой безопасности и стала фундаментальным слоем, который помогает организациям понимать, кто стоит за каждым онлайн-взаимодействием — неважно, агент это или человек.
Дальше это выросло в отдельный продукт — Know Your Agent (KYA), который у Persona теперь стоит в одном ряду с KYC/KYB как самостоятельная категория.
Ключевая философская развилка — и тут принципиальное различие с Sumsub — Persona явно формулирует три вопроса, на которые должен отвечать любой процесс KYA:
агент это или человек;
если агент — кто стоит за ним;
и можно ли доверять этим людям.
То есть агент как таковой у Persona не верифицируется как самостоятельная сущность — компания сознательно возвращает вопрос доверия к человеку. Показательна фраза с их же страницы: «Корпоративные процессы и коммерция всегда были укоренены в этом вопросе. Агенты меняют то, как вы на него отвечаете, но не меняют сам вопрос».
Это принципиально иной ход, чем у Sumsub. У Sumsub агент — это инструмент, который получает доступ к конфигурационному слою инфраструктуры доверия (агент настраивает комплаенс за человека-оператора). У Persona агент — это объект верификации, который принципиально не может быть верифицирован сам по себе: система всегда должна «пробить» его до ответственного человека. Технически это реализуется через привязку агента к верифицируемой идентичности человека на этапе онбординга и повторную реверификацию при рискованных действиях в реальном времени.
Продуктовый слой под этим такой.
Три «примитива», которые Persona продаёт под зонтиком KYA:
Проверка государственного ID и селфи-liveness — чтобы «привязать агента к реальному человеку»;
Relay — минимальный набор PII (прямых и косвенных идентификаторов), способ доказать «человечность» без полной идентификации;
Компоненты фонового наблюдения (passive signals) за устройством пользователя, его сетевыми характеристиками и поведенческими шаблонами для выявления процедур, доверенных агенту.
Компания также активно участвует в институциональной повестке: у неё есть публичные комментарии в NIST (Национальный институт стандартов США) о том, что безопасность ИИ-агентов начинается с верификации человеческой идентичности, то есть Persona продвигает свою модель не только продуктово, но и как регуляторную рамку.
Для полноты картины стоит упомянуть, что в феврале 2026 у Persona была утечка: специалист по безопасности обнаружил публично доступный фронтенд правительственного дашборда (FedRAMP-авторизованный эндпоинт), включая данные о том, что платформа умеет подавать SAR (Suspicious Activity Report) в FinCEN (Financial Crimes Enforcement Network) и STR (Suspicious Transaction Report) в FINTRAC (Financial Transactions and Reports Analysis Centre of Canada). Это не отменяет концептуального разворота, но хорошо иллюстрирует обратную сторону позиционирования себя как «инфраструктуры доверия»: чем шире претензии на инфраструктурность, тем больнее бьёт любой инцидент безопасности — а такая инфраструктура неизбежно становится привлекательной целью и вызывает вопросы о слежке (в статьях на специализированном новостном сайте Biometric Update тема слежки в контексте бизнеса компании Persona поднимается регулярно).
Veriff
Видение Veriff — это вариант модели Persona, но со своим акцентом.
У Veriff есть отдельный программный текст CTO Хьюберта Бегеля именно про агентную коммерцию, и рамка там предельно ясная: «Проблема не в ИИ. Проблема — в анонимном эккаунте за ним». Veriff вводит понятие «Level 0 agentic readiness» — структурный отказ терпеть анонимные эккаунты — и формулу-лозунг: «каждое действие ИИ-агента должно оставаться прослеживаемым до верифицированного человеческого источника». Это практически дословно та же логика, что у Persona (KYA как способ всегда свести агента к ответственному человеку), только Veriff даёт этому более сильную временну́ю рамку: не разовая проверка при онбординге, а «пронизывающая верификация (pervasive verification)» — верификация должна сопровождать эккаунт весь его жизненный цикл, потому что агент может исполнить сотни транзакций от имени скомпрометированной личности до первого триггера.
Ещё показательная деталь: у Veriff есть отдельный материал «Who's verifying your verifier (Кто верифицирует верификатора)» — они прямо ставят вопрос о необходимости верифицировать самого поставщика услуг верификации, что может стать отдельным любопытным нюансом (мета-верификация как следующий виток).
Onfido/Entrust
Сам Onfido как бренд собственной агентной риторики почти не имеет — после поглощения его компанией Entrust в 2024-м, он функционирует как «Entrust IDV», компонент внутри более широкого портфеля. Именно на уровне Entrust разворачивается принципиально иная логика. Компания недавно открыла Agentic AI Trust Accelerator, и формулировка их CEO любопытна. Тони Болл настаивает, что предприятиям нужно относиться к ИИ-агентам как к новому классу цифровой идентичности, а их же COO Анудип Пархар называет результат работы «trust plane for autonomous AI (плоскость доверия для автономного ИИ)».
Ключевое отличие такого подхода в том, что Entrust заходит в эту тему не со стороны KYC/биометрии, а со стороны своего ключевого бизнеса — PKI, сертификаты, управление ключами и секретами. То есть агент здесь получает собственные машинные учётные данные (аналог TLS-сертификата для сервера или mTLS для микросервисов), а не сводится обратно к верифицированному человеку через селфи и документ. Это принципиально другая онтология: не «кто стоит за агентом», а «у агента есть собственная криптографически проверяемая идентичность как у отдельного актора».
Это, кстати, смыкается с тем, что параллельно делают платёжные сети — Visa со своим Trusted Agent Protocol и Mastercard/Google с Verifiable Intent, — где акцент так же на криптографически подписываемых полномочиях (delegated authority, verifiable credentials), а не на «дожать до человека через IDV». FIDO Alliance тоже сейчас формирует рабочую группу именно по агентной аутентификации в этой парадигме.
Итого — вырисовывается три архетипа бизнес активности в области верификации ИИ.
Sumsub — агент как оператор/пользователь инфраструктуры доверия (агент настраивает комплаенс за человека).
Persona / Veriff — агент как объект, который принципиально нельзя верифицировать самостоятельно: система обязана прослеживать его до ответственного человека (KYA, «анонимность — реальная угроза», непрерывная реверификация).
Entrust (через Onfido) / Visa / Mastercard / FIDO — агент как самостоятельный субъект машинной идентичности со своими криптографическими учетными данными (credentials), без обязательной привязки к живому человеку в моменте действия (хотя делегирование полномочий от человека, конечно, где-то в цепочке подразумевается).
Третий архетип принципиально отличается от второго тем, что не настаивает на «человек должен быть виден на каждом шаге» — вместо этого он формализует полномочия агента как отдельного узла доверия, ближе к традиционной модели machine identity / PKI, чем к традиционной модели IDV с биометрией. Эта развилка — «верифицировать агента через человека» vs «верифицировать агента как самостоятельную сущность» — кажется куда более фундаментальным водоразделом на рынке, чем разница между Sumsub и Persona.
Парфянский выстрел
А теперь, в завершение, сделаем важное и ответственное наблюдение.
Агент, действующий строго в рамках комплаенса, может быть при этом полностью злонамеренным.
И это не частность, а структурный слепой пробел всей инфраструктуры доверия, как её строят Sumsub, Persona, Veriff и даже Entrust.
Все инструменты, которые мы разбирали, отвечают на вопросы типа «реальна ли эта личность?», «соответствует ли эта транзакция статистически нормальному паттерну?», «есть ли совпадение с санкционным списком?», «авторизован ли этот агент действовать от имени этого принципала?».
Это вопросы процедурного соответствия (conformance) — верифицируется идентичность и полномочие, но не цель.
Агент, который абсолютно честно верифицирован, действует строго в рамках делегированных ему полномочий, не превышает лимиты, не палится ни на одном AML-триггере — и при этом ведёт, скажем, скоординированную дезинформационную кампанию, манипулирует рынком через легальные с виду сделки или методично социально-инженерит цели в рамках разрешённых коммуникационных каналов — пройдёт вообще все проверки инфраструктуры доверия без сучка и задоринки. Комплаенс — это пол, а не потолок: он ловит известные паттерны вреда (отмывание, санкции, кража личности), но ничего не говорит о содержательной цели действия.
Тут прослеживается ровно та же развилка, что в AI safety между аутентификацией/авторизацией (кто это, действует ли он в рамках выданных ему прав) и верификацией поведенческих шаблонов и намерения (что он на самом деле собирается делать и хорошо ли это). Вся индустрия верификации ID — Sumsub, Persona, Veriff, Entrust — целиком живёт в первом слое. Второй слой — верификация намерения/целесообразности действия агента относительно интересов его же собственного суверена или третьих сторон — вообще не их компетенция, и, честно говоря, непонятно, разрешима ли эта задача теми же средствами (биометрия, документы, PKI-сертификаты), которыми решается первая.
Индустрия «инфраструктуры доверия» массово переизобретает себя вокруг проблемы идентификация/авторизация, в то время как реальный риск агентной автономии лежит в зоне верификации намерений и их допустимости, которую весь этот рынок структурно не решает и, возможно, не может решить в своей нынешней парадигме.