MCP-серверы для IAM: какие умеют создавать пользователей, а какие только читают

Обычная просьба админу: «Создай пользователя, добавь в группу Engineering и отзови доступ через неделю». Для AI-агента это одно предложение. Для IAM это несколько административных операций, и каждая может закончиться инцидентом. Автор материала на Habr сравнил, что вендоры уже предлагают через Model Context Protocol, и вывод получился неоднозначный.

Кто что умеет на 9 ноября 2026

Автор проверял официальную документацию и списки инструментов. Тенанты он не нагружал, так что это сравнение заявленных возможностей, а не независимый аудит.

Okta: self-hosted open source сервер в GA с февраля 2026, умеет создавать и менять пользователей и группы. Есть OAuth scopes, фильтрация инструментов и подтверждение деструктивных действий через MCP Elicitation. Hosted-вариант пока в Early Access.

Microsoft MCP Server for Enterprise: public preview и только чтение, три инструмента для Graph GET и схемы.

PingOne Remote MCP Server: Early Access, есть создание, изменение и удаление пользователей, но сам вендор не рекомендует включать это в проде. Включение для среды открывает все инструменты, разрешённые ролью.

JumpCloud: создание, блокировка и удаление пользователей, изменение групп, отзыв OAuth-сессий и события в Directory Insights.

Auth0: сервер автоматизирует приложения, API, Actions и журналы, но управления пользователями и группами в справочнике нет. Для задачи «завести сотрудника» это принципиальная разница.

Keycloak в официальных материалах выступает как authorization server для чужих MCP, а не как объект администрирования. Для админки каталога придётся брать сервер сообщества и отдельно проверять его модель доступа.

Пять проверок вместо подсчёта инструментов

1. Что включено по умолчанию. Хорошо, когда сервер выключен или работает на чтение, пока админ не разрешит больше. Важна и гранулярность после включения.
2. От чьего имени действует агент. OAuth администратора с его ролями удобнее для аудита, чем общий API-ключ в переменных окружения.
3. Проверка прав на каждом вызове. Скрыть лишнее в tools/list полезно, но это не авторизация. Проверка нужна и при tools/call: список мог устареть, а вызов можно собрать вручную.
4. Что именно подтверждает человек. В Okta, если клиент не умеет показать диалог Elicitation, сервер возвращает JSON, с которым разбирается модель. Граница доверия там иная, чем у страницы подтверждения, которую формирует сам IAM по сохранённой операции.
5. Различимость агента в журнале. Нужен ответ на вопрос, какой клиент инициировал изменение и кто его подтвердил. Ping пишет в аудит и user_id админа, и client_id MCP-сервера.

Отдельно висит prompt injection: имя группы или атрибут пользователя могут содержать инструкцию для модели. Результаты инструментов нельзя считать безопасными командами, права должен ограничивать сервер.

Одно подтверждение, одна операция

Автор разрабатывает issuerd и прямо об этом предупреждает. В его проекте сервер сохраняет канонические tool и arguments, человек проходит свежую аутентификацию и видит страницу, собранную из серверных данных. После CIBA-подтверждения клиент получает короткий DPoP-токен без refresh token. Подмена id, аргументов или realm отклоняется, а повтор того же вызова возвращает записанный результат без второго удаления.

Это не стандарт MCP. Нужен клиент с поддержкой DPoP и CIBA, а у issuerd нет cross-realm администрирования и unattended M2M.

Что делать на практике

Спецификация MCP Authorization 2026-07-28 с OAuth 2.1 и Resource Indicators отвечает на вопрос, как клиент получил доступ к MCP-серверу. Как человек подтверждает удаление конкретного пользователя, она не определяет.

Чек-лист автора: начать с тестового тенанта и режима чтения, сверить реальный tools/list с задачей, выделить роль с минимальными правами, предпочесть делегированную личность общему секрету, для удаления и привилегированных ролей требовать свежее подтверждение, отфильтровать MCP-действия в аудите и заранее отрепетировать отзыв доступа агента. Статусы Early Access и «не для прода» — часть архитектурного решения, а не мелкий шрифт.

Проверки нужно переносить туда, где модель их не перепишет: в роли, scopes, аудиторию токена, серверную страницу подтверждения и аудит. Старая проблема confused deputy никуда не делась, просто посредник теперь красиво объясняет свои действия.