Попробуй украсть токен
Сегодня агенты ходят в сервисы с API-ключами и OAuth-токенами «на предъявителя». Кто держит токен, тот и пользуется. Переключи режим и нажми кнопку.
Шесть действующих лиц
Нажми на любого участника, чтобы увидеть, чем он занят и с кем общается. В каждом конкретном случае участвуют не все.
Четыре документа и один пропуск-на-сессию
Все токены AAuth живут недолго и подписаны тем, кто их выдал. Цвет полоски показывает, кто выдаёт документ.
cnf или agent_jkt). Если запрос не подписан этим ключом, документ недействителен. Поэтому красть его бесполезно.
Посмотри, как это работает, шаг за шагом
Выбери режим и жми «Дальше» (или стрелки на клавиатуре). Режимы отличаются тем, что сервис в итоге знает. Один сервис может использовать разные режимы для разных адресов.
Режимы листаются вбок →
Сколько сервис узнаёт в каждом режиме
Чем выше столбик, тем больше сервис знает перед тем, как ответить. Нажми на столбик, чтобы открыть режим.
Агенту не нужно знать сервис заранее
Агент всегда делает одно и то же: отправляет запрос, читает заголовок AAuth-Requirement («что мне от тебя нужно»), выполняет требование и повторяет. Первый запрос к сервису и есть регистрация.
Ты даёшь агенту задание, Person Server за ним присматривает
Миссия описывает задачу обычным текстом. Агент её предлагает, ты одобряешь. Дальше Person Server сверяет с миссией каждое действие агента и записывает всё в журнал. Миссии необязательны. Сыграй за человека.
Журнал миссии
Нет миссии- Пока пусто
Что ещё продумано
Субагенты
Главный агент может запускать помощников. У каждого свой паспорт с пометкой parent_agent. Сами к Person Server они не ходят: пропуска для них берёт родитель. Глубина только один уровень.
Цепочки вызовов
Сервис, которому для ответа нужен другой сервис, сам становится агентом со своим паспортом. Права человека передаются по цепочке, и Person Server видит каждое звено.
Нет «вечных» токенов
Паспорт агента живёт до 24 часов, токен личности до часа, заявка до 5 минут. Refresh-токенов нет: когда пропуск истёк, агент снова спрашивает сервис, и у сервиса есть право сказать «нет».
Отзыв каскадом
Отозвал токен личности, и Person Server сообщает об этом сервису и серверу доступа. Тот, в свою очередь, гасит все пропуска, выданные по этому токену.
Приватность
Для каждого сайта у тебя свой псевдоним (sub). Сайты не могут сопоставить тебя между собой. В режимах 3–5 сервис даже не видит, какой именно агент пришёл, поэтому не может пускать «только агентов от компании X».
Честное окно согласия
Person Server обязан визуально отделять слова агента («мне нужно, потому что…») от того, что заявил сам сервис. Агенту выгодно, чтобы ему поверили, и ты должен видеть, где чьи слова.
Внедрять можно по частям
Каждая сторона подключается сама по себе. Сервис может начать с проверки подписи вместо API-ключа. Тот, кто AAuth не знает, просто игнорирует новые заголовки, и всё старое продолжает работать.
Целое семейство черновиков
Рядом с основным протоколом развиваются отдельные документы: Budgets (лимиты трат агента), Events (уведомления агентам), R3 (права в терминах MCP, OpenAPI, gRPC, GraphQL) и Bootstrap (как агент получает паспорт).
Чем это лучше OAuth для агентов
AAuth не заменяет OAuth целиком. Сервис может спрятать свой существующий OAuth внутрь сессионного токена, а Person Server может логинить людей через OpenID Connect.
| OAuth 2.0 и API-ключи | AAuth | |
|---|---|---|
| Кто такой клиент | ✕client_id выдаёт каждый сервер свой: id в Google ничего не значит в GitHub | ✓Один ID aauth:имя@домен, его может проверить кто угодно |
| Регистрация | ✕Заранее на каждом сервере (или Dynamic Client Registration, как в MCP) | ✓Не нужна: первый запрос и есть регистрация |
| Кража токена | ✕Токен на предъявителя: кто украл, тот и вошёл | ✓Токен привязан к ключу, каждый запрос подписан |
| Копии агента | ✕Один client_id на всё приложение | ✓ID у каждой запущенной копии: отозвать можно одну |
| Подлинность сервиса | ✕Сервис криптографически не подтверждает, кто он | ✓Сервис подписывает заявку (resource token) |
| Контроль за агентом | ✕Нет | ✓Миссии, разрешения на действия, аудит, вопросы человеку |
| Чей сервер решает | ✕Всегда сервер владельца ресурса | ✓Твой Person Server и сервер доступа сервиса договариваются между собой |
| Продление | Refresh-токены | Нет refresh: каждый раз заново, у сервиса есть право голоса |
Частые вопросы
Это уже можно использовать?
Попробовать можно: есть SDK для TypeScript, .NET, Python и Go, расширение для Keycloak, готовый Person Server и демо-песочницы (AAuth Explorer, AAuth Web Agent). Но это черновик, а не стандарт. Между версиями меняются названия полей и даже число режимов, так что для боевых систем пока рано.
Это замена OAuth?
Нет, скорее надстройка для мира агентов. Обычные приложения с OAuth продолжат работать как раньше. Сервис может спрятать свой OAuth-токен внутрь сессионного токена AAuth, а Person Server может логинить людей через OpenID Connect.
Что изменится для обычного человека?
Появится место, где видно всех твоих агентов: какие подключены, на каких устройствах, какие у них задания и что они уже сделали. Там же можно ответить на вопрос агента, разрешить или запретить действие и отозвать доступ. Это и есть Person Server.
А если украдут сам секретный ключ агента?
Тогда провайдер агента перестаёт выдавать ему паспорт и отзывает текущий через Person Server. Паспорт живёт не больше суток, токен личности не больше часа. Есть слабое место: сервис, который пускает агента только по паспорту (режим 1), сообщения об отзыве не получает. Там доступ закончится, когда истечёт паспорт.
Как это связано с MCP?
MCP сейчас использует OAuth 2.1 и динамическую регистрацию клиентов: на каждом сервере у агента новый client_id, а токены на предъявителя. Автор AAuth приводит MCP как пример, где эти ограничения уже мешают. Для MCP-серверов уже есть реализации AAuth: TypeScript SDK для MCP-серверов и модуль для Envoy и agentgateway, который превращает MCP-сервис в AAuth-ресурс.
Кто будет моим Person Server?
Его выбираешь ты сам, его никто не навязывает. Это может быть сервис твоего провайдера входа, твоя компания (один сервер выполняет роли провайдера агентов, Person Server и Access Server для сотрудников) или даже свой собственный сервер. В спецификации есть раздел о том, как сделать минимальный Person Server.
Зачем целых пять режимов? Не слишком сложно?
Каждый сервис берёт только то, что ему нужно, и не обязан внедрять всё сразу. Обычно большинство адресов работают по личности агента или человека, и только несколько важных действий (оплата, запись, удаление) требуют полноценного разрешения.
Где протокол сейчас
Это личный черновик (Internet-Draft), а не принятый стандарт. Детали меняются от версии к версии: только в -11 появился токен личности, и режимов стало пять вместо четырёх.