MCP-сервер (эндпоинт /iikona-mcp, HTTP-сервис КИИ_СерверMCPAPI) публикует инструменты доступа к данным 1С для ИИ-агента по HTTP. Это общая библиотека — развёртывание не контролируется вендором, поэтому конфигурируйте её по принципу наименьших привилегий и не доверяйте сети/заголовкам по умолчанию.

Учётные данные MCP-клиента хранятся в безопасном хранилище (НЕ в коде):

• пользователь — константа КИИ_СерверMCPПользовательAPI;
• пароль — безопасное хранилище (владелец КИИ_СерверMCPПользовательAPI, ключ Пароль).

⚠ Демонстрационный пароль (например 12345) НЕДОПУСТИМ в проде — установите длинный случайный пароль. Rate-limiter (§3) тормозит перебор, но не заменяет сильный секрет.

Пароли сравниваются по SHA-256-хешам в постоянном времени — утечки длины пароля по таймингу нет.

execute_query выполняет read-only запрос под правами сессии MCP-пользователя (привилегированный режим в тракте MCP не используется). Если у пользователя широкая роль (Полные права / администратор хост-конфигурации) — агент, а через инъекцию в недоверенном контенте и внешняя сторона, читает ЛЮБЫЕ данные базы: зарплаты, персоналку, почтовые креды.

Вендор поставляет least-privilege роль КИИ_СерверMCPДиагностика (read-only):

• Read — мониторинг-регистры (КИИ_МониторингОшибокЖурнал/Статистика), логи и кеш ИИ, база знаний RAG (КИИ_БазаЗнаний/ФрагментыЗнаний/КатегорииЗнаний/ЭкспертыИИ), КИИ_МоделиИИ, эмбеддинги/Qdrant;
• Read+Update — инфра-регистры лимитера и аудита (КИИ_СерверMCPОграниченияВызовов, КИИ_СерверMCPАудитВызовов), иначе учёт лимита бросает исключение → fail-open → rate-limiting молча отключается;
• НЕ даёт — почтовые аккаунты, физлица, константы-секреты, объекты хост-конфигурации, запись в бизнес-данные.

Требование к развёртыванию: MCP-пользователю назначить КИИ_БазовыеПрава (сессионные/клиентские права) + КИИ_СерверMCPДиагностика (диагностические чтения) и снять КИИ_ПолныеПрава и любые административные роли хост-конфигурации. Права в 1С аддитивны — при наличии широкой роли ограничение не сработает.

Платформа сама отклонит любой execute_query по объекту вне роли («нет права чтения») — это надёжнее прикладного парсинга текста запроса. Чтобы расширить или сузить видимость агента — правьте состав объектов роли КИИ_СерверMCPДиагностика осознанно.

Лимит 60 запросов/мин ключуется:

• аутентифицированный запрос → бакет по имени пользователя (user:<имя>);
• неаутентифицированный → единый глобальный бакет (anon:global).

Заявленный username и заголовок X-Forwarded-For НЕ используются как ключ лимитера — их подмена не даёт атакующему свежий бакет, поэтому перебор пароля троттлится. Заявленный идентификатор попадает только в журнал аудита (форензика).

Глобальный бакет для неаутентифицированных — осознанный компромисс: без доверенного обратного прокси 1С не отдаёт реальный IP клиента, поэтому все неаутентифицированные попытки делят один бакет. Для per-IP гранулярности поставьте сервер за доверенный реверс-прокси (nginx/Apache), который очищает клиентские заголовки и проставляет X-Forwarded-For; тогда ключ лимитера можно доработать до первого XFF-хопа.

Ответы клиенту содержат только correlation_id; внутренние детали (имена модулей, фрагменты запросов, значения параметров) пишутся в журнал регистрации под этим id и на сторону клиента не утекают.

Контроль персональных данных (с 1.5, маскировка подстановками перед отправкой в модель, Telegram и kroki) на MCP-сервер не распространяется: внешний агент сам запрашивает данные базы и получает их такими, какие они есть, в пределах прав MCP-пользователя. Единственная граница здесь — состав роли КИИ_СерверMCPДиагностика (раздел 2): не давайте MCP-пользователю чтение справочников с физическими лицами, контрагентами и контактами, если агент на стороне провайдера не должен их видеть.

Если в обработке «Контроль персональных данных» указан адрес сервиса распознавания имен (1c-ai-connector-ner-shim), каждый проверяемый текст до маскировки уходит ему — с исходными значениями. Поэтому:

• ставьте сервис в том же контуре, что и 1С; по умолчанию он слушает 127.0.0.1. На отдельном хосте закройте порт firewall'ом так, чтобы к нему ходили только серверы 1С: сервис не требует аутентификации, а 1С ходит к нему по HTTP напрямую, без прокси;
• сервис не пишет тексты запросов в лог и не обращается в интернет — модели Natasha зашиты в пакет;
• ответ сервиса проверяется по протоколу. Ответ не по протоколу, отказ (текст длиннее лимита — 413) и таймаут считаются недоступностью: проверка идет своими правилами, а с флажком «Без сервиса не отправлять» запрос в режимах «Заменять подстановками» и «Не отправлять» не уходит.