{
"mcpServers": {
"production-erp": {
"command": "python",
"args": ["-m", "erp_mcp_server"],
"env": {
"DB_DSN": "postgresql://admin:supersecret@10.0.0.5:5432/main_db",
"ALLOW_UNSAFE_WRITES": "true"
}
}
}
}Посмотрите на этот кусок конфигурации. Именно так сейчас большинство энтерпрайз-команд подключают так называемых ИИ-агентов к своим боевым системам. Сырая строка подключения к базе данных с правами на запись пробрасывается прямо в окружение сервера, потому что очередной разработчик прочитал, что новый протокол магическим образом решает все проблемы с коннекторами. Внедрить MCP в корпоративной среде: как подключить агента к своим системам без зоопарка интеграций и дыр — это не просто поднять Python-скрипт из документации. Это суровый архитектурный вызов, на котором сейчас ломаются те, кто путает стандартизацию интерфейсов с делегированием безопасности.
До появления этого стандарта подключение LLM к внутренним инструментам было чистым хаосом. Представьте матрицу: с одной стороны у вас пять разных фреймворков и агентов, с другой — двадцать корпоративных систем. Вы пишете сотню кастомных адаптеров, и любое изменение в API ломает половину пайплайнов. Model Context Protocol переводит эту архитектуру в классическую клиент-серверную модель. Клиент говорит по стандарту MCP. Сервер говорит по стандарту MCP. Вы пишете коннектор к ERP один раз, и любой агент сразу получает к нему доступ. Сервер сам отдает схему того, что он умеет, через JSON-RPC, а клиент динамически строит под это абстракции. Звучит идеально, пока мы не упираемся в реальность продакшена.
Протокол специфицирует три типа возможностей: ресурсы, инструменты и промпты. Ресурсы — это потоки данных только для чтения, например, логи или содержимое файлов. Инструменты — это исполняемые функции с сайд-эффектами. Промпты — шаблоны контекста. Фатальная ошибка инженеров заключается в размытии границы доверия. Они искренне верят, что если в системном промпте написать строгую инструкцию не удалять таблицы, то языковая модель этого не сделает. Но LLM — это недетерминированный вероятностный генератор текста. Доверять ему нельзя по определению. Граница доверия проходит не внутри нейросети, а на кромке вашего MCP-сервера.
Наш подход в Morana Labs к этой архитектуре радикально отличается от того, что транслируют евангелисты agentic-хайпа. Рынок кричит: дайте агенту сырой доступ к SQL-движку или Bash-терминалу, чтобы он мог решать задачи любой сложности. Мы говорим: агент в проде — это потенциально скомпрометированный и крайне непредсказуемый внешний пользователь с минимальными правами. Если мы разворачиваем MCP-сервер для взаимодействия с внутренними системами, он никогда не смотрит напрямую в базу данных. Он оборачивается в жестко типизированный слой внутреннего API. Вместо того чтобы отдавать агенту инструмент для выполнения сырых SQL-запросов, мы отдаем ему метод проверки баланса клиента. Валидация каждого параметра, проверка лимитов и бизнес-логика остаются на стороне бэкенда, а не делегируются умному промпту.
Безопасность on-prem инсталляций требует понимания того, что MCP — это транспортный слой, а не система авторизации. Протокол работает поверх стандартных потоков ввода-вывода или через Server-Sent Events. В нем нет встроенного управления доступами. Чтобы построить безопасную обвязку, необходимо полностью изолировать секреты. Провайдер LLM или локальный рантайм агента никогда не должен видеть ключи от ваших внутренних API. Агент лишь отправляет JSON-RPC запрос на вызов конкретного инструмента. Локальный сервер перехватывает этот запрос, идет в Vault за временным токеном с узким скоупом прав, и только затем делает реальный HTTP-вызов к целевой системе.
Права самого MCP-сервера должны быть урезаны так же жестко, как IAM-роли для публичного микросервиса. Есть вещи, которые категорически нельзя отдавать агенту ни при каких условиях. Это управление доступами, любые операции изменения состояния без аудита и широкие права на чтение, пересекающие границы тенантов. Каждый вызов инструмента через MCP обязан оставлять неизменяемый след в аудит-логе. Речь не о логировании цепочки мыслей LLM — при расследовании инцидентов этот сгенерированный текст абсолютно бесполезен. Вам нужен жесткий лог того, какой именно payload пришел на сервер, какой конкретно вызов ушел во внутреннюю систему, какова была latency этого вызова и уложился ли он в p99. Агенты склонны зацикливаться и устраивать внутренний DDoS вашим же сервисам, и в этот момент вам нужно точно знать, какой именно инструмент экстренно отключить.
При всей элегантности стандарта нужно честно признать: иногда MCP абсолютно избыточен. Если у вас есть ровно одна языковая модель, которая ходит в одну единственную базу знаний для RAG-пайплайна, тащить сюда Model Context Protocol — это архитектурный оверинжиниринг. Напишите прямой коннектор. Вам не нужен стандартизированный клиент-серверный слой для единичной интеграции. Прямые вызовы быстрее работают, их элементарно дебажить, и они не создают лишних абстракций, которые ломаются под нагрузкой. Протокол начинает окупать свою сложность только тогда, когда матрица разрастается: у вас появляются десктопные клиенты, фоновые агенты, аналитические скрипты, и всем им нужен доступ к десятку внутренних систем. Вот тогда единый слой спасает от паралича разработки.
Механика правильного self-hosted развертывания требует отношения к MCP-серверу как к критическому узлу инфраструктуры. Если вы используете stdio-транспорт, сервер делит жизненный цикл с родительским процессом агента. Это значит, что компрометация процесса агента дает прямой доступ к окружению сервера. Если вы переходите на SSE для удаленного вызова, у вас появляется сетевая граница. И поскольку сам протокол полагается на доверенную среду, вам придется самостоятельно реализовывать mutual TLS между рантаймом агента и сервером, а также добавлять слой аутентификации самих запросов. Без этого любой процесс в вашей локальной сети сможет дергать инструменты, предназначенные для ИИ.
Переход от экспериментальных песочниц к суровому Production ML требует осознания простых фактов. MCP — это великолепный стандарт интеграции, но он ничего не знает про безопасность ваших данных. Он убирает зоопарк оберток, но взамен создает централизованное бутылочное горлышко. Без вашего собственного слоя жесткой авторизации, ограничения частоты запросов и строгой валидации параметров внутри самого сервера — это просто высокопроизводительная открытая дверь в вашу инфраструктуру. Проектируйте этот слой так, будто на другой стороне сидит не услужливый ИИ-помощник, а хакер с бесконечным запасом попыток. Только тогда система выживет под реальной нагрузкой.