Сертификат доверия для ИИ-агентов: аналог SSL уже собирают

В 2025 году агентные системы перестали быть демо. Автономные ИИ-агенты бронируют билеты, оформляют возвраты, ходят по сторонним API и совершают платежи. И тут выяснилось: на другом конце соединения нет способа понять, кто именно пришёл — легитимный агент банка, самопальный скрипт или подделка, выдающая себя за корпоративного бота. Тот самый вопрос, который для сайтов закрыл SSL/TLS в 1990-х, для агентов пока открыт.

Речь идёт о нескольких параллельных инициативах. Anthropic и OpenAI продвигают протоколы взаимодействия агентов с внешними системами (MCP¹ у Anthropic, инструменты и function calling у OpenAI). Google в 2025 году представил протокол Agent2Agent (A2A) для общения агентов между собой. Но ни один из них пока не решает главное: как одна сторона криптографически убеждается, что вторая — это доверенный агент с проверяемым происхождением, а не имперсонация.

Что вообще значит «сертификат доверия» для агента

Аналогия с SSL точна лишь наполовину. SSL-сертификат подтверждает две вещи: что вы соединяетесь именно с тем доменом, который видите в адресной строке, и что канал зашифрован. Удостоверяющий центр (CA) выступает третьей стороной, которой доверяют браузеры.

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

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

SSL закрывает первый пункт. Второй и третий требуют механизмов, ближе к OAuth-токенам с делегированием прав, чем к классическому сертификату сайта.

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

Кто и что уже строит

Единого стандарта на сегодня нет. Есть набор кирпичей, часть из которых заимствуют из веб-безопасности, часть придумывают заново.

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

Почему нельзя просто взять SSL как есть

Веб-PKI строился вокруг доменных имён — стабильных, публичных, привязанных к юрлицу. У агентов нет доменов. Они эфемерны: один пользователь может запустить сотню экземпляров агента на час. Классический удостоверяющий центр, выдающий сертификат на два-три года, тут не подходит по скорости и по модели жизненного цикла.

Плюс вопрос отзыва. Если агент скомпрометирован, доверие нужно отозвать за секунды, а не ждать обновления списков отзыва, как у устаревших CRL. Это толкает индустрию к короткоживущим токенам и проверке в реальном времени, а не к «сертификату на бумаге».

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

Пригодится:

• Финтеху и банкам, чьи агенты инициируют платежи: без проверяемой идентичности каждый автоматический перевод — риск фрода.
• Маркетплейсам и API-провайдерам, которые хотят пускать агентов-покупателей, но отличать их от парсеров и ботнетов.
• Корпоративным ИТ-отделам, разворачивающим внутренних агентов: mTLS и токены делегирования уже применимы внутри периметра прямо сейчас.
• SaaS-платформам, строящим агентные интеграции между собой — им нужен общий язык доверия.

Пока не критично:

• Тем, кто гоняет агента локально для себя — саммаризация писем, разбор своих файлов. Внешней стороне доказывать нечего.
• Внутренним пилотам без доступа к деньгам и персональным данным: там достаточно обычной авторизации по API-ключу.
• Разработчикам, у которых агент — это тонкая обёртка над одной моделью без права действовать вовне.

Что делать бизнесу сейчас, не дожидаясь стандарта

1. Выдавайте агентам отдельные идентичности, а не общий сервисный аккаунт — так вы сможете отозвать доступ точечно.
2. Ограничивайте полномочия токена до минимально необходимых: чтение вместо записи, лимит на сумму, срок жизни в минутах.
3. Логируйте каждое действие агента с привязкой к его идентичности — это ваша единственная опора при разборе инцидента.
4. Для внутренних сценариев внедряйте mTLS уже сегодня: технология зрелая и не ждёт нового стандарта.
5. Следите за протоколами A2A и MCP, но не завязывайтесь на один вендорский формат идентичности, пока он не устоялся.

Единый «сертификат доверия для агентов» с общепризнанным удостоверяющим центром — вопрос не месяцев, а нескольких лет и согласия конкурирующих вендоров. Пока же безопасность агентных систем собирается вручную из OAuth, mTLS и дисциплины логирования.

¹ MCP (Model Context Protocol) — открытый протокол Anthropic, описывающий, как модель подключается к внешним источникам данных и инструментам. Отвечает за то, как агент получает контекст и вызывает функции, но сам по себе не решает задачу взаимной проверки доверия сторон.