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

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

Крупные отчёты NIST, ENISA и других регуляторов фиксируют: генеративный ИИ уже используется в разработке, тестировании и эксплуатации систем. Его применяют в DevSecOps — от code review до генерации инфраструктурного кода и управления конфигурациями.

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

Каждый такой инструмент — не просто «ещё одна модель», а новый элемент инфраструктуры. Вместе они формируют новый ландшафт угроз, который не покрывается классическим OWASP Top 10.

Дополнение — OWASP Top 10 for LLM Applications — выделяет риски, ранее не характерные для веб-приложений: prompt injection, небезопасная обработка вывода модели, чрезмерные полномочия агента, утечки секретов через контекст и другие.

Многие команды безопасности сегодня работают в режиме: «появился новый агент — срочно разбираем его код». Такой подход не масштабируется и не успевает за развитием технологий. Нужно переходить к системному подходу, применимому ко всем ИИ-агентам.

Основные термины в новой ИИ-реальности

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

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

• анализ и генерация кода
• принятие решений по типу «какой следующий шаг»
• формирование запросов к инструментам (shell, git и др.) через прослойку

Типичные права моделей:

• доступ к исходникам (read, реже write)
• доступ к конфигам и логам
• доступ к секретам через переменные окружения

Ключевые риски:

• prompt injection — модель можно «переубедить» выполнить нежелательное действие
• небезопасная обработка вывода — текст модели без фильтрации может попасть в shell, SQL или CI
• утечки данных — модель может раскрыть секреты или слить конфиденциальные данные

MCP (Model Context Protocol) — протокол, стандартизирующий подключение внешних инструментов к модели. Он описывает:

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

Функции MCP:

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

Права MCP:

• доступ к файловой системе
• доступ к git
• доступ к сетевым сервисам
• редко — доступ к конфигам

Риски MCP:

• небезопасный дизайн tools (слишком широкие полномочия)
• отсутствие scoping (один сервер видит несколько репозиториев)
• отсутствие явной политики использования tools

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

Функции ИИ-агентов:

• автоматизация рутинных задач разработчиков и DevOps
• полуавтоматический рефакторинг и code review
• работа с баг-репортами и тикетами
• автономное выполнение сценариев

Права ИИ-агентов:

• read/write в репозиториях и директориях
• вызов shell-команд, доступ к git и тестовым раннерам
• доступ к облачным sandbox'ам

Риски:

• чрезмерная агентность (агент получает root-доступ)
• инъекции (командная, файловая, конфигурационная) в LLM-контексте
• утечки секретов при логировании, аналитике, prompt-инжекции

Sandboxes — контейнерные песочницы, ограничивающие права и scope ИИ-агентов.

Исследование ИИ-агентов: что показал исходный код

ИИ-агенты следует рассматривать как обычное ПО. Для анализа я использовал semgrep для open-source решений и grep для проприетарных, фокусируясь на паттернах из OWASP Top 10 и LLM Top 10.

Анализировал несколько агентов (Nymbalist, Serena, NanoClaw, GoClaw, VibeKit), которые работают как «обвязка» вокруг LLM. Подход:

• статический анализ по правилам OWASP и LLM Top 10
• ручной разбор реализации sandbox, работы с секретами, мостов между LLM и инструментами
• динамические тесты в лаборатории с honeypot-файлами

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

Картина однотипная:

• Bash / shell-доступ — все агенты могут вызывать shell через spawn/exec, docker exec, SSH и т.п.
• Доступ к git с широкими правами — создание веток, коммитов, pull-requests. MCP-инструменты могут вызывать git напрямую.
• Флаги bypassPermissions — режимы вроде allowDangerouslySkipPermissions: true, дающие агенту root-доступ без ограничений. При включении по умолчанию это создаёт высокий риск бесконтрольной поставки кода.

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

Сопоставление симптомов с OWASP LLM Top 10:

• LLM01 (prompt injection) — через инъекцию можно заставить агента выполнить reverse shell
• LLM02 (insecure output handling) — вывод модели без проверки приводит к выполнению опасных команд
• LLM07 (insecure plugin/tool design) — MCP-инструменты с избыточными правами

При слабом контроле и высоком доверии возможны:

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

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

Некоторые разработчики внедряют меры безопасности:

• Sandbox по умолчанию — например, VibeKit использует Docker/Podman-песочницу с ограниченным workspace, управляемой сетью и ужесточёнными правами
• Управление секретами — отдельные модули для хранения и маскировки секретов
• Наблюдаемость с фокусом на безопасность — логи и дашборды, показывающие, с какими файлами и tools работал агент
• Документация по безопасной эксплуатации — рекомендации по запуску в изолированных профилях, ограничению сети, запрету доступа к прод-секретам

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

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

Если исключить слово «ИИ», картина упрощается: перед нами просто сервис (blackbox) с широкими правами — чтение/запись файлов, выполнение команд ОС, сетевые запросы, push в git.

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

• Идентификация, аутентификация, авторизация — актор (человек или сервис) должен быть аутентифицирован, его действия — залогированы, доступы — сопоставлены с правами в целевой системе
• Минимальные привилегии — чётко определить scope: один репозиторий или монорепо? read-only или запись? только тесты или миграции? Каждый ответ — правило в policy
• Изоляция — где работает агент: в контейнере, на dev-машине, в CI runner? Какие директории смонтированы? Есть ли доступ к docker.sock или Kubernetes API?
• Сетевой контроль — может ли агент вызывать внешние API? Только через прокси? Как отслеживаются обращения к доменам не из white-list?
• Логирование и мониторинг — что пишется в логи и как долго хранится?

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

1. Статический анализ кода и конфигов (профиль под OWASP + LLM Top 10)
2. Динамические тесты в лаборатории с honeypot-файлами и включённой песочницей
3. Чёткие правила авторизации: какие директории, tools и сети доступны
4. Обязательный аудит и алерты на нетипичные действия

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

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

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

1. Вместе с разработчиками исследовать стек ИИ-агентов, декомпозировать на слои: модель, обвязка, tools, sandbox и т.д.
2. Выявить общие черты и разработать единый профиль безопасности, который урезает лишние права, но сохраняет функциональность. Определить: какие права нужны, какие mounts недопустимы, какие сети разрешены, что логируется.
3. Тестировать гипотезы в изолированной лаборатории с honeypot-файлами и фейковыми секретами. Сначала убедиться, что агент ничего лишнего не видит и не делает, только потом пускать к реальным репозиториям.

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

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

За последние два‑три года компании в РФ перестали относиться к ИИ как к «чудо машине» и начали встраивать его в рабочие процессы: от помощи специалистам контакт‑центров в чатах с клиентами и «серым» помощникам разработчиков до написания полноценных продуктов. Если раньше нельзя было сказать, что ты использовал ИИ для задачи, так как тебя закидают помидорами, сегодня — этот навык 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 (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‑файлами и фейковыми секретами: сначала убедиться, что по умолчанию агент не видит и не делает ничего лишнего, а уже потом пускать его к реальным репозиториям.

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