Мы живем в эпоху, когда агенты на базе искусственного интеллекта, протокол MCP (Model Context Protocol) и приложения, управляемые большими языковыми моделями (LLM), внедряются в кодовые базы быстрее, чем традиционные программы информационной безопасности успевают их отслеживать. Это не просто технический нюанс — это фундаментальный сдвиг в парадигме разработки. Раньше безопасность приложений (AppSec) опиралась на четкое понимание того, что код делает ровно то, что в нем написано. Сегодня поведение AI-агента эмерджентно: оно возникает из сложного взаимодействия модели, системного промпта, извлеченного контекста, пользовательского ввода и инструментов, которые агент может вызывать. Два идентичных развертывания одного и того же агента могут вести себя по-разному в зависимости от контекста, что делает традиционные методы сканирования уязвимостей недостаточными.
Новое практическое руководство от Mend.io, озаглавленное «Securing AI agents, MCP servers & LLM apps: A practical framework», призвано закрыть этот критический пробел. Документ не предлагает абстрактных теорий, а предлагает конкретный фреймворк, состоящий из трех ключевых этапов: увидеть то, что важно, быстрее исправить то, что важно, и защитить AI в продакшене. В основе этого подхода лежат семь повторно используемых артефактов, которые позволяют инженерам по безопасности и разработчикам перейти от реактивного тушения пожаров к проактивному управлению рисками. Давайте разберем каждый этап подробно, чтобы понять, как применить эти принципы в реальных условиях, особенно с учетом ограничений доступа из РФ и необходимости локального запуска.
01Почему традиционная AppSec ломается о AI
Традиционная безопасность приложений строилась на предположении, что уязвимости находятся в коде. Если вы исправите баг в строке 42, приложение станет безопаснее. В мире AI-агентов это правило перестает работать. Поведение агента не зашито жестко в бинарник; оно «вычисляется» на лету. Это порождает новые режимы отказов (failure modes), которые не попадают в стандартные базы данных CVE.
Например, инъекция промпта (prompt injection) теперь может приходить не через уязвимый параметр в коде, а через данные. Если агент получает доступ к внешнему документу, содержащему вредоносные инструкции, он может выполнить их, даже если сам код агента идеален. Переуполномоченный агент может нанести вред, не эксплуатируя никаких уязвимостей — просто выполнив разрешенное действие в неподходящем контексте. Устаревшая модель может продолжать выдавать предсказания после того, как ее разработчик перестал выпускать патчи безопасности. Отравленное описание инструмента на MCP-сервере может перенаправить поведение агента, не трогая код приложения вовсе. Мандат для инженеров становится двусторонним: нужно не только сдвинуть безопасность влево (shift left, то есть интегрировать проверки на ранних этапах), но и защитить систему справа (protect right, то есть в моменте выполнения).
02Артефакт 1.1: Карта поверхности атаки в пять слоев
Первый шаг к безопасности — понимание того, где именно кроются риски. Mend.io предлагает карту, разделенную на пять слоев. Каждый слой имеет свои векторы атак и свои уязвимости.
1. Взаимодействие (Interaction): Это точка входа. Сюда относятся пользовательские вводные, извлеченные документы и сообщения между агентами. Основные угрозы здесь — инъекция промпта, отравление контекста и утечка данных. Если вы не контролируете входные данные, вы не контролируете выход.
2. Агент (Agent): Здесь находятся системные промпты, конфигурации, память и настройки автономности. Риски включают слишком широкие права доступа к инструментам, небезопасные настройки по умолчанию и перехват целей (goal hijacking), когда агент начинает преследовать чужую цель, заложенную в промпте.
3. Интеграция (Integration): MCP-серверы, определения инструментов, плагины и API. Здесь кроются угрозы отравленных описаний инструментов (tool poisoning), несекьюреных учетных данных и «теневых» серверов, которые не были утверждены архитекторами.
4. Модель (Model): Базовые и дообученные модели, эмбеддинги. Риски связаны с использованием моделей, достигших конца жизненного цикла (EOL), рисками цепочки поставок (supply chain) и генерацией небезопасного контента.
5. Код (Code): Код, сгенерированный AI, фреймворки AI, SDK. Классические уязвимости, CVE в фреймворках и вредоносные пакеты, которые могут быть внедрены через зависимости.
Охота на теневых агентов и MCP-серверы
Агенты редко попадают в инфраструктуру через официальные закупки. Чаще всего они появляются как «теневые» инициативы разработчиков. Существует три категории, которые нужно искать: теневые агенты (shadow agents), незарегистрированные MCP-серверы и встроенные AI-фреймворки. Каждый MCP-сервер должен иметь владельца, четкий объем доступа и регулярный пересмотр.
Существует пять методов обнаружения. Во-первых, сканирование репозиториев на наличие «агентных сигнатур» (специфичных библиотек или паттернов кода). Во-вторых, мониторинг исходящего сетевого трафика на вызовы к конечным точкам API моделей. В-третьих, аудит сервисных аккаунтов и API-ключей. В-четвертых, упрощение регистрации через легкие процессы декларирования. В-пятых, автоматизация процесса, так как однократное обнаружение быстро устаревает.
03Артефакт 2.1 и 2.2: Инвентаризация и проверка конфигураций
После обнаружения необходимо структурировать данные. Артефакт 2.1 расширяет понятие AI-BOM (Bill of Materials) для AI-систем, добавляя девять ключевых полей для каждого агента или MCP-сервера: идентификатор, зависимость от модели, уровень автономности, разрешения инструментов, объем учетных данных, доступ к данным, конечные точки MCP, расположение промпта и дата последнего пересмотра. Это позволяет создать полный паспорт безопасности для каждого компонента.
Артефакт 2.2 представляет собой чек-лист из 12 пунктов для выявления неправильных конфигураций. Ключевые пункты включают:
- Учетные данные должны быть ограничены конкретными ресурсами, а не предоставлять широкий доступ на уровне сервиса.
- Запрет на использование общих учетных данных между разными агентами.
- Инструменты с высоким уровнем воздействия должны требовать одобрения человека.
- Системные промпты должны храниться в системе контроля версий, а не редактироваться напрямую в продакшене.
- MCP-серверы должны аутентифицировать клиентов.
- Описания инструментов должны проверяться на наличие контента, способного вызвать инъекцию, перед внедрением.
- Версии моделей должны быть зафиксированы (pinned), с мониторингом окончания поддержки (EOL) и назначенным владельцем.
04Артефакт 3.1: Приоритизация и триаж уязвимостей
Поскольку количество потенциальных проблем огромно, критически важна система приоритизации. Пайплайн должен работать по схеме: обогащение → приоритизация → триаж. Сигналы для приоритизации, расположенные по убыванию ценности, следующие:
- Доступность (Reachability): Может ли атака быть осуществлена извне или из текущего контекста?
- Контекст эксплуатации: Насколько легко эксплуатировать уязвимость?
- Бизнес-контекст: Какой ущерб нанесет инцидент бизнесу?
- Агентное усиление: Может ли агент использовать уязвимость для выполнения цепочки действий?
- Доступность исправления: Есть ли уже патч или обходное решение?
Артефакт 3.1 определяет линию автоматизации. Для хорошо понятных классов уязвимостей с подтвержденной доступностью решение принимается автоматически. Для случаев с ложными срабатываниями (FP/TP) требуется автоматизация с выборочной проверкой и следствием доказательств. Для приложений 3-го уровня или с высоким риском, а также для новых классов угроз и поведения AI, где нет достаточных доказательств, решение должно приниматься только человеком. Принятие рисков или отсрочка исправления также требует ручного документированного решения.
Правило номер один: каждое автоматическое закрытие инцидента должно сопровождаться доказательной базой. Если система не может показать, почему это ложное срабатывание, задача передается человеку. Ошибки подвергаются выборочному аудиту, а пороги ошибок запускают переобучение моделей триажа.
05Артефакт 4.1: Защита во время выполнения (Runtime Security)
Даже при идеальной настройке на этапе разработки, runtime-защита необходима. Она включает в себя «ограничители» (guardrails), укрепление промптов, enforcement политик и мониторинг. Этот процесс работает как петля: результаты AI-red teaming улучшают guardrails, а логи guardrails направляют следующие тесты red teaming.
Guardrails могут развертываться двумя способами. Первый — через встроенный Python SDK (поддерживающий онлайн или изолированный офлайн-режимы). Второй — как отдельный API-сервер (Docker), не требующий изменений в коде или зависимостей Python. Минимально жизнеспособная настройка включает входящие guardrails, которые перехватывают инъекции промптов, запросы вне политики и джейлбрейки, а также исходящие guardrails, которые блокируют утечку учетных данных, PII (персональных данных), проприетарного кода, небезопасного контента и нарушений политик.
Укрепление системных промптов следует пяти паттернам: предположение о раскрытии (assumption of disclosure), разделение инструкций и данных, ограничение радиуса поражения (blast radius), версионирование/пересмотр и adversarial-тестирование. Важно помнить: строгие разрешения (permissions) эффективнее инструкций в промпте. Запрет доступа к инструменту устраняет необходимость инструктировать модель не выполнять опасные действия.
06Дорожная карта зрелости
Для оценки текущего состояния организации предлагается дорожная карта из четырех этапов: Emerging (Возникающий), Developing (Развивающийся), Controlling (Контролирующий) и Leading (Лидирующий). Эта модель согласована с NIST AI RMF, OWASP AIMA, ISO/IEC 42001 и EU AI Act. Артефакт 5.1 представляет собой самооценку из 15 вопросов. Результат 0–5 указывает на этап Emerging, 6–10 — Developing, 11–13 — Controlling, и 14–15 — Leading. Это позволяет командам не только фиксировать проблемы, но и планировать путь к зрелости безопасности AI.
07Что это значит на практике
Для российских компаний и разработчиков, работающих с AI, эти рекомендации приобретают особый смысл. Во-первых, из-за ограничений доступа к некоторым зарубежным облачным сервисам и API, многие проекты переходят на локальные модели или гибридные схемы. В этом контексте пункт о «фиксации версий моделей» и «мониторинге EOL» становится критическим. Вы не можете полагаться на автоматические обновления от провайдера, если провайдер прекратил поддержку или ограничил доступ. Вам нужно самостоятельно управлять жизненным циклом моделей.
Во-вторых, использование MCP-серверов и агентов в локальной среде требует строгой изоляции. Теневые агенты, созданные разработчиками для экспериментов, могут получить доступ к внутренним базам данных или корпоративным API. Чек-лист из 12 пунктов, особенно требование об аутентификации клиентов для MCP-серверов и ограничении прав учетных записей, должен стать стандартом де-факто даже для внутренних инструментов.
В-третьих, runtime-защита через Docker-контейнеры с API-сервером guardrails позволяет внедрить безопасность без переписывания существующего кода на Python. Это особенно важно для легаси-проектов или систем, где внедрение новых SDK невозможно. Локальный запуск такого сервера обеспечивает контроль над данными, не покидающими периметр компании, что соответствует требованиям по суверенитету данных.
Наконец, культура безопасности должна измениться. AI-агенты — это не просто код, это динамические сущности. Инженеры по безопасности должны работать в тесной связке с ML-инженерами, используя артефакты Mend.io как общий язык. Автоматизация триажа освобождает время для анализа сложных, новых угроз, которые требуют человеческого суждения. В конечном итоге, безопасность AI — это не продукт, который можно купить, а процесс, который нужно непрерывно улучшать, используя структурированные фреймворки и четкие артефакты управления.
Полное руководство от Mend.io доступно для детального изучения. Оно предоставляет не просто теорию, а готовые шаблоны, чек-листы и метрики, которые можно адаптировать под любую инфраструктуру, будь то облачная или полностью локальная. Интеграция этих практик сегодня — это инвестиция в устойчивость ваших AI-продуктов завтра.
Источник: MarkTechPost ↗