MCP-серверы в IAM: какие права уже можно доверить AI-агентам
Запрос вроде «создай пользователя, добавь его в группу Engineering и отзови доступ через неделю» выглядит для человека одной задачей. Для IAM это последовательность административных операций, каждая из которых может привести к ошибке или инциденту. MCP-серверы постепенно позволяют передавать такие действия AI-агентам, но уровень готовности разных решений сильно отличается.
В этом обзоре рассматривается именно администрирование IAM: пользователи, группы, роли и доступы. Сценарий, в котором Keycloak или другой провайдер идентификации выдает токены для доступа к стороннему MCP-серверу, относится к другой задаче. Эти процессы важно не смешивать: наличие OAuth-авторизации для MCP еще не означает, что система умеет безопасно менять данные в каталоге.
Что уже предлагают поставщики
Сравнение официальной документации и списков инструментов проводилось по состоянию на 9 ноября 2026 года. Статусы General Availability, Early Access и preview являются обозначениями самих вендоров. Коммерческие окружения не нагружались тестами, поэтому речь идет о заявленных возможностях и защитных механизмах, а не о независимом аудите.
Okta Open Source MCP Server доступен в self-hosted-варианте и имеет статус GA с 4 февраля 2026 года. Он поддерживает создание и изменение пользователей, включая работу с группами. Среди механизмов защиты заявлены OAuth scopes, фильтрация инструментов и подтверждение деструктивных действий через MCP Elicitation. При этом hosted-вариант Okta на момент проверки находился в Early Access.
Microsoft MCP Server for Enterprise распространяется в public preview и работает в режиме чтения. Он предоставляет инструменты для подбора и выполнения запросов Microsoft Graph GET, а также просмотра схемы. Для отчетности и получения сведений о каталоге этого достаточно, но изменять пользователей и группы через него нельзя.
PingOne Remote MCP Server находится в Early Access. Он умеет создавать, изменять и удалять пользователей, а также управлять группами. Доступ контролируется административными ролями, а в журнале фиксируются и идентификатор администратора, и идентификатор MCP-клиента. Однако Ping пока не рекомендует использовать сервер в продуктивной среде.
JumpCloud MCP Server for Admins поддерживает создание, блокировку и удаление пользователей, а также изменение групп. Для подключения применяются административный API-ключ или OAuth. Дополнительно предусмотрены отзыв OAuth-сессий и события в Directory Insights.
У Auth0 MCP Server в справочнике инструментов нет операций для пользователей и групп. Он предназначен для работы с приложениями, API, Actions, журналами и Forms. Поэтому общее слово management в описании сервера нельзя трактовать как полноценное управление каталогом.
С Keycloak ситуация зависит от конкретного решения сообщества. В официальном сценарии Keycloak выступает прежде всего как authorization server, который выдает токены для защищенных MCP-серверов. Для администрирования самого каталога придется отдельно выбирать реализацию и проверять ее модель доступа.
Пять проверок перед выдачей административных прав
Первое, на что стоит смотреть, — поведение по умолчанию. Безопаснее, когда сервер изначально отключен либо работает только на чтение, пока администратор явно не разрешит операции записи. Важна и гранулярность настроек. Например, включение PingOne Remote MCP Server для среды открывает все поддерживаемые операции чтения, записи и удаления, доступные назначенной роли. Поэтому для него особенно важны тестовые или непроизводственные окружения.
Второй вопрос — от чьего имени действует агент. Делегированная OAuth-личность администратора обычно удобнее для аудита, чем общий API-ключ или пароль в переменных окружения. Сервер должен позволять ограничивать доступ scopes и фиксировать, какой пользователь и какой MCP-клиент инициировали изменение.
Третья проверка касается каждого вызова инструмента. Скрывать лишние функции из tools/list полезно: модель видит меньше опасных возможностей и тратит меньше контекста. Но это не заменяет авторизацию. Права необходимо проверять и во время tools/call, поскольку список инструментов мог быть получен раньше, а полномочия пользователя к этому моменту могли измениться.
Четвертый аспект — содержание подтверждения. Надпись «требуется подтверждение человека» сама по себе мало что говорит. Важно, видит ли пользователь конкретную операцию, целевой объект и ее параметры, а также может ли модель изменить вызов после подтверждения. Если клиент не умеет показывать MCP Elicitation, сервер может вернуть JSON, который затем будет интерпретировать модель. Это создает другую границу доверия по сравнению со страницей, сформированной самим IAM.
Наконец, в журнале должно быть понятно, кто именно инициировал действие. Записи вида «пользователь удален» недостаточно для расследования. Желательно видеть администратора, MCP-клиент, время операции и сведения о подтверждении. Дополнительная атрибуция клиента помогает отличить действия агента от изменений через обычную консоль.
Почему подтверждение должно относиться к одной операции
Более строгий подход предполагает, что человек подтверждает не общее право агента на запись в IAM, а одно конкретное изменение. Такой принцип реализован в проекте issuerd, автор которого участвовал в разработке решения, поэтому его возможности следует рассматривать с учетом этого ограничения и проверять самостоятельно.
В описанной модели сервер сохраняет канонические имя инструмента и аргументы, а также ожидаемое состояние целевого объекта. После свежей аутентификации пользователь видит страницу, сформированную IAM на основе серверных данных. Затем после CIBA-подтверждения клиент получает короткоживущий DPoP-токен со scope openid mcp:step_up, без refresh token и общего доступа к административному API.
Повторный вызов должен полностью совпадать с исходным: нельзя заменить идентификатор пользователя, аргументы, realm, ключ или ожидаемое состояние. Точная повторная отправка возвращает уже записанный результат и не запускает второе удаление. Такой механизм не является стандартом MCP и требует совместимости клиента с DPoP и CIBA. У issuerd заявлены 71 инструмент, включая чтение и self-service, но отсутствуют cross-realm-администрирование и unattended M2M.
Что дают стандарты MCP
Спецификация MCP Authorization от 28 июля 2026 года описывает OAuth 2.1, Protected Resource Metadata и Resource Indicators для защищенного HTTP-транспорта. Практический смысл Resource Indicators заключается в ограничении аудитории токена: он должен быть выпущен для конкретного MCP-сервера, а не использоваться как универсальный пропуск к разным API.
Однако этот набор механизмов отвечает прежде всего на вопрос, как клиент получил доступ к MCP-серверу и для какого ресурса предназначен токен. Спецификация сама по себе не определяет, как подтверждать удаление пользователя или выдачу привилегированной роли. Для этого нужен отдельный продуктовый или отраслевой профиль безопасности.
Практический чек-лист для пилота
- Начать с тестового тенанта и режима только для чтения.
- Сверить фактический список инструментов с задачами, не полагаясь только на маркетинговое описание.
- Создать отдельную роль с минимальными правами и проверить повторную авторизацию при каждом вызове.
- Предпочесть делегированную личность администратора общему секрету и проверить ограничение токена по аудитории.
- Для удаления и выдачи привилегированных ролей включить свежую аутентификацию и подтверждение точных аргументов операции.
- Убедиться, что действия агента выделяются в аудите и что его доступ можно быстро отозвать.
- Учитывать статус продукта: Early Access, preview и рекомендация не использовать решение в продакшене являются архитектурными ограничениями, а не формальностями.
Для первичного тестирования Okta логично рассматривать в self-hosted-варианте с узкими OAuth scopes. Microsoft MCP Server подходит для отчетов и чтения данных, но не для изменений. В случае Keycloak необходимо оценивать конкретный сервер сообщества. Если приоритетом является подтверждение одной точной операции, можно изучить issuerd, предварительно проверив поддержку нужных протоколов на стороне клиента.
Главный риск здесь связан не с количеством доступных инструментов, а с проблемой confused deputy. Агент получает чужие полномочия и может быть убежден выполнить лишнее — в том числе через prompt injection в имени группы, атрибуте пользователя или записи журнала. Поэтому результаты инструментов нельзя считать безопасными командами. Ограничения должны задаваться на сервере через роли, scopes, аудиторию токена, подтверждение и журналирование, а не только системным промптом.
