MCP для корпоративного поиска: wiki, тикеты, ACL и аудит

Раздел

MCP-серверы

Сложность

средняя

Обновлено

2026-05-20

Короткий ответ

MCP для корпоративного поиска нужен, когда агенту нужно безопасно искать по wiki, тикетам, регламентам, политикам и инженерной документации, не получая доступ “ко всему”. Хороший сервер возвращает только разрешенные пользователю источники, показывает ссылку на документ, пишет audit log и умеет отказаться, если источника нет.

Плохой поиск начинается с единого индекса всех документов. Это быстро дает демо, но ломает права: HR-политики, клиентские договоры, инциденты, внутренние расследования и product roadmap оказываются в одном контексте модели. MCP не должен быть дырой между системами. Он должен быть thin layer над существующими ACL и журналом.

По спецификации MCP resources дают серверу способ открыть клиенту данные вроде файлов, схем или прикладной информации через URI. Важно, что ресурс - это не разрешение читать все. Смотрите MCP resources specification: сервер объявляет capability, а приложение решает, как включать контекст.

Какие источники подключать

Для первого контура выберите два-три источника, а не всю компанию.

Если у документа нет владельца, даты обновления и прав доступа, не кладите его в первый индекс. Сначала наведите порядок в корпусе. Для поиска по документам без MCP полезен общий разбор поиска по документам с ИИ.

ACL до retrieval

Права применяются до поиска и до передачи текста модели. Нельзя найти закрытый документ, передать его LLM, а потом попросить “не показывать”. Сервер должен получать identity пользователя, проверять группы и фильтровать corpus на уровне запроса.

user identity
  -> group and role lookup
  -> allowed source filter
  -> retrieval over allowed documents only
  -> answer with citations
  -> audit event

Для enterprise-контуров ориентируйтесь на существующие системы прав. Microsoft Entra описывает audit logs как записи активности по пользователям, группам и приложениям: Microsoft Entra audit logs. Это хороший пример того, какие события обычно нужны для расследования.

Контракт ответа

MCP-поиск должен возвращать не “текст из модели”, а структурированный результат, который модель может использовать.

{
  "query": "как эскалировать инцидент P1",
  "results": [
    {
      "title": "Incident response runbook",
      "uri": "wiki://sre/runbooks/incidents",
      "updated_at": "2026-05-10",
      "owner": "SRE",
      "access": "allowed",
      "excerpt": "P1 эскалируется через on-call..."
    }
  ],
  "missing": false,
  "policy": "do_not_answer_without_source"
}

Если источник не найден, ответ должен быть отказом или уточняющим вопросом. Для поддержки, юристов и операций честный отказ лучше уверенного пересказа без источника.

Правило поиска: агент может объяснять найденный документ, но не должен создавать новое правило компании. Если в источниках нет ответа, итоговый ответ должен сказать, что данных нет.

Audit log

Для каждого запроса пишите событие: user, client, query hash, source filter, найденные URI, отказ или ответ, время, trace ID, версия сервера. Не пишите полный вопрос в открытый лог, если он может содержать персональные данные или секреты.

GitHub Enterprise Cloud показывает похожую идею для событий организации и enterprise через audit log API: GitHub enterprise audit log API. Внутренний MCP-журнал не обязан копировать GitHub, но должен позволить ответить на вопросы: кто искал, какие источники получил, почему система отказала.

OpenTelemetry полезен для технической стороны: logs описываются как timestamped records with metadata, а structured logs проще фильтровать и связывать с trace ID. См. OpenTelemetry logs.

Как избежать мусорного поиска

Качество корпоративного поиска портится не моделью, а корпусом:

• дубли страниц;
• старые инструкции без archive status;
• разные версии одного процесса;
• документы без владельца;
• тикеты с временными workaround;
• вложения без текста;
• неразмеченные права;
• одинаковые названия страниц.

Перед запуском соберите eval-набор: 100 реальных вопросов, ожидаемый источник, список допустимых отказов и провокационные вопросы на закрытые документы. Потом считайте source hit rate, refusal quality и leakage tests. Подход похож на оценку качества RAG, только права становятся обязательной метрикой.

Схема первого пилота

2 wiki spaces + 1 ticket project
  -> clean owners and updated_at
  -> index only allowed documents
  -> MCP search_resources(query, source_type)
  -> answer only with citations
  -> audit log and daily leakage review

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

Чеклист

• Выбраны конкретные источники, а не “все документы”.
• У документов есть owner, updated_at и статус.
• ACL применяются до retrieval.
• Ответы требуют источника.
• Empty result не превращается в догадку.
• Audit log пишет user, URI, outcome и trace ID.
• Секреты и персональные данные не попадают в индекс без политики.
• Есть eval-набор с провокационными вопросами.
• Есть владелец корпуса и процесс удаления устаревших страниц.
• MCP-сервер можно отключить без остановки продукта.

FAQ

MCP лучше обычного RAG?

Это разные слои. RAG описывает retrieval и генерацию ответа, а MCP может быть интерфейсом, через который агент получает разрешенный поиск или resources.

Можно ли индексировать закрытые документы?

Можно только если права применяются до поиска и результаты не попадают пользователям без доступа. Для первого пилота лучше брать менее чувствительный корпус.

Что делать с тикетами?

Начинайте с read-only поиска по закрытым или решенным тикетам, маскируйте персональные данные и показывайте ссылку на исходный тикет.

Что читать дальше?

Для архитектуры MCP смотрите MCP сервер: что это, а для качества поиска - RAG систему.