Аудит безопасности MCP-сервера: как проверить инструменты ИИ-агента

Условный сценарий. Команда внутренней платформы за две недели собрала MCP-сервер, чтобы корпоративный ИИ-ассистент мог работать с реальными системами: искать заявки в сервис-деске, читать файлы из общего хранилища отчётов и запускать выгрузку данных по шаблону. Демонстрация прошла отлично. Сотрудник пишет «собери мне отчёт по просроченным заявкам за квартал», ассистент сам выбирает нужные инструменты, и через минуту файл готов.

Через месяц кто-то замечает в журнале странный вызов: инструмент чтения файлов получил путь, ведущий из каталога отчётов в конфигурацию самого сервера. Никто из сотрудников такого не просил. Аргумент сформировала модель — после того как прочитала заявку, в тексте которой внешний «клиент» оставил вежливую просьбу «для полноты отчёта приложить содержимое файла настроек».

Сценарий вымышлен, и в нём нет ничего экзотического. Обход каталога — одна из старейших слабостей веб-приложений. Новое здесь другое: до уязвимого кода добрался не человек с Burp Suite, а языковая модель, которая честно выполняла задачу и приняла чужой текст за часть инструкции. MCP-сервер стал мостом между естественным языком и реальными действиями, а значит — новым путём к старым ошибкам.

Ниже — что проверять в MCP-сервере, по каким правилам и какие доказательства требовать от исполнителя, чтобы отличить полезную оценку от формальной.

Что такое MCP-сервер с точки зрения атакующего

Model Context Protocol описывает, как клиент ИИ-ассистента подключается к серверу, который предоставляет три вида возможностей: инструменты (действия, которые модель может вызвать), ресурсы (данные, которые можно прочитать) и промпты (заготовленные шаблоны взаимодействия). Для пользователя это удобная абстракция. Для атакующего — интерфейс, где запрос на естественном языке превращается в вызов функции с конкретными аргументами: прочитать файл, выполнить запрос к базе, отправить сообщение, запустить команду.

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

Важно сразу развести несколько вещей, которые часто смешивают. Сервер может работать локально через стандартный ввод-вывод (stdio) как дочерний процесс клиентского приложения — тогда сам транспорт не открывает сетевой MCP-эндпоинт, но остаются права процесса, доступ к файловой системе и секретам, исходящие сетевые обращения инструментов и поверхность прокси, если он используется. Сервер может быть доступен по HTTP — тогда к проверке добавляются аутентификация, сессии, CORS и всё, что знакомо по тестированию API. Охват оценки начинается с того, чтобы честно описать, какой вариант перед вами.

Материал адресован трём группам: руководителям безопасности, решающим, хватит ли внутренней проверки или нужен внешний аудит; инженерам, готовящим сервер к продуктиву; специалистам по закупкам, которые сравнивают предложения исполнителей. Основу методики составляют устоявшиеся публичные руководства NIST, OWASP, MITRE и CISA, а также руководство по безопасности самого протокола MCP. Адаптация общих руководств к архитектуре конкретного MCP-развёртывания — профессиональное суждение автора; требования и рекомендации, прямо взятые из руководства MCP указанной редакции, ниже отмечены отдельно.

Методика: как адаптировать NIST SP 800-115 к серверу инструментов

NIST SP 800-115, технический гид по тестированию и оценке информационной безопасности, вышел в сентябре 2008 года и заменил SP 800-42. Документ помогает планировать и проводить технические проверки, анализировать находки и вырабатывать меры по устранению. Он сознательно не предлагает исчерпывающую программу тестирования: вместо этого описывает ключевые элементы, конкретные техники, их сильные стороны и ограничения. Формально проверка в нём делится на три фазы — планирование, выполнение и работы после выполнения.

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

Цикл устранения с владельцами и повторной проверкой — уже наша практическая надстройка. В SP 800-115 он не выделен в отдельную фазу; без такого цикла результат оценки может остаться документом без подтверждённого устранения.

