Безопасные паттерны MCP для агентов, изменяющих бизнес-состояние

Минимальный MCP-сервер, демонстрирующий три паттерна безопасного предоставления ИИ-агентам доступа на запись к реальным бизнес-системам: фазовое гейтирование, валидация перед изменением и структурированное аудиторское логирование.

Это демо, а не продукт. Предметная область (игрушечная система инвентаря и заказов на закупку) существует только для того, чтобы дать паттернам конкретное применение — сами паттерны и есть суть, и они не зависят от предметной области.

Зачем это существует

ИИ-агентам всё чаще предоставляют доступ на запись к реальным системам — заказам, инвентарю, CRM-записям, прогнозам. Типичный сценарий отказа не в том, что базовая LLM ненадёжна в каком-то абстрактном смысле; проблема в том, что реализации часто доверяют модели «поступить правильно» без каких-либо структурных защитных механизмов. Когда агент галлюцинирует состояние, поддаётся манипуляции через prompt injection или просто путает порядок операций, результатом становится тихая некорректная запись в систему, которую человеку теперь придётся заметить, диагностировать и исправить постфактум.

Три паттерна ниже — не новое исследование; это стандартная инженерная дисциплина для всего, что касается производственного состояния, применённая конкретно к вызовам инструментов агента.

Related MCP server: commerce-ops-harness

Три паттерна

1. Фазовое гейтирование. Операция изменения (submit_purchase_order) не может завершиться успешно, если соответствующая операция чтения/предпросмотра (draft_purchase_order) не была выполнена первой, в той же сессии. Это обеспечивается в коде — жёсткая ошибка, а не инструкция в промпте, которую модель может проигнорировать или отговорить. Сообщение об ошибке точно говорит вызывающей стороне, что делать дальше, — именно это позволяет агенту самокорректироваться, а не просто падать.

2. Валидация перед изменением. Каждая проверка — существует ли SKU, разумно ли количество, не превышает ли это разумный порог заказа — выполняется над чистым представлением предлагаемого изменения, до любой записи. Валидация никогда не имеет побочных эффектов. И главное: все проверки выполняются независимо от более ранних ошибок, поэтому вызывающая сторона видит все проблемы сразу, а не исправляет одну, повторно отправляет и натыкается на следующую.

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

Демо

• examples/happy_path.md — черновик → проверка → отправка, с реальным захваченным выводом

• examples/blocked_paths.md — пять способов, которыми защитный слой реально останавливает плохой вызов, также с реальным выводом

Попробуйте сами

pip install -r requirements.txt
pytest tests/ -v          # 17 tests, exercises every pattern above
python server.py          # runs the MCP server over stdio

Тесты — это фактическое доказательство, а не проза выше. Если вы хотите проверить утверждение из этого README, соответствующий тест — лучший источник истины, чем моё описание.

Структура

server.py              # MCP tool definitions — thin, delegates everywhere
safety/
  phases.py             # session state + the phase gate itself
  validation.py         # pure validation functions
  audit.py               # structured logging, including failures
domain/
  inventory.py           # toy in-memory "database"
  purchase_orders.py    # draft/commit data + transformations
tests/                   # one file per pattern, ~17 tests total
examples/                 # real captured walkthroughs

safety/ и domain/ не импортируют друг друга в том направлении, которое вы ожидали бы от разделения «бизнес-логика» и «защитные механизмы»: доменный слой понятия не имеет о сессиях или одобрении. Гейт живёт полностью вне его, в safety/phases.py, который решает, будет ли вообще достигнут domain.purchase_orders.commit_draft(). Это разделение намеренно — именно оно позволяет рассуждать о свойствах безопасности, не рассуждая одновременно о логике инвентаря.

Чем это не является

Не производственный код. Нет реальной базы данных — инвентарь это Python-словарь. Нет аутентификации. Состояние сессии в памяти и в одном процессе. Это существует, чтобы сделать паттерны безопасности инспектируемыми и тестируемыми изолированно, а не для того, чтобы быть системой, которую кто-то должен разворачивать.

Предыстория

Я проектировал и создавал производственные MCP-серверы (Go, Kubernetes) во время стажировки в Eli Lilly, включая фазовое гейтирование доступа к инструментам и обязательную валидацию перед любой операцией развёртывания, изменяющей состояние. Это демо создано с нуля, в другой предметной области, без использования какого-либо из того кода — оно изолирует те же базовые паттерны, чтобы их можно было читать, запускать и тестировать без доступа к чему-либо проприетарному.