WorkOS придумал как регистрировать AI-агентов без API-ключей

Пока агенты уже пишут код, открывают pull-реквесты, триажируют тикеты и обновляют записи в базах — большинство продуктов до сих пор не умеют их регистрировать по-человечески. Стандартный воркэраунд: дать агенту сырой API-ключ или session token. Результат — credentials без скоупов, без аудита на сессию, без возможности точечного отзыва. WorkOS предложил структурированную альтернативу: auth.md.

Контекст

WorkOS — это платформа для enterprise-аутентификации: SSO, SCIM, RBAC. Их основная аудитория — SaaS-разработчики, которым нужно быстро добавить корпоративный вход. Компания хорошо понимает, как устроена идентичность в современном стеке, и поэтому их выход в тему agent identity выглядит органично, а не как маркетинговый ход.

Проблема реальная. Веб строился под допущение: за браузером сидит человек. Кликает кнопку, заполняет форму, читает письмо. Когда работу делегируешь агенту — этот сценарий ломается. Агент не прочитает письмо, не введёт CAPTCHA. А продукты, которые не готовы к этому, либо раздают raw API-ключи (плохо), либо вовсе не поддерживают агентов (ещё хуже).

auth.md — это не продукт WorkOS, а открытый протокол. Любое приложение может его поддержать независимо от того, использует ли оно инфраструктуру WorkOS. В основе — существующие стандарты: RFC 9728 и ID-JAG. Это важно: протокол не изобретает колесо, а собирает уже принятые OAuth-спецификации в один понятный сценарий.

Аналитика

В 2025–2026 годах рынок захлестнул первый серьёзный вопрос agentic-эры: кто именно что-то сделал? Когда агент модифицирует запись в CRM или пушит код в репозиторий, система должна знать: от чьего имени, с какими правами, когда это можно отозвать. Без ответа на этот вопрос масштабное делегирование задач агентам просто небезопасно для корпораций.

auth.md атакует именно эту дыру. Два потока регистрации покрывают реальные сценарии: агент с верифицированным провайдером (Anthropic, OpenAI, Cursor) — синхронная регистрация без человека, через ID-JAG. Агент без провайдера — OTP-поток, где пользователь один раз читает код из письма обратно агенту. Первый поток — для зрелых платформ, второй — для любого стека прямо сейчас.

Что важно с точки зрения трендов: это не конкурент MCP и не замена OAuth. Это слой поверх OAuth, решающий конкретную задачу — onboarding агента вместо onboarding человека. Вся остальная инфраструктура — JWKS, access tokens, revocation — остаётся стандартной. Если auth.md наберёт поддержку у major SaaS-провайдеров, мы получим первый реальный identity-стандарт для агентов.

Кейсы применения в бизнесе

B2B-SaaS стартап: вы строите продукт, который сам по себе является агентом или вызывает агентов для автоматизации workflow клиентов. Добавьте /auth.md на свой домен и поддержите два well-known эндпоинта. Клиенты смогут подключить своих агентов (Cursor, Claude, кастомные) без выдачи master API-ключей. Каждая сессия — отдельные credentials с чётким аудитом. Это прямо продаётся как enterprise-фича.

Корпорация с legacy: у вас внутренние системы — ERP, CRM, тикетница — и вы начинаете внедрять AI-агентов для автоматизации. Стандартный подход — сервисные аккаунты с широкими правами. auth.md позволяет выдавать агентам скоупированные токены с привязкой к конкретному пользователю, отзывом по событию и полным audit trail. Compliance-офицеры будут благодарны.

SMB или локальный бизнес в КР/СНГ: если вы используете no-code/low-code платформы вроде Make или n8n, и планируете добавить AI-агента в процессы — пока протокол не поддерживается нативно в этих инструментах. Но следить за его поддержкой стоит уже сейчас: как только major SaaS начнут его принимать, вы сможете безопасно давать агентам доступ к CRM или email без выдачи полных ключей администратора.

Кейсы в личной жизни

Разработчик: если вы строите AI-агента, который работает с внешними API — посмотрите на спецификацию auth.md и ID-JAG. Реализовать agent verified flow не сложнее, чем стандартный OIDC. Выигрыш — ваш агент получает честные per-session credentials вместо hardcoded ключей. Это сразу снимает вопросы безопасности при код-ревью.

Контент-мейкер или фрилансер: вы используете Claude, ChatGPT или другие AI-ассистенты для работы с внешними сервисами. Пока большинство платформ не поддерживают auth.md — но когда поддержат, вы сможете дать агенту доступ к своему Notion, GitHub или почте без риска скомпрометировать мастер-токен. Следите за обновлениями в тех инструментах, которыми пользуетесь.

Студент или исследователь: auth.md — отличный учебный пример того, как строятся open protocols. Спецификация короткая, написана на Markdown, хорошо структурирована. Читая её, вы одновременно разбираетесь в OAuth, JWT, JWKS и discovery patterns. Репозиторий открытый — это готовый материал для курсовой по identity management или agent security.

Как применить сегодня

• Прочитайте спецификацию auth.md в репозитории WorkOS — она короткая, написана понятным языком и не требует глубокого знания OAuth для первого прочтения.
• Если вы SaaS-разработчик: добавьте поддержку /.well-known/oauth-protected-resource и /.well-known/oauth-authorization-server с блоком agent_auth — это минимальный шаг для совместимости.
• Для новых агентских интеграций: вместо выдачи raw API-ключей реализуйте user claimed flow с OTP — он не требует интеграции с провайдером, работает с любым стеком.
• Настройте audit events согласно спецификации: registration.created, claim.confirmed, registration.revoked — минимальный набор для инцидент-менеджмента.
• Следите за тем, когда Anthropic и OpenAI добавят поддержку ID-JAG в свои платформы — это откроет agent verified flow без дополнительных интеграций.