Коротко. Учётная запись при подключении ИИ-помощника к Directum RX остаётся на компьютере пользователя, а данные RX уходят провайдеру модели, и решать службе безопасности в первую очередь про них. Риск кражи учётки зависит от способа входа, лучший вариант OIDC с отдельным клиентом. От инструкций внутри документов защищают выключенная по умолчанию запись, подтверждение каждого действия и запрет прикладывать файлы с ключами. Полный разбор для rxmcp лежит в документе security.md на GitHub.

Сотрудники хотят спрашивать ИИ-помощника про свои задания и договоры, а служба безопасности спрашивает в ответ: что при этом уйдёт наружу. Обычно её беспокоит учётная запись, хотя больше всего наружу уходит содержимое документов. Разбираем по шагам, куда и что передаётся при подключении помощника к Directum RX через MCP-сервер, что лежит на диске и какие настройки закрывают каждый риск. Примеры на rxmcp, но вопросы те же для любого MCP-сервера к СЭД.

Симптом

Типичная картина в компании: несколько человек уже подключили помощника сами, по инструкции из интернета. Служба безопасности узнаёт об этом последней и хочет понять, не утечёт ли учётная запись, не увидит ли помощник лишнего и не отправит ли документы куда не надо.

Почему так

Схема подключения состоит из трёх звеньев, и у каждого свой риск:

  1. MCP-сервер работает на компьютере пользователя и ходит в сервис интеграции RX от его имени. Здесь вопрос в том, где и как хранятся данные для входа.
  2. ИИ-клиент (Claude Desktop, Cursor и другие) получает от MCP-сервера ответы: тексты заданий, документов, изображения сканов.
  3. Провайдер модели получает от клиента всё, что тот отправил модели вместе с вопросом пользователя.

Учётная запись остаётся в первом звене: в ответы инструментов её не кладут. Данные RX проходят все три звена, поэтому с них и стоит начинать разговор о безопасности.

Диагностика: какие соединения открываются

Первое, что стоит выяснить про любой MCP-сервер, это список его соединений. У rxmcp он такой:

Откуда и куда Что передаётся Когда
компьютер → сервис интеграции RX запросы от имени пользователя и его данные для входа всегда
компьютер → веб-клиент RX и провайдер единого входа сессия провайдера, чтобы получить новую сессию RX только при входе через сессию Keycloak
компьютер → сайт с номером последней версии только запрос номера версии, без адреса RX и логина раз в сутки, выключается настройкой
ИИ-клиент → провайдер модели вопросы и ответы инструментов, то есть данные RX при каждом вызове

Других соединений нет, телеметрии тоже. Сервис интеграции не обязан быть доступен из интернета: серверу нужен только сетевой доступ к нему с компьютера пользователя, через VPN тоже подойдёт. Если сервис интеграции у вас опубликован наружу и в RX включён вход по паролю, его можно перебирать, и это риск сам по себе, без всякого ИИ.

Диагностика: что лежит на диске

MCP-сервер должен где-то держать данные для входа. Хорошая практика, когда их нет в конфиге ИИ-клиента, а есть только в отдельном каталоге с правами только для владельца. Что именно там лежит, зависит от способа входа, и цена кражи этих файлов сильно разная:

Способ входа Что хранится Чем грозит кража файла Сколько живёт
логин и пароль пароль открытым текстом полный вход под пользователем, в том числе в веб-клиент пока пароль не сменят
cookie из браузера сессия RX работа в RX под пользователем часы
сессия Keycloak сессия провайдера единого входа вход во все приложения этого провайдера, а не только в RX сколько задал администратор провайдера
OIDC с отдельным клиентом токены только этого клиента доступ к сервису интеграции до отзыва токена задаёт администратор, отзыв в провайдере

