Подключение MCP превращает ИИ-агента из собеседника в участника корпоративной инфраструктуры: он получает инструменты, доступы и возможность выполнять действия. Разбираемся, где в этой цепочке заканчивается доверие и какие контроли должны остановить опасный вызов до того, как он достигнет системы.
Если вы уже подключаете ИИ-агентов к коду, данным и корпоративным сервисам, сверьте свой подход с практикой курса «Безопасность ИИ-систем и агентов», где эту архитектуру разбирают на работающем стенде.
Сам по себе ИИ-агент может выглядеть довольно безобидно: получает запрос, формирует ответ, иногда обращается к базе знаний. Риск меняется качественно, когда у агента появляются инструменты. Теперь он способен не только рассуждать, но и читать файлы, обращаться к API, работать с репозиторием или запускать предусмотренные разработчиками операции.
MCP упрощает подключение таких возможностей, но не отменяет главный вопрос безопасности: кто, кому и на каких условиях разрешил выполнить конкретное действие? Ответ «агент вызвал инструмент через доверенный сервер» здесь недостаточен.
Три участника — три разные зоны доверия
В минимальной схеме есть агент, MCP-сервер и инструмент. Их легко мысленно объединить в одну систему, особенно если все компоненты развернула одна команда. Для моделирования угроз полезнее считать их отдельными зонами.
Агент работает с инструкциями и контекстом. Часть этого контекста может прийти из недоверенного источника: документа, базы знаний, issue, pull request или ответа другого агента. Даже если исходный запрос пользователя безопасен, дальнейшая цепочка инструкций может изменить намерение агента.
MCP-сервер посредничает между рассуждением и действием. Он публикует доступные инструменты, принимает параметры вызова и передаёт запрос дальше. Сервер не должен считать корректно сформированный запрос автоматически разрешённым: синтаксическая валидность ничего не говорит о допустимости операции.
Инструмент соприкасается с реальным активом — данными, кодом, API или инфраструктурой. Именно здесь абстрактная ошибка превращается в чтение лишней информации, изменение объекта или запуск нежелательной операции.
Поэтому доверительная граница проходит не вокруг всей MCP-интеграции. Она возникает на каждом переходе: контекст → агент, агент → MCP-сервер, сервер → инструмент, инструмент → целевая система и результат → обратно в контекст агента.
Почему доверенный агент может сделать недоверенное действие
Одна из самых опасных иллюзий звучит так: «Мы используем проверенную модель и собственный MCP-сервер, значит вызовам можно доверять». Но действие определяется не только моделью. На него влияют инструкции, извлечённые данные, память, результаты предыдущих инструментов и делегирование между агентами.
Если агент обработал недоверенный документ с внедрённой инструкцией, он может выбрать допустимый инструмент для недопустимой цели. Если сервер проверяет только название функции и формат параметров, запрос пройдёт. Если сам инструмент работает с широкими правами, цена такой ошибки возрастёт.
Получается неприятная цепочка: каждый компонент по отдельности ведёт себя «штатно», но система в целом нарушает ожидаемую политику. Именно поэтому безопасность нельзя сводить к фильтрации промпта или одному guardrail перед моделью.
Что должен проверять MCP-сервер
MCP-сервер — удобная точка применения политики, но только если он действительно принимает решение, а не работает прозрачным прокси. Минимальный набор вопросов перед вызовом выглядит так:
- кто инициировал действие и от чьего имени работает агент;
- разрешён ли этому субъекту выбранный инструмент;
- допустима ли конкретная операция, а не только сам инструмент;
- соответствуют ли параметры разрешённой области данных;
- требует ли действие подтверждения человека;
- можно ли безопасно выполнить его в песочнице;
- какие сведения должны попасть в журнал;
- что произойдёт при ошибке проверки или недоступности политики.
Важно разделять доступ к инструменту и разрешение на действие. Агенту может быть разрешён клиент репозитория, но не изменение защищённой ветки. Доступ к файловой системе не означает право читать секреты. Возможность вызвать внешний API не должна автоматически разрешать произвольный адрес и любой объём данных.
Allowlist полезен, но его недостаточно
Список разрешённых инструментов сокращает поверхность атаки, однако не описывает все опасные комбинации. Безопасный по отдельности вызов может стать рискованным в последовательности: получить данные, преобразовать их и передать во внешнюю систему.
Поэтому матрицу разрешений стоит строить как минимум по четырём измерениям: identity, tool, action и target. Для критических операций добавляется approval, а для сетевых взаимодействий — ограничения направления и назначения. Политика должна отклонять неизвестное по умолчанию, а не пытаться перечислить только очевидно опасные варианты.
Посмотреть, как ограничения MCP и полномочий агента проверяются на практике можно в программе курса по безопасности ИИ-систем.
Логи должны отвечать на вопрос «почему»
Записи вида «инструмент вызван успешно» мало помогают при расследовании. Для восстановления цепочки действий нужны субъект, сессия, источник инструкции, выбранный инструмент, параметры после нормализации, решение политики, факт подтверждения, результат и последующее действие агента.
Такой журнал нужен не только после инцидента. На его основе можно искать необычные инструменты, новые последовательности вызовов, нетипичные доступы и сетевые взаимодействия. Если поведение выходит за допустимые рамки, система должна уметь заблокировать действие, остановить сессию, отозвать доступы или передать решение человеку.
Отдельно нужно определить условия восстановления и повторного допуска. Простого перезапуска агента недостаточно, если не устранён источник недоверенной инструкции и не проверена эффективность защитной меры.
Проверять нужно цепочку целиком
Хорошая security-evaluation начинается с модели угроз. Сначала команда фиксирует активы, потоки данных, доверительные границы и цену ошибки. Затем формулирует негативные сценарии: попытку indirect prompt injection, опасный tool call, обращение к запрещённому target, обход approval или делегирование операции другому агенту.
После исходного теста добавляется контроль — validation, policy enforcement, allowlist, sandbox или подтверждение критического действия. Затем тот же сценарий запускается повторно. Защита считается полезной не потому, что она присутствует в архитектуре, а потому, что опасное действие блокируется или завершается безопасным отказом и это поведение сохраняется после изменений.
MCP не является ни доверенной зоной, ни уязвимостью сам по себе. Это граница, на которой намерение модели превращается в действие. Чем яснее здесь определены идентичность, полномочия, политика, журналирование и безопасный отказ, тем меньше система зависит от надежды на «правильное» поведение агента.
От модели угроз до защищённого прототипа
На курсе CyberED «Безопасность ИИ-систем и агентов» участники проходят путь от анализа архитектуры и моделирования угроз до защищённого прототипа ИИ-агента. В практической работе они подключают инструменты, включая MCP-инструмент, формируют матрицу разрешённых действий, реализуют ограничения полномочий, воспроизводят атаку и проводят повторный тест после усиления защиты. Итог дополняют security-evaluation, release-критерии, журналирование и сценарий реагирования.
Ведущие курса — Денис Макрушин, директор по продуктам безопасной разработки в Яндексе, и Глеб Михеев, Chief Product Officer ГигаАгента в Сбербанке.