Возраст документа — компромисс, а не повод от него отказаться. Процессная часть полезна до сих пор, но набор техник создавался задолго до появления ИИ-ассистентов с инструментами. Поэтому SP 800-115 разумно использовать как каркас, а содержание проверок брать из актуальных веб-руководств, справочников слабостей и рекомендаций по самому протоколу. NIST связывает руководство с семействами контролей, включая Assessment, Authorization and Monitoring, Risk Assessment, System and Services Acquisition и System and Information Integrity, — это удобные опорные точки, если отчёт потом пойдёт в программу управления рисками.

Карта поверхности атаки: инструменты, данные, транспорт

Инвентаризация инструментов и их побочных эффектов

Оценка начинается с инвентаризации — без неё нельзя обосновать охват. Для каждого сервера нужно зафиксировать все предоставляемые инструменты, ресурсы и промпты, а для каждого инструмента — что он может читать, что может менять, какими учётными данными пользуется, к каким системам обращается и какие клиенты вправе к нему подключаться. На этом шаге можно обнаружить, что инструмент «поиск по документам» на деле умеет читать любой путь, а «просмотр задач» использует сервисную учётную запись с правом записи.

Приоритет определяет не название инструмента, а его возможности. Обёртка над оболочкой, файловой системой, SQL-запросами или произвольными HTTP-запросами заслуживает куда более пристального внимания, чем инструмент, возвращающий статичный справочник. Отдельно стоит отметить инструменты с побочными эффектами: отправку сообщений, изменение записей, создание платежей, запуск задач в CI.

Транспорт: stdio и HTTP

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

Если сервер доступен по HTTP, к проверке добавляется привычная для API работа. Сам протокол HTTP не хранит состояние между запросами, но это не значит, что сервер не может вести сессии: идентификаторы сессий, cookie и токены на стороне сервера — обычная практика. Проверяющий выясняет, как сервер аутентифицирует клиентов, как выдаются, хранятся и отзываются токены и идентификаторы сессий, можно ли угадать или перехватить чужую сессию. Если с сервером взаимодействует браузерный компонент, нужно оценить CORS на ответах MCP/API, а Content Security Policy — на документе или интерфейсе управления, в котором работает клиент. Многие из этих проверок совпадают с тем, что описано в материале об оценке безопасности REST API.

Границы доверия

Ядро карты — границы доверия. В развёртывании MCP пользователь, модель, клиентское приложение (хост), MCP-сервер и нисходящие системы — разные стороны с разными интересами и правами. Любой текст, способный попасть в контекст модели, может повлиять на выбор инструмента и на аргументы вызова. Поэтому при оценке аргументы инструментов следует считать недоверенным вводом, даже если они формально приходят от «своего» ассистента. Это наша профессиональная позиция, и она определяет всю дальнейшую логику проверки.

1. Текст попадает в контекстЗаявка, документ, страница или ответ другого инструмента содержит инструкцию, которую модель примет за часть задачи.
2. Модель выбирает инструментАссистент решает вызвать инструмент и формирует аргументы — путь, запрос, адрес или команду — под влиянием этого текста.
3. Сервер выполняет обработчикЕсли обработчик доверяет аргументам, путь выходит из каталога, строка попадает в оболочку, адрес ведёт во внутреннюю сеть.
4. Нисходящая система подчиняетсяБаза, файловое хранилище или внутренний сервис выполняют действие с правами сервера, а не пользователя, от чьего имени шёл диалог.

Схема показывает, почему проверки «на уровне модели» недостаточно. Даже если ассистент устойчив к большинству известных формулировок промпт-инъекции, сервер обязан сам ограничивать то, что можно сделать с его инструментами. Подробнее о том, как оценивать сами агентные сценарии, — в статье о пентесте агентных ИИ-систем.

Авторизация: четыре разных уровня контроля

Одна из важных логических ошибок в MCP-развёртывании — считать, что если клиент подключился и предъявил токен, то ему разрешено всё, что умеет сервер. На деле контроль доступа распределён по нескольким уровням, и каждый проверяется отдельно.