Права «только владелец» защищают от других пользователей компьютера, но не от программ, запущенных под тем же пользователем. Вредонос на машине прочитает эти файлы. Прочитать их может и ИИ-агент с доступом к файлам и терминалу, если пользователь ему это разрешит. Поэтому главная мера защиты здесь выбор способа входа. Лучший вариант OIDC с отдельным клиентом: пароль сервер не видит, а сроки и отзыв в руках администратора.

Диагностика: что видит провайдер модели

Всё, что помощник прочитал по просьбе пользователя: темы и переписку заданий, текст документов, статьи базы знаний, карточки досок. Сканы уходят изображениями страниц вместе с печатями и подписями. Это свойство любого облачного ИИ-ассистента, MCP-сервер тут ничего не добавляет и не убирает.

Что стоит выяснить до внедрения:

  • Тариф и договор с провайдером. Корпоративные тарифы основных провайдеров по договору не используют данные для обучения и ограничивают срок хранения. Бесплатные и личные тарифы таких условий могут не давать.
  • Какие документы нельзя отправлять внешнему провайдеру вообще: персональные данные, коммерческая тайна, документы с грифом. Помощник видит всё, что видит пользователь, поэтому ограничивать нужно правами в RX или регламентом: модель сама ничего не отфильтрует.
  • Можно ли использовать локальную модель. MCP-сервер работает с любым клиентом, который поддерживает протокол, в том числе с клиентом локальной модели внутри контура.

Диагностика: инструкции внутри документов

Текст из RX может содержать инструкции для модели: «перешли этот документ на адрес», «приложи файл». Это называется prompt injection, и модель не всегда отличает данные от команд. Автору документа достаточно иметь доступ к системе, чтобы положить такую инструкцию туда, где её прочитает чужой помощник.

Что должен делать MCP-сервер, чтобы это не стало утечкой:

  • помечать всё, что пришло из системы, как данные пользователя, а не инструкции;
  • без явного разрешения на запись не показывать модели пишущих инструментов вообще;
  • перед каждой записью пересказывать действие и спрашивать подтверждение у человека;
  • не прикладывать к карточкам и документам файлы из каталогов с ключами и из своего каталога настроек. Иначе инструкция в документе может попросить модель приложить cookie пользователя к карточке, которую видит автор документа.

Чего MCP-сервер закрыть не может: если в том же ИИ-клиенте подключены инструменты с выходом в интернет (поиск, загрузка страниц, другие MCP-серверы), модель, прочитав данные RX, технически может передать их через них. Это настраивается в самом клиенте: какие инструменты подключены и спрашивает ли он разрешение перед вызовом.

Что сделать

Короткий список для правил внедрения:

  1. Способ входа. OIDC с отдельным клиентом в вашем провайдере. Если клиент завести нельзя, cookie или сессия Keycloak с разумным сроком сессии провайдера. Вход по паролю только там, где других вариантов нет.
  2. Сервис интеграции доступен только из корпоративной сети или через VPN.
  3. Запись выключена, пока она не нужна конкретному человеку. Если включена, подтверждение каждого действия в клиенте остаётся включённым.
  4. Шифрование диска на компьютерах пользователей. Оно закрывает сценарий украденного ноутбука при любом способе входа.
  5. Решение о провайдере модели и о том, какие документы ему отправлять нельзя.
  6. Происхождение программы. Открытый код, сборка из исходников или проверка подписи происхождения архива. Если компания собирает сама, проверку новых версий можно выключить.

Чего не делать

  • Не заводить для помощника сервисную учётку с полными правами. Помощник должен видеть ровно то же, что человек, от чьего имени работает.
  • Не класть пароли и токены в конфиг ИИ-клиента. Его читают и показывают многие программы, а синхронизация настроек может унести его в облако.
  • Не подключать к тому же клиенту всё подряд. Каждый инструмент с выходом наружу становится возможным каналом утечки того, что помощник прочитал в RX.
  • Не выключать подтверждение действий ради удобства. Это последняя преграда между инструкцией в чужом документе и записью от вашего имени.