Собственный MCP-сервер для вашего бизнеса: сначала только чтение, запись позже и с подтверждением

Когда команда просит ИИ-ассистента проверить заказы, я сначала спрашиваю, какие заказы ему можно видеть. Само подключение решает только часть задачи. Нужно также определить права доступа и форму ответа.

MCP даёт общий интерфейс для инструментов. В первой версии у меня узкий набор запросов. Запись появляется позже, когда команда проверит, как работает чтение.

Что дорожная карта обещает и чего не обещает

В посте мейнтейнеров MCP от 22 августа 2026 описаны пять приоритетных направлений. Среди них идентификация агентов и корпоративная безопасность: работа над DPoP, workload identity и token exchange. Ещё одно запланированное направление: поэтапное обнаружение инструментов.

В посте также сказано, что релиз июля 2026 упрощает эксплуатацию удалённых серверов как обычных HTTP-сервисов. Я вижу в этом повод применять обычные меры контроля для сервисов: аутентифицировать вызывающих, авторизовать операции, записывать результаты и давать возможность отозвать доступ. Дорожная карта не добавляет эти меры в интеграцию автоматически.

Почему у чтения тоже нужны границы

В исследовании Invariant Labs от апреля 2025 показали инструкции, спрятанные в описаниях инструментов. Ассистент мог следовать им, а со стороны выглядело, будто он выполняет запрошенное вычисление. Это prompt injection, даже если заявленный инструмент выглядит безобидно.

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

CSA рекомендует повышать доверие постепенно, начиная с ограниченного доступа на чтение и надзора. Я использую это как ориентир для внедрения, а не как гарантию безопасности.

Первая версия

Я согласую с командой короткий каталог инструментов:

• Один вопрос на инструмент. Остатки по товару, заказы по статусу или поиск по утверждённой политике.
• Права соблюдаются в источнике. Вызывающий видит только разрешённые записи и поля. Попытки записи должны завершаться ошибкой.
• Проверенные код и конфигурация сервера. Процесс получает только те учётные данные и доступ к файлам, которые ему нужны.
• Полезный журнал аудита. Кто вызвал, какой инструмент, когда, каков исход и безопасная ссылка на результат. Секреты и персональные данные я скрываю, а не пишу в журнал каждый payload целиком.
• Проверенные подключения. Одобренные серверы и описания инструментов; изменения проверяются до использования.

Я проверяю не только обычные ответы, но и доступ не из того аккаунта, чрезмерные запросы и внедрённое содержимое. Успешный ответ подтверждает только одну из приёмочных проверок.

Добавление записи

Один инструмент готовит счёт, другой его отправляет: это разные действия. Каждому я даю нужные ему права, а в первой версии прошу человека подтвердить конкретный объект и действие.

Журнал фиксирует, что изменилось и кто это подтвердил. Повторные попытки и восстановление нужно спроектировать до релиза. Тот же подход я описываю в гайде обработка запросов ИИ с проверкой человеком.

Могу сделать это вместе с вами

Результат работы: небольшой каталог инструментов с проверенными границами доступа, журнал аудита и согласованный порядок добавления операций записи. Страница ситуации: собственный MCP-сервер; услуга: API-интеграции и автоматизация. Если задача понятна, я могу сразу составить смету на реализацию.