OAuth для агентов: как ИИ доказывает, что это он, а не вы

Осенью 2024 года Anthropic выпустила Model Context Protocol — открытый способ подключать модели к внешним инструментам и данным. Весной 2025-го спецификацию MCP дополнили разделом про авторизацию, опирающимся на OAuth 2.1. Почти одновременно Google представила Agent2Agent (A2A) — протокол, где агенты договариваются между собой, и там тоже фигурируют OAuth-схемы и API-ключи. Общий сюжет один: агент хочет дёрнуть чужой сервис от вашего лица, а тот сервис хочет понять, кому вообще выдавать доступ и на что.

Проблема не в том, что OAuth плохой. Проблема в том, что его придумали для сценария «человек нажал кнопку Разрешить в браузере». У агента нет браузера, нет человека рядом каждую секунду и часто нет чёткой границы, где заканчиваются его полномочия и начинаются ваши.

Почему обычный OAuth ломается на агентах

Классический OAuth 2.0 держится на редиректе: приложение отправляет вас на страницу провайдера, вы логинитесь, видите список запрашиваемых прав и жмёте согласие. Этот момент — consent — и есть точка, где живой человек берёт на себя ответственность.

Агент выпадает из этой схемы сразу по нескольким причинам:

• Некому нажимать кнопку. Агент работает в фоне, ночью, в цикле. Интерактивный consent на каждый вызов убивает саму идею автономности.
• Права слишком широкие. Пользователь один раз выдал доступ «читать почту», а агент теперь читает её тысячу раз в день по собственной логике. Отозвать доступ к одному сценарию, не сломав остальные, нечем.
• Непонятно, кто действует. Запрос пришёл от агента, но от вашего имени. Если он что-то удалил — это сделали вы или программа, которой вы делегировали часть полномочий? Аудит-лог показывает один токен на двоих.
• Секреты негде хранить. Агент, живущий в чате или в браузерном расширении, — это publicclient без надёжного места для client secret.

Токен, выданный человеку, отвечает на вопрос «кто вы». Токен для агента должен отвечать на другой: «кто вас послал, что именно вам поручили и до какого момента».

Что предлагает индустрия

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

OAuth 2.1 и то, что вокруг него

OAuth 2.1 — это консолидация лучших практик OAuth 2.0: обязательный PKCE, отказ от неявного грант-флоу, более строгие требования к редиректам. На него ссылается спецификация авторизации MCP. Отдельно существуют механизмы, которые пытаются закрыть именно машинные сценарии:

• Client Credentials Grant — поток без пользователя вообще, когда сервис ходит к сервису по своим учётным данным. Подходит там, где агент действует не от вашего лица, а сам по себе.
• Token Exchange (RFC 8693) — обмен одного токена на другой, часто с сужением прав. Полезен, когда агент получает узкий токен под конкретную задачу вместо широкого «на всё».
• Dynamic Client Registration (RFC 7591) — регистрация клиента на лету, без ручного заведения в консоли. MCP-авторизация опирается на неё, чтобы агент мог представиться серверу без предварительной настройки.

Кто есть кто

Ниже — грубая карта того, что сейчас применяют. Спецификации меняются, поэтому детали сверяйте с первоисточником.

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

Три проблемы, которые ещё не решены

Гранулярность прав

Человеку хватает крупных scope: «почта», «календарь». Агенту нужны права, привязанные к задаче и времени: «прочитать письма за сегодня с меткой Счета, один раз, до 20:00». OAuth-scope таким не был никогда, и попытки натянуть эту гибкость упираются в то, что каждый провайдер описывает права по-своему.

Цепочка делегирования

Вы поручаете агенту, агент дёргает второго агента, тот идёт в API банка. На каждом звене должно быть видно, откуда растут полномочия. Token Exchange умеет передавать факт делегирования, но выстроить сквозную цепочку из трёх-четырёх участников с внятным аудитом — пока ручная работа, а не готовый стандарт.

Отзыв и срок жизни

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

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

Тема выглядит инфраструктурной, но касается вполне конкретных людей.

• Разработчику, который делает агента поверх чужих API, — это уже сейчас. Как только ваш агент ходит в Gmail, GitHub или платёжку от имени пользователя, вопрос «каким токеном и с какими правами» стоит перед вами напрямую.
• Команде, поднимающей MCP-сервер, — тоже актуально: раздел авторизации в спецификации придётся читать и реализовывать, а не откладывать.
• Платформам с чувствительными данными (финтех, здравоохранение) — стоит следить, но не спешить пускать сторонних агентов до тех пор, пока не выстроен внятный отзыв и аудит.
• Продукту с одним пользователем и одним ключом «на всё» — можно жить на API-ключе и не городить OAuth-огород. Сложность оправдана там, где есть делегирование между разными сторонами.

Если вы просто пользуетесь готовым ассистентом внутри одного сервиса — вас это касается опосредованно. Но полезно знать, какие права вы выдали и как их отозвать: настройки доступа к сторонним приложениям есть в аккаунте почти любого крупного провайдера.

Сноска. Агент здесь — не любая программа с ИИ, а система, которая сама решает, какие шаги предпринять и какие инструменты вызвать для достижения цели, а не просто отвечает на один запрос. Именно автономность действий и делает вопрос авторизации острым: агент дёргает API без человека в контуре на каждом шаге.