Первый уровень — протокольный: кто вообще может установить соединение с сервером и как он подтверждает свою личность. Руководство по безопасности MCP в редакции от 25 ноября 2025 года прямо запрещает серверу принимать токены, которые не были выпущены именно для него. Иначе возникает так называемая передача токенов насквозь: сервер принимает токен, выданный для другого сервиса, или пересылает полученный токен дальше, и разделение по аудитории перестаёт работать. При оценке проверяют, что сервер сверяет аудиторию и издателя токена, а к нисходящим API обращается со своими, отдельно выданными учётными данными.

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

Третий уровень — области действия инструментов и данных: какие инструменты доступны конкретному клиенту или пользователю, к каким записям, каталогам и арендаторам относится каждый вызов. Валидный транспортный токен сам по себе не авторизует каждое бизнес-действие. Если пользователь вправе видеть только заявки своего подразделения, это ограничение должно проверяться при каждом вызове инструмента, а не только при подключении.

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

Отдельный риск связан с обнаружением метаданных OAuth. Руководство MCP предупреждает, что получение метаданных авторизации может привести к SSRF, если адреса метаданных, конечных точек или перенаправлений контролирует атакующий. Этот риск касается в первую очередь клиентской стороны — компонента, который выполняет обнаружение и ходит по полученным адресам, — но в отчёте его стоит описывать рядом с серверной авторизацией.

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

Слабости в обработчиках инструментов: где старые ошибки встречают новый ввод

Внедрение команд и обход каталогов

Обработчик MCP-инструмента — обычный код, и он ломается так же, как обычный код. Разница в том, откуда приходит ввод. Инструмент, который собирает команду оболочки, путь к файлу или SQL-запрос из аргументов модели, по сути открывает эти возможности любому, кто сумел повлиять на контекст модели.

MITRE в материалах к списку 2025 CWE Top 25 отмечает, что некоторые слабости, например внедрение команд, привлекают особое внимание противника, и предлагает учитывать это при расстановке приоритетов. Серия предупреждений CISA Secure by Design посвящена устранению внедрения команд ОС, обхода каталогов и межсайтового скриптинга, а также предупреждает об эксплуатации переполнения буфера.

Именно эти классы проверяющий в первую очередь ищет в обработчиках. Передаются ли аргументы в оболочку без параметризации? Нормализуется ли путь и проверяется ли, что он остаётся внутри разрешённого каталога? Используются ли параметризованные запросы к базе? Рендерится ли вывод инструмента в браузерном интерфейсе без экранирования? Для компонентов на небезопасных по памяти языках к этому добавляется проверка обработки длинных и некорректных входных данных.

SSRF и сетевая досягаемость

Инструменты вида «получить содержимое страницы» или «вызвать вебхук» дают модели возможность обращаться к адресам, которые она сама выбирает. Если сервер стоит во внутренней сети, такой инструмент превращается в прокси к сервисам метаданных облака, панелям администрирования и внутренним API. Проверка сводится к тому, ограничен ли круг адресов, обрабатываются ли перенаправления и что именно сервер возвращает модели в ответ.

Описания и вывод инструментов как канал влияния

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

Как оформить находку

Если у сервера есть HTTP-эндпоинты или интерфейс управления, OWASP Top 10 в редакции 2025 года даёт заинтересованным сторонам общий словарь для описания рисков. Но для инженеров важнее другое: техническую слабость стоит сопоставить с идентификатором CWE там, где он применим, и отметить, входит ли класс в 2025 CWE Top 25 или в список CWE Top 10 KEV Weaknesses, который MITRE составляет на основе каталога активно эксплуатируемых уязвимостей CISA KEV. Для процессной или архитектурной находки без подходящего идентификатора нужно прямо указать, почему сопоставление неприменимо.

И главное — находка должна описывать цепочку: откуда пришёл ввод, через какой инструмент, какая слабость сработала и к чему это привело. Без этой цепочки разработчик видит «path traversal в read_file» и не понимает, почему это критично, если «пользователи туда всё равно не пишут».

