Перейти к содержимому

Раскрытие потенциала Claude 3.5 с помощью безопасных интеграций Model Context Protocol

Раскрытие потенциала Claude 3.5 с помощью безопасных интеграций Model Context Protocol

Автор: Alexandr Balas (CEO & Chief System Architect, dlab.md) | Актуализация: март 2026

Интеграция Model Context Protocol (MCP) в 2026 году перестала быть экспериментом. Для зрелой корпоративной архитектуры это уже не «интересная опция», а нормальный способ подключать AI-агентов к внутренним системам без хаоса в доступах, логике и ответственности.

Когда компания переходит от простого LLM-чата к агентам, которые читают ERP, CRM, документы и операционные данные, вопрос упирается не в качество промпта. Вопрос в другом: как дать модели доступ к нужному контексту так, чтобы не сломать безопасность, не нарушить GDPR Article 32, не создать проблемы для RO e-Factura, SAF-T и не получить неконтролируемый канал доступа к финансовым или персональным данным.

В этом материале я разберу, почему локальное и защищённое подключение Claude 3.5 через MCP к корпоративной базе данных — это базовый архитектурный слой, а не дополнительная надстройка.

Почему кастомные API-интеграции LLM быстро упираются в потолок

Последние два года многие ИТ-команды закрывали задачу «подключить LLM к внутренним данным» самым прямым способом: писали REST-эндпоинты, добавляли middleware на LangChain, оборачивали внутренние сервисы в Python и передавали payload во внешний LLM API.

На пилоте это часто работает. В production — уже нет.

Проблема не только в поддержке кода. Самописные интеграции обычно ломаются в трёх местах:

  • нет строгой схемы tool-calling;
  • нет понятной модели разграничения доступа на уровне инструментов и ресурсов;
  • нет нормального способа масштабировать несколько агентов без дублирования логики.

В результате один агент умеет читать CRM, второй — бухгалтерские документы, третий — склад. Но каждый делает это по-своему, через отдельный слой кода, с разными правилами аутентификации и логирования. Для CISO это плохая новость. Для CTO — тоже.

Если у вас уже есть внутренние Python-скрипты и вы пытаетесь превратить их в управляемый слой для AI-агентов, полезно посмотреть, как мы подходим к этому в статье От Script-Kiddie к Enterprise: Рефакторинг Python-скрейперов в масштабируемые бекенды FastMCP. Там как раз разобран переход от «работает у одного разработчика на ноутбуке» к нормальной серверной архитектуре.

Контекстное окно LLM не заменяет доступ к данным

Одна из самых частых ошибок в интеграциях «до MCP» — попытка загрузить весь релевантный контекст в модель через RAG или прямую сериализацию больших JSON-объектов в prompt.

На практике это быстро упирается в ограничения:

  • размер context window;
  • рост стоимости inference;
  • задержки на сериализацию и передачу;
  • Out-Of-Memory на больших выборках;
  • таймауты при работе через XML-RPC или промежуточные API-шлюзы.

Поэтому зрелая архитектура строится иначе. Модель не должна «тащить» весь массив данных в контекст. Она должна уметь делать точечные вызовы к структурированным источникам данных в реальном времени и получать только то, что нужно для текущей задачи.

Это и есть практический смысл MCP.

MCP как стандартный слой между LLM и корпоративными системами

Model Context Protocol (MCP) — это открытый протокол, который стандартизирует обмен контекстом, инструментами и ресурсами между AI-клиентом и сервером доступа к данным.

Если говорить без лишней теории, MCP решает простую, но важную задачу: отделяет AI-модель от внутренней бизнес-логики. Благодаря этому вы не завязываете архитектуру на одного LLM-провайдера и не переписываете интеграции каждый раз, когда меняется SDK, формат tool-calling или политика доступа.

На практике внедрение MCP даёт три понятных эффекта:

  • снижает зависимость от конкретной LLM-платформы;
  • вводит предсказуемую схему вызова инструментов;
  • позволяет строить Zero-Trust доступ на уровне каждого запроса.

Если вы хотите глубже посмотреть на саму механику MCP в корпоративной CRM-среде, рекомендую статью Подключение ИИ-Агентов к Внутренней CRM: Разбор Архитектуры MCP. Она хорошо дополняет тему этого материала.

MCP и JSON-RPC 2.0: почему строгая схема важнее «гибкости»

В основе MCP лежит модель обмена, близкая по духу к JSON-RPC 2.0: клиент вызывает инструмент, сервер возвращает строго структурированный ответ, а не произвольный текстовый поток.

