AI-агент с правами администратора: что уже умеют MCP-серверы в IAM

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

Я посмотрел, что поставщики IAM уже предлагают через Model Context Protocol. Хорошая новость: создание пользователей и изменение групп больше не выглядит фантастикой. Плохая: надпись «подтверждение человеком» сама по себе еще ничего не гарантирует. Важно, что именно подтвердил человек и может ли модель подменить операцию после этого.

Сразу обозначу границы. Речь про администрирование самой IAM: пользователей, группы, роли и доступ. Сценарий, где Keycloak или другой IdP выдает токены для доступа к чужому MCP-серверу, интересен отдельно. Это две разные задачи, и смешивать их не стоит.

Что я сравнивал

Я проверил официальную документацию и списки инструментов на 9 ноября 2026 года. Статусы GA, Early Access и preview здесь принадлежат вендорам, а не мне. Коммерческие тенанты я не нагружал тестами, поэтому это сравнение заявленных возможностей и защитных механизмов, а не независимый сертификационный аудит.

Получилась такая выборка, без претензии на полный каталог рынка:

Первый вывод простой: универсального ответа «MCP для IAM уже готов» нет. У Okta self-hosted сервер имеет GA, а ее hosted-вариант на дату проверки находится в Early Access. Microsoft умеет отвечать на вопросы о каталоге, но не менять его. Ping уже дает инструменты записи, однако сам не рекомендует включать их в проде. Это разные состояния, хотя на слайдах все они могут называться одинаково.

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

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

Когда MCP-сервер получает доступ к административному API, я смотрю на пять вещей.

1. Что происходит по умолчанию. Хороший признак — сервер выключен или работает только на чтение, пока администратор явно не разрешил больше. Но важна и гранулярность после включения. У PingOne Remote MCP Server роли ограничивают доступные действия, но включение для среды открывает все поддерживаемые read, write и delete инструменты, разрешенные ролью. Поэтому Ping пока советует ограничиться непроизводственными средами и обещает более детальные настройки позже.

2. От чьего имени действует агент. OAuth администратора с его ролями обычно удобнее для аудита, чем общий API-ключ или пароль в переменных окружения. Okta загружает только инструменты, покрытые OAuth scopes. Ping записывает в аудит и user_id администратора, и client_id MCP-сервера. Так действия агента можно отделить от обычных изменений через консоль.

3. Проверяются ли права на каждом вызове. Скрыть лишний инструмент из tools/list полезно: модель меньше соблазняется и расходует меньше контекст. Но это еще не авторизация. Повторная проверка должна происходить и при tools/call, ведь список мог быть получен раньше, права могли измениться, а вызов можно сформировать вручную.

4. Что именно подтверждает человек. У Okta деструктивные операции используют MCP Elicitation. Если клиент умеет показать запрос, человек видит диалог. Если не умеет, сервер возвращает JSON, с которым уже разбирается модель. Это рабочий механизм, но у него другая граница доверия, чем у страницы подтверждения, которую формирует сам IAM по сохраненной у себя операции.

5. Можно ли отличить агента в журнале. Мне нужен не просто event «пользователь удален», а ответ на вопрос «какой клиент инициировал это изменение и кто его подтвердил». Отдельный идентификатор MCP-клиента в аудите сильно упрощает расследование.

И поверх всего этого остается prompt injection. Имя группы, атрибут пользователя или запись в журнале могут содержать вредоносную инструкцию для модели. Поэтому результаты инструментов нельзя считать безопасными командами. Права должен ограничивать сервер, а не надежда на хорошее поведение LLM.

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

Здесь нужен личный дисклеймер: я разрабатываю issuerd, поэтому свой проект ставлю не на пьедестал, а под тот же разбор. В нем я хотел получить понятную механику: человек подтверждает не общее право «разрешаю агенту писать», а одно конкретное изменение.

Например, модель предлагает такой вызов:

{
  "tool": "users_delete",
  "arguments": {
    "id": "<uuid пользователя>",
    "confirmation": "DELETE"
  }
}

Дальше в игру вступает серверный профиль issuerd:

1. Сервер сохраняет канонические tool + arguments и ожидаемое состояние цели. Подтверждение привязано к этой операции, а не к названию инструмента в тексте чата.

2. Человек проходит свежую аутентификацию и видит страницу, сформированную IAM по серверным данным.

3. После CIBA-подтверждения клиент получает короткий DPoP-токен со scopes openid mcp:step_up, без refresh token и общего доступа к Admin API.

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

Это не стандарт MCP и не универсальная кнопка безопасности. Это профиль на OAuth, DPoP и CIBA, который надо проверять на совместимость с конкретным клиентом. Из рассмотренных реализаций такую серверную привязку я увидел у issuerd; у других продуктов есть свои подтверждения, но с другими границами. У issuerd сейчас 71 инструмент, при этом нет cross-realm администрирования и unattended M2M, а полный strict-flow требует клиента с поддержкой DPoP и CIBA. Это ограничения, которые придется учитывать до пилота.

Отдельно скажу про Keycloak. В проверенных официальных материалах его роль в MCP сводится прежде всего к authorization server: выдать токен для защищенного MCP-сервера. Для администрирования самого каталога придется выбирать сервер сообщества и отдельно проверять его модель доступа. OAuth вошедшего пользователя и пароль администратора из окружения — не одно и то же.

Стандарты помогают, но не решают все

В спецификации MCP Authorization 2026-07-28 для защищенного HTTP-транспорта используются OAuth 2.1, Protected Resource Metadata и Resource Indicators. Практический смысл последних простой: токен должен быть выпущен для конкретного MCP-сервера, а не быть универсальным пропуском во все API подряд. Сервер обязан проверять свою аудиторию и не передавать чужие токены дальше.

Это важная база, но она отвечает на вопрос «как клиент получил доступ к MCP-серверу». Она не определяет, как человек подтверждает удаление конкретного пользователя. Для этого все равно нужен отдельный продуктовый или отраслевой профиль.

Что бы я проверил перед запуском

Независимо от вендора мой чек-лист выглядит так:

1. Начать с тестового тенанта и режима только для чтения.

2. Сверить фактический tools/list с задачей, а не полагаться на анонс.

3. Выделить отдельную роль с минимальными правами и убедиться, что проверка повторяется на каждом вызове.

4. Предпочесть делегированную личность администратора общему секрету. Проверить, как токен ограничен по аудитории и можно ли использовать DPoP.

5. Для удаления и выдачи привилегированных ролей требовать свежее подтверждение. Желательно — с серверной привязкой к точным аргументам.

6. Отфильтровать MCP-действия в аудите и заранее пройти сценарий отзыва доступа агента.

7. Прочитать ограничения конкретного статуса. Early Access, preview и «не рекомендован для прода» — не мелкий шрифт, а часть архитектурного решения.

Для Okta я бы начал с self-hosted сервера в тестовой организации и узких scopes. Для Entra официальный сервер сейчас подходит для отчетов, а не для изменений. Для Keycloak пришлось бы оценивать конкретную реализацию сообщества. Для пилота с серверным подтверждением точной операции можно посмотреть issuerd, сначала проверив клиентскую совместимость.

Немного философии

MCP не отменяет старую задачу confused deputy. У нас по-прежнему есть посредник с чужими полномочиями, которого можно обманом заставить сделать лишнее. Просто теперь этот посредник умеет красиво объяснить свои действия на естественном языке.

Поэтому полезный переход здесь не «дать агенту root и добавить системный промпт», а перенести проверки туда, где модель не сможет их переписать: в роли, scopes, аудиторию токена, серверную страницу подтверждения и аудит. Число инструментов потом. Сначала — кто и что может выполнить на самом деле.

Ссылки

• Okta: релизы Open Source MCP Server и репозиторий со списком возможностей.

• Microsoft: обзор MCP Server for Enterprise.

• Ping Identity: инструменты PingOne Remote MCP Server и правила безопасности.

• JumpCloud: MCP Server for Admins.

• Auth0: справочник инструментов MCP Server.

• Keycloak: использование как MCP authorization server.

• Спецификация MCP Authorization 2026-07-28.

• issuerd: встроенный MCP-сервер и разбор подтверждения одной точной операции.