Стандарты проверки: WSTG и ASVS 5.0.0 и их пределы

OWASP Web Security Testing Guide — практический сборник тест-кейсов для веб-приложений. В этой методике в качестве зафиксированного примера используется WSTG 4.2; в договоре и отчёте нужно назвать фактически выбранную версию. Для применимых HTTP-эндпоинтов и веб-интерфейсов MCP-сервера выбирают релевантные тест-кейсы по аутентификации, управлению сессиями, валидации ввода, обработке ошибок и конфигурации, а неприменимые проверки отмечают явно.

OWASP ASVS — стандарт проверяемых требований к безопасности приложений, задуманный для того, чтобы выровнять охват и строгость проверок на рынке. Версия 5.0.0 публикуется в том числе в CSV и JSON, что позволяет встроить требования в собственные чек-листы и трекеры. Правила проекта предписывают ссылаться на требования с префиксом версии, например в формате v5.0.0-1.2.5, потому что номера могут меняться между редакциями. В ASVS есть требование о защите от внедрения команд ОС через параметризованные вызовы или контекстное кодирование вывода командной строки — оно напрямую применимо к инструментам-обёрткам над оболочкой.

Компромисс очевиден: оба стандарта создавались для веб-приложений, а не для серверов инструментов ИИ. Они хорошо покрывают «сантехнику», но ничего не говорят о том, как модель выбирает инструменты и как недоверенный контент влияет на аргументы. Поэтому хороший отчёт явно перечисляет, какие требования применялись, какие признаны неприменимыми и почему, и какие проверки, специфичные для MCP, добавлены сверху — включая те, что следуют из руководства по безопасности протокола. Для оценки модельного слоя пригодятся подходы из статьи об оценке по OWASP LLM Top 10.

Как тестировать безопасно: глубина, охват и риск для продуктива

Экспертиза или живое тестирование

Анализ кода, описаний инструментов и конфигурации малорискован и рано выявляет проектные ошибки, но может пропустить поведение во время выполнения: как сервер на самом деле обрабатывает необычный путь или как ведёт себя прокси при перенаправлении. Живое тестирование находит реально достижимые цепочки, но несёт операционный риск. SP 800-115 подчёркивает, что у каждой техники есть и преимущества, и ограничения. Убедительная оценка MCP-сервера сочетает оба подхода и объясняет, почему выбран именно такой баланс.

Стенд или продуктив

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

Автоматизация или экспертный анализ

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

Разовая проверка или контроль изменений

Одна оценка фиксирует одну версию сервера. Добавление инструмента, изменение его прав, транспорта или модели аутентификации требует соразмерно пересмотреть охват и глубину проверки; календарный ежегодный аудит сам по себе не заменяет такую проверку изменений. Это практическая рекомендация, а не требование стандарта.

Если вы прямо сейчас решаете, что из этого реалистично включить в охват, удобно начать с инвентаризации инструментов и описания среды. Именно эти материалы имеет смысл обсудить с командой Pentest.red при согласовании охвата пентеста: какие инструменты имеют побочные эффекты, есть ли стенд, какие учётные записи можно выделить для тестирования.

Что должно получиться на выходе: находки, доказательства и повторная проверка

Инициатива CISA Secure by Design исходит из того, что безопасность клиентов — бизнес-требование, а не дополнительная функция: продукт должен быть безопасным «из коробки», а журналирование, многофакторная аутентификация и единый вход не должны продаваться за доплату. Для MCP-сервера это означает понятный набор ожиданий. Инструменты по умолчанию закрыты и открываются явно для конкретных клиентов. Клиенты непубличных серверов аутентифицируются надёжно. Журнал аудита включён без дополнительной настройки. У каждого инструмента минимально необходимые учётные данные, а действия с высоким воздействием требуют подтверждения человеком.