Для enterprise-сценариев это критично. Когда AI-агент запрашивает выписку для RO e-Factura, ищет документы по контрагенту или читает данные из Odoo, вам нужен не «примерно правильный» ответ, а предсказуемый контракт:

  • какой инструмент вызван;
  • с какими параметрами;
  • кто инициировал запрос;
  • что именно было возвращено;
  • можно ли это аудировать и воспроизвести.

Именно здесь самописные REST-обёртки обычно начинают рассыпаться. Они удобны до первого серьёзного аудита или инцидента.

Кейс: безопасный XML-RPC payload для Odoo 18
Ниже — деперсонализированный пример из production MCP-сервера dlab.md. Он показывает, как JSON-RPC-вызов со стороны MCP-сервера маршрутизируется в XML-RPC-интерфейс Odoo.
import os
import xmlrpc.client
import ssl


# Zero-Trust Environment Params
ODOO_URL = os.environ.get("ODOO_URL", "https://dlab.md")
ODOO_DB = os.environ.get("ODOO_DB", "bitnami_odoo")
ODOO_USER = os.environ.get("ODOO_USER", "agent_publisher@dlab.md")
ODOO_API_KEY = os.environ.get("ODOO_API_KEY") # Strict Token Requirement


def _get_odoo_models():
    """Authenticate via API Token and return models proxy."""
    ctx = ssl.create_default_context()
    ctx.check_hostname = False
    ctx.verify_mode = ssl.CERT_NONE


    common = xmlrpc.client.ServerProxy(f'{ODOO_URL}/xmlrpc/2/common', context=ctx)
    uid = common.authenticate(ODOO_DB, ODOO_USER, ODOO_API_KEY, {})


    if not uid:
        raise Exception(f"Failed to authenticate Agent ({ODOO_USER}) with generated API Token.")


    models = xmlrpc.client.ServerProxy(f'{ODOO_URL}/xmlrpc/2/object', context=ctx)
    return models, uid

Сам код выше полезен как иллюстрация маршрутизации, но в production я бы не оставлял ctx.check_hostname = False и ctx.verify_mode = ssl.CERT_NONE, если только речь не идёт о временном стенде в изолированном контуре. Для боевой среды нужен нормальный TLS с проверкой сертификата, ротацией токенов и журналированием вызовов.

Это важный момент. Без него Zero-Trust остаётся только красивым словом в презентации.

Базовая схема: Claude 3.5, FastMCP и Odoo 18

Ниже — минимальная архитектурная схема для локального или контролируемого корпоративного сценария:

[ Claude 3.5 Sonnet ] <--(MCP/JSON-RPC)--> [ FastMCP Server ] <--(XML-RPC)--> [ Odoo 18 / PostgreSQL ]

В такой схеме Claude 3.5 не получает прямой доступ к базе данных. Он работает через MCP-клиент, который видит только опубликованные инструменты. А уже MCP-сервер решает, какие вызовы допустимы, какие параметры валидны и какие данные можно вернуть.

Это принципиально лучше, чем давать модели широкий сетевой доступ к ERP или SQL.

Жизненный цикл защищённого MCP-подключения

Если упростить, безопасное подключение Claude 3.5 к внутренним данным через MCP проходит несколько этапов:

  1. Инициализация клиента: MCP Client устанавливает соединение с MCP Server.
  2. Handshake и negotiation: сервер сообщает, какие инструменты и ресурсы доступны.
  3. Вызов инструмента: клиент вызывает, например, fetch_erp_record или execute_sql_query.
  4. Проверка политики доступа: сервер валидирует токен, контекст, допустимость операции и область данных.
  5. Обращение к backend-системе: Odoo, PostgreSQL, CRM или другой источник.
  6. Возврат строго ограниченного результата: без лишних полей, без «полезной нагрузки на всякий случай».

На этом этапе особенно важно не смешивать транспорт, бизнес-логику и политику безопасности в одном месте. Как только всё это оказывается в одном Python-файле, сопровождение становится дорогим, а аудит — болезненным.

Почему `stdio` часто безопаснее, чем HTTP

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

Для распределённых сценариев HTTP или SSE тоже допустимы, но только если у вас уже есть зрелая модель аутентификации, сегментация сети, журналирование и понятные правила публикации сервисов.

Ниже — пример инициализации FastMCP для локального агента:

from mcp.server.fastmcp import FastMCP


# Initialize the MCP Server with strict namespace
mcp = FastMCP("DLab Odoo Web Editor")


@mcp.tool()
def search_odoo_views(name: str) -> str:
    """
    Search for Odoo QWeb views by name (e.g. 'bridge', 'homepage').
    Returns a formatted list of IDs and Names to help you target the right page.
    """
    # ... [XML-RPC Logic] ...


if __name__ == "__main__":
    # Bind to stdio transport for local Agent execution
    mcp.run()

