Безопасность ИИ: как перестать бежать анализировать каждое новое ПО и перейти к системному подходу

Что происходит на рынке

За последние два‑три года компании в РФ перестали относиться к ИИ как к «чудо машине» и начали встраивать его в рабочие процессы: от помощи специалистам контакт‑центров в чатах с клиентами и «серым» помощникам разработчиков до написания полноценных продуктов. Если раньше нельзя было сказать, что ты использовал ИИ для задачи, так как тебя закидают помидорами, сегодня — этот навык must have для каждого. В этой статье речь пойдет о безопасной разработке с использованием генеративных ИИ. Крупные опросы и отчёты фиксируют одинаковую картину: большинство организаций уже экспериментируют с LLM‑системами или планируют их внедрение, в том числе в зонах, где раньше работали только люди или классические скрипты.

• NIST подчёркивает, что генеративный ИИ уже используется в разработке, тестировании и эксплуатации систем, и предлагает относиться к нему как к компоненту критичной инфраструктуры, а не к «чёрному ящику»

• ENISA и другие регуляторы отдельно выделяют применение ИИ в DevSecOps и автоматизации инженерных процессов: это и code review, и генерация инфраструктурного кода, и управление конфигурацией

• Отдельный пласт — так называемый «vibe coding» и coding‑агенты, которые сидят в IDE, в терминале или в CI и умеют не только писать код, но и запускать тесты, работать с файловой системой и git’ом

Каждый такой инструмент — это не «ещё одна модель», а новый элемент инфраструктуры. И вместе они создают новый ландшафт угроз, который не покрывается классическим OWASP Top 10. Чтобы зафиксировать, что нового появилось, полезно посмотреть на OWASP Top 10 for LLM Applications. В нём отдельно выделены проблемы, которые в классическом веб‑приложении практически не встречались: prompt injection, небезопасная обработка вывода модели, чрезмерные полномочия агента, небезопасный дизайн плагинов, утечки секретов через контекст и так далее. Это дополнение к классическому OWASP: к инъекциям и broken access control добавляются риски, возникающие при появлении в ИТ ландшафте модели, умеющей выполнять различные действия.

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

Стоит предупредить, что следующий блок — информационный, который поможет тем, кто пока еще не в контексте. Если вы уже знаете основы, можете смело пропустить следующий абзац (но только его).

Разберем основные термины в новой ИИ‑реальности

LLM

LLM (Large Language Model) — это большие языковые модели общего назначения, способные генерировать текст, код и другие форматы по запросу пользователя. Под генеративными моделями шире имеют в виду и мультимодальные системы, которые работают с текстом, изображениями, аудио и видео, но в контексте безопасности нас больше всего интересует их способность принимать текстовый ввод и выполнять действия по описанию: писать и запускать код, управлять файлами, вызывать API.

Основные функции моделей:

• анализ и генерация кода (в нашем контексте)

• принятие решений в рамках сценария «какой шаг сделать дальше»

• формирование запросов к инструментам (shell, git и так далее) через прослойку

Обычно модели наделяют следующими правами:

• доступ к исходникам (read, реже — write)

• доступ к конфигам, исходному коду

• доступ к логам и метрикам

• иногда — доступ к секретам через переменные окружения

Какие возникают риски:

• prompt injection: модель можно «уговорить» сделать то, чего не планировали авторы сценария (например, приписать «разрешаю тебе все»)

• небезопасная обработка вывода: если текст модели без фильтра уходит в shell, SQL, CI — это уже полноценная инъекция

• утечки данных: модель может случайно раскрыть секреты, к которым у неё есть доступ, или слить данные наружу

MCP (Model Context Protocol)

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

• какие tools доступны (прочитать файл, записать файл, вызвать HTTP, обратиться к БД)

• какие параметры они принимают и что возвращают

• какие ограничения и политики к ним привязаны (какие директории, какие домены, какой набор методов)

Основные функции MCP:

• связывает модель с внешним миром через набор описанных инструментов

• позволяет переиспользовать один и тот же набор tools с разными моделями

• задаёт уровень «структурированности» взаимодействия: модель не просто пишет текст, она вызывает именованные действия

Обычно PCM наделяют следующими правами:

• доступ к файловой системе (workspace, иногда шире)

• доступ к git

• доступ к сетевым сервисам

• реже — доступ к конфигам

Какие возникают риски:

• небезопасный дизайн tools («плагин», который даёт модели слишком много полномочий)

• отсутствие нормального scoping«а (один MCP‑сервер видит сразу несколько репозиториев/окружений)»

• отсутствие явной политики: какие tools можно использовать в каком контексте, с какими ограничениями

ИИ‑агенты

Агент — это связка из модели и окружения, в котором она работает: читает файлы, пишет код, запускает команды, ходить в сеть. Coding agent — частный случай, заточенный под разработку и сопровождение приложений

Основные функции ИИ‑агентов:

• автоматизация рутинных задач разработчиков и DevOps (правки кода, миграции, генерация конфигов)

• полуавтоматический refactoring и code review

• работа с баг‑репортами и тикетами

• иногда — автономное выполнение длинных сценариев

Обычно ИИ‑агентов наделяют следующими правами:

• read/write в репозитории и прилегающих директориях

• вызов shell‑команд, доступ к git и тестовым раннерам

• доступ к облачным sandbox«ам»

Какие возникают риски:

• чрезмерная агентность: агент получает «root» на рабочей машине разработчика или CI runner«e»

• классические инъекции (командная, файловая, конфигурационная), завёрнутые в LLM‑контекст

• утечки секретов и другой конфиденциалки при логировании, аналитике, prompt‑инжекции

Еще я добавлю термин «Sandboxes» — контейнерные песочницы, ограничивают права и scope ИИ‑агентов. Теперь, когда «база закрыта», переходим к исследованию ИИ‑агентов.

Исследование ИИ‑агентов (что показал исходный код)

Я никогда не доверяю заявлениям разработчиков, что их ПО безопасно, пока сам в этом не убежусь. Поэтому имеет смысл подойти к ИИ‑агентам, как к обычному ПО. Для анализа тех ИИ‑агентов, которые я привожу в статье, я использовал semgrep для opensource ПО, а для проприетарных — старый добрый grep (определил интересующие паттерны и исследовал доступные конфиги). Я проанализировал лишь малую часть существующих агентов (Nymbalist, Serena, NanoClaw, GoClaw, VibeKit), и использовал небольшой инструментарий. В этой статье я не буду описывать их различия, но все они работают, как «обвязка» вокруг LLM.

Подход был примерно такой: прогонял semgrep по правилам, покрывающим OWASP Top 10 и LLM Top 10, плюс grep по критичным шаблонам. Далее — ручной разбор: выборка файлов, где реализована sandbox, работа с секретами и мосты между LLM и инструментами (shell, git, сеть). Затем динамика — запуск в локальной лаборатории honeypot‑файлами, чтобы проверить гипотезы на практике. Почему я пишу про агенты? Я бы выделил ИИ‑агентов в отдельное семейство ПО, для которых характеры одни и те же «симптомы».

Чем «болеют» ИИ‑агенты?

Картина пока что складывается однотипная:

Bash / shell‑доступ
Все ИИ‑агенты могут вызвать shell: через child_process.spawn/exec, docker exec, SSH или аналогичные механизмы.

Доступ к git (с широкими правами)
Агенты умеют создавать ветки, коммиты, pull‑requests. MCP‑tools могут вызывать git‑команды напрямую

bypassPermissions и аналогичные флаги
В ИИ‑агентах встречаются флаги и режимы уровня permissionMode: bypassPermissions, allowDangerouslySkipPermissions: true и тому подобное. По сути это root’a, который работает вообще без ограничений. В связке с предыдущим симптомом работа такого агента превратится в бесконтрольную поставку кода (и не факт, что его будут ревьюить). Semgrep, кстати, такие штуки ловит хорошо, но по умолчанию они почти всегда включены.

Какие возникают риски?

Если сопоставить эти «симптомы» с OWASP LLM Top 10, то каждому симптому найдется своя пара:

• LLM01 «prompt injection»: через промт‑инъекцию можно заставить ИИ‑агента выполнить shell/bash, например, тот же reverse shell

• LLM02 «insecure output handling»: результат работы модели без проверки может привести к выполнению небезопасных команд shell/bash, git

• LLM07 «insecure plugin/tool design»: MCP‑tools с слишком широкими правами

При низком уровне технического контроля и высоком уровне доверия ИИ‑агенту резко растёт вероятность реализации недопустимых событий: исполнение произвольных команд в shell (включая классический reverse shell), развёртывание криптомайнеров, считывание и выгрузка чувствительных файлов (SSH‑ключи, токены), незаметная модификация кода и конфигов с backdoor’ами, обход ограничений sandbox за счёт небезопасных mounts и docker.sock, боковое движение по инфраструктуре через git, CI/CD и внутренние API, а также утечки секретов через логи, analytics и внешние интеграции.

Безопасность ИИ‑агентов от разработчиков

Некоторые добросовестные разработчики закладывают следующее:

• Sandbox по умолчанию. Например, тот же VibeKit вводят локальную Docker/Podman‑песочницу, через которую ведется работа с ИИ‑агентом: workspace ограничивается одним каталогом, сеть можно рубить, права контейнера ужесточать (спойлер, за день тестирования я пока так и не вышел из песочницы, удалось пока что максимум «уговорить» модель сходить за пределы /workspace)

• Secrets management и redaction. Отдельные модули для хранения секретов

• Observability с акцентом на безопасность. Логи, дашборды и analytics, заточенные не только под то, что сделал агент, но и куда он полез, с какими файлами работал, какие tools использовал

• Документация по безопасной эксплуатации. Всё чаще появляется раздел «Security», в котором авторы честно говорят: запускайте нас в отдельных профилях, включайте sandbox, ограничивайте сеть, не давайте прямой доступ к прод‑секретам.

Но на этом фоне у многих компаний остаётся боль: каждый новый агент надо разбирать почти с нуля и не все (в том числе и я) доверяют дефолтным песочницам.

Системный подход: убрать слово «ИИ»

Если убрать слово «ИИ», все становится проще: перед нами просто сервис (на самом деле blackbox) с максимально широкими правами, который может читать и редактировать файлы, выполнять команды операционной системы, выполнять сетевые запросы, пушить код в git. NanoClaw, например, также заявляет, что их агент может самостоятельно переписывать /app/src/ (но руки проверить пока не дошли)

И дальше логика в разрезе безопасности становится проще: любую такую систему нужно оценивать через классические домены:

• Идентификация, аутентификация и авторизация. Аутентифицировать актора (не важно, человек это или сервис), логировать факт входа, сохранять один к одному доступ актора/юзера/сервиса через агента с его доступами в целевой системе

• Авторизация и минимальные привилегии ИИ‑агентов. Определить скоуп, что агент может делать: видеть только один репозиторий или монорепо? Иметь read‑only или право на запись? Запускать только тесты или ещё и миграции? Каждый ответ — это правило в policy

• Изоляция: где именно крутится агент: в контейнере, на dev‑машине, в CI runner«е? Какие директории смонтированы, есть ли доступ к docker.sock, Kubernetes API?»

• Сетевой контроль. Может ли агент вызывать внешние API? Только внутренние? Через прокси с фильтрацией доменов? Как отслеживаются попытки обратиться к адресам не из white‑list?

• Логирование и мониторинг. Что пишется в логи и как долго они хранятся?

По сути, нужен не какой‑то новый хитровыдуманный фреймворк безопасности, а классический подход с пониманием, что из себя представляет LLM и ИИ‑агент под капотом:

1. Статический анализ кода и конфигов (Semgrep/grep‑профиль под OWASP + LLM Top 10)

2. Динамические тесты в лаборатории с honeypot‑файлами и включённой песочницей

3. Чёткие правила authz: какие директории, какие tools и какие сети доступны

4. Обязательный audit и алерты на нетипичные действия агента

Как бы больно ни было — не тормозите разработку

История циклична: сначала появляется удобный инструмент для разработчиков, потом приходит безопасность и говорит «подождите, так нельзя». С ИИ‑агентами это особенно заметно: люди видят, как можно «сэкономить два дня на миграциях» или «дать ИИ самому чинить мелкие баги», и логично, что такой инструмент хотят внедрить повсеместно (а сколько он денег потенциально экономит).

Главная задача безопасности — не тормозить это движение, а помочь сделать его управляемым.

1. Вместе с командами разработки исследовать стэк ИИ‑агентов, декомпозировать на слои: модель, агент/обвязка, tools, sandbox, etc.

2. Выявить общие черты тестируемых инструментов и разработать понятный профиль безопасности, который урежет «лишние» права, и не сильно сузят функциональность. Для тех же агентов определить: какие права им нужны, какие mounts недопустимы, какие сети разрешены, что логируем.

3. Тестировать гипотезы в изолированной лаборатории с honeypot‑файлами и фейковыми секретами: сначала убедиться, что по умолчанию агент не видит и не делает ничего лишнего, а уже потом пускать его к реальным репозиториям.

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