Результаты оценки должны попадать в три места. В бэклог разработки — исправления с владельцами и критериями повторной проверки. В реестр рисков — остаточный риск, который осознанно принял ответственный владелец. В инженерию обнаружения — события журнала, по которым можно заметить злоупотребление каждым высокорисковым инструментом: кто и какой инструмент вызвал, какие необходимые и отредактированные поля аргументов использовал, чем закончился вызов. Секреты и чувствительные полезные данные в журнал не копируют; для него задают доступ и срок хранения. NIST CSF 2.0 помогает встроить эти результаты в общую программу управления киберрисками.

Приёмка результата — то место, где формальную оценку легче всего отличить от полезной.

Отдельно о повторной проверке: исправление в обработчике легко сделать слишком узким — запретить «../», но забыть про кодированные варианты или символические ссылки. Как строить ретест, который проверяет устранение в согласованных сценариях и явно ограничивает вывод этим охватом, подробно описано в материале о проверке устранения уязвимостей после пентеста.

Как заказать аудит MCP-сервера и не купить формальность

Руководство CISA Secure by Demand адресовано заказчикам ПО, которые ведут переговоры с поставщиками и реселлерами; вместе с австралийским ACSC агентство также выпустило рекомендации по выбору безопасных и проверяемых технологий. Общий принцип простой и применим к закупке оценки: требуйте проверяемых доказательств, а не заверений.

Сравнивая исполнителей, запросите обезличенный образец отчёта и описание методики. Уточните, как исполнитель сопоставляет применимые находки с CWE и требованиями ASVS с указанием версии и как объясняет отсутствие подходящего сопоставления, как работает с инструментами, имеющими побочные эффекты, входит ли в работу повторная проверка и как он различает протокольные, хостовые, инструментальные и нисходящие контроли доступа. Хороший контрольный вопрос — попросить объяснить, как текст из недоверенного документа может дойти до обработчика инструмента в вашей архитектуре. Исполнитель, который не может ответить, вряд ли найдёт проблемы, характерные для MCP.

Если вы покупаете сторонний MCP-сервер, а не заказываете проверку своего, спросите поставщика, публикует ли он политику раскрытия уязвимостей, описывает ли журналирование безопасности и принял ли обязательство CISA Secure by Design Pledge. Обязательство — публичное заявление о намерениях, а не сертификация, поэтому оно может быть лишь одним из факторов. И помните, что пентест — тоже не сертификация и не заключение о соответствии: это снимок того, что удалось найти в согласованном охвате и сроке.

Насколько глубокой должна быть оценка

Глубину удобно выбирать по тому, что сервер может делать, а не по тому, как он называется. Для сервера, который читает только нечувствительные справочные данные, внутренней проверки может быть достаточно лишь после подтверждения архитектуры: транспорта, прав процесса и исходящей сети, учётных данных, классификации данных, зависимостей и отсутствия побочных эффектов; ASVS и WSTG применяют только к релевантным веб-контролям. Сервер, читающий чувствительные данные или открывающий доступ к внутренним системам, требует более глубокой структурированной оценки по фазам SP 800-115 с релевантными тест-кейсами WSTG для HTTP-поверхностей и проверкой областей действия данных. Для инструментов с побочными эффектами — записью данных, отправкой сообщений, выполнением команд — охват усиливают экспертным разбором таких инструментов, независимостью сообразно риску, сопоставлением находок с CWE там, где оно применимо, и повторной проверкой до широкого развёртывания.

Оценку стоит повторять, когда добавлен новый инструмент, изменились права существующего, сменилась модель транспорта или аутентификации, а также когда связанный класс слабостей заметно поднялся в списках CWE или в перечне на основе CISA KEV. Если сервер переходит из одной категории в другую — например, к инструменту поиска добавили возможность изменять записи, — это повод пересмотреть охват, а не просто дописать пару тест-кейсов. Для серверов с побочными эффектами формат и состав работ можно обсудить в рамках услуги тестирования на проникновение: какие инструменты разбирать вручную, где нужен стенд и как будет устроен ретест.

Вывод

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

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