Если вам интересен более широкий контекст по FastMCP и тому, как из отдельных скриптов вырастает нормальный backend-слой, снова отсылаю к статье От Script-Kiddie к Enterprise: Рефакторинг Python-скрейперов в масштабируемые бекенды FastMCP.

Безопасность MCP: что действительно нужно CISO и ИТ-директору

Основной риск при интеграции LLM с внутренними системами — не «галлюцинации» как таковые. Главный риск — неконтролируемый доступ к данным и невозможность доказать, кто, когда и зачем получил конкретную информацию.

Подключение Claude или любого другого AI-агента к ERP без Zero-Trust архитектуры — это прямой путь к проблемам с безопасностью и комплаенсом. Особенно если речь идёт о PII, финансовых документах, кадровых данных или трансграничной обработке.

С практической точки зрения я бы считал обязательными следующие меры:

  • Сервисные аккаунты и отзывные API-токены. Каждый агент работает от отдельной технической учётной записи. Пользовательские пароли в таких интеграциях использовать нельзя.
  • Минимально необходимые права. Агент должен видеть только те модели, поля и записи, которые нужны для его функции.
  • Row-Level Security и доменные ограничения. Если backend это поддерживает, ограничение должно применяться на уровне данных, а не только в UI.
  • Изолированное выполнение. MCP-серверы лучше запускать в read-only контейнерах с ограниченным набором системных вызовов и без лишних сетевых маршрутов.
  • Журналирование и трассировка. Каждый вызов инструмента должен оставлять след: кто вызвал, с какими параметрами, к каким данным был доступ.
  • Rollback-протоколы. Если агент участвует в операциях записи, должна быть предусмотрена обратимая транзакционная схема.
  • Air-gapping для чувствительных контуров. Для финансовых и персональных данных это не паранойя, а нормальная инженерная практика.

Тема защиты данных здесь напрямую пересекается с принципом privacy by design. По этой причине полезно дополнительно прочитать Data Protection by Design: Почему ваши скрипты автоматизации обходятся в €20 миллионов и Zero-Trust IT Audit: Как обезопасить бизнес-процессы перед выходом на рынки Европы.

Где MCP особенно полезен на практике

MCP особенно хорошо показывает себя не в «демо-ботах», а в сценариях, где есть реальные ограничения по данным, SLA и аудиту. Например:

  • AI-агент читает статусы счетов и отгрузок из Odoo, но не имеет доступа к зарплатным данным.
  • Claude помогает оператору находить документы для RO e-Factura, но получает только нужные поля, а не весь бухгалтерский реестр.
  • Агент анализирует инциденты в CRM и ERP, но работает через опубликованные инструменты, а не через прямой SQL-доступ.
  • При миграции с 1C или SAP MCP используется как промежуточный Data Bridge, который даёт контролируемый доступ к legacy-данным без открытия всей системы наружу.

Последний сценарий особенно важен для компаний, которые одновременно модернизируют ERP и внедряют AI-слой. В таком случае рекомендую посмотреть Миграция с устаревших систем (1C, SAP) на Odoo 19: Оценка рисков и Дорожная карта, потому что там хорошо видно, где именно появляются риски при совмещении миграции и автоматизации.

Что меняется для enterprise-команды в 2026 году

В 2026 году уже недостаточно просто «подключить LLM к данным». Для production-среды нужен управляемый слой доступа, который:

  • не зависит жёстко от одного вендора модели;
  • поддерживает аудит и воспроизводимость вызовов;
  • вписывается в требования GDPR, SAF-T, RO e-Factura и EU AI Act;
  • не превращает AI-интеграцию в новый теневой IT-контур.

Именно поэтому MCP становится не модным словом, а нормальным архитектурным выбором.

Если коротко: кастомный API можно собрать быстро. Но поддерживать его годами под нагрузкой, аудитом и требованиями безопасности — совсем другая задача. MCP здесь выигрывает не за счёт «новизны», а за счёт дисциплины интерфейсов и предсказуемости интеграции.

Вывод

Переход от самописных API к Model Context Protocol — это не косметическое улучшение. Это способ навести порядок в доступе AI-агентов к корпоративным данным.

Для Claude 3.5 это особенно важно, потому что сама модель сильна ровно настолько, насколько аккуратно вы построили слой инструментов, политик доступа и транспорт. Если этот слой сделан плохо, никакая модель не спасёт архитектуру. Если сделан правильно — AI-агент становится полезным рабочим компонентом, а не источником новых рисков.

Для enterprise-среды я бы сформулировал это так: MCP — это не про удобство интеграции. Это про управляемость, безопасность и возможность масштабировать AI без потери контроля.

*

Discover More