Что происходит на рынке
За последние два‑три года компании в РФ перестали относиться к ИИ как к «чудо машине» и начали встраивать его в рабочие процессы: от помощи специалистам контакт‑центров в чатах с клиентами и «серым» помощникам разработчиков до написания полноценных продуктов. Если раньше нельзя было сказать, что ты использовал ИИ для задачи, так как тебя закидают помидорами, сегодня — этот навык 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 и ИИ‑агент под капотом:
Статический анализ кода и конфигов (Semgrep/grep‑профиль под OWASP + LLM Top 10)
Динамические тесты в лаборатории с honeypot‑файлами и включённой песочницей
Чёткие правила authz: какие директории, какие tools и какие сети доступны
Обязательный audit и алерты на нетипичные действия агента
Как бы больно ни было — не тормозите разработку
История циклична: сначала появляется удобный инструмент для разработчиков, потом приходит безопасность и говорит «подождите, так нельзя». С ИИ‑агентами это особенно заметно: люди видят, как можно «сэкономить два дня на миграциях» или «дать ИИ самому чинить мелкие баги», и логично, что такой инструмент хотят внедрить повсеместно (а сколько он денег потенциально экономит).
Главная задача безопасности — не тормозить это движение, а помочь сделать его управляемым.
Вместе с командами разработки исследовать стэк ИИ‑агентов, декомпозировать на слои: модель, агент/обвязка, tools, sandbox, etc.
Выявить общие черты тестируемых инструментов и разработать понятный профиль безопасности, который урежет «лишние» права, и не сильно сузят функциональность. Для тех же агентов определить: какие права им нужны, какие mounts недопустимы, какие сети разрешены, что логируем.
Тестировать гипотезы в изолированной лаборатории с honeypot‑файлами и фейковыми секретами: сначала убедиться, что по умолчанию агент не видит и не делает ничего лишнего, а уже потом пускать его к реальным репозиториям.
Если подойти к этой задаче системно, то каждый новый агент не будет отнимать дни на анализ и копирование предыдущих требований ИБ. Внедрение станет более быстрым, коммуникации сократятся, исключения — как всегда согласуются :-)