Governance и безопасность
Безопасность кода, сгенерированного ИИ: контроль в команде и заказчике
1. Использование ИИ на работе: где прячется главный риск
Код, который написал ИИ, выглядит как обычный код. Он так же компилируется, так же проходит сборку, так же звучит уверенно. Именно поэтому его и опасно пускать в работу без контроля — визуально нет никакой разницы между «человек написал» и «агент сгенерировал».
Безопасность кода, сгенерированного ИИ, — не про «ИИ опасный», а про то, что в этой среде добавляются три новых источника риска, которых не было при написании кода инженером.
Утечка данных в промпте. Когда разработчик вставляет фрагмент в ассистента или агент тянет контекст, в запрос попадает то, что туда не должно попадать. Персональные данные, ключи, внутренняя логика, фрагменты чужого кода. Сама канальная утечка — это обещание «удобства», а соблюдение 152-ФЗ и защита конфиденциальных сведений требуют обратного.
Галлюцинация с уверенным лицом. Модель может сгенерировать интерпретируемую, но неверную или небезопасную реализацию — например, функцию с отсутствующей валидацией ввода или SQL без параметризации. На первый взгляд код решает задачу; проблема вылезает под нагрузкой или при первой атаке.
Уязвимость и «мусорная» зависимость. ИИ-агент охотно подтягивает библиотеки, выбранные «по вкусу». Так в проект попадают малоизвестные пакеты с непроверенной репутацией, которые тянут за собой цепочку зависимостей. Это классический вектор для коммерчески и защищённо — заказчик в итоге наследует бэкдор, о существовании которого не знает.
Вывод простой: использование ИИ на работе — это инструмент, а не развлечение. Инструмент эффективен, пока у него есть тормоза.
2. Типовые угрозы и как они проявляются
Сведём риски в таблицу — наглядно, чтобы при разборе команда опиралась на примеры.
| Риск | Как проявляется | Чем грозит |
|---|---|---|
| Утечка данных в промпт | ключи, персональные данные, фрагменты чужого кода уходят во внешний сервис | нарушение 152-ФЗ, репутация, штрафы |
| Некорректное решение | правдоподобный, но неверный алгоритм | ошибки в продакшене, переделка |
| Ошибка валидации | нет проверки ввода, прямой SQL, игнор лимитов | SQL-инъекции, OWASP-класс уязвимостей |
| «Мусорные» зависимости | случайные библиотеки с неясной репутацией | цепочка уязвимостей, бэкдор |
| Неуправляемые права | агент работает под общими правами или с избыточным доступом | полный доступ к данным и системам |
| Отсутствие следа | никто не записал, что и кто сгенерировал | невозможность разобрать инцидент |
Каждая строка — это не теоретическая угроза, а типовой сценарий, который всплывает в первых же неделях активного использования агентов.
3. Правила и меры защиты: что внедрить в команде
Защита строится на трёх уровнях, и все три нужны вместе.
Первый уровень — границы данных. Разрешаем агенту то, что безопасно, и запрещаем то, что уходит за пределы контура. Никакой «общей» учётки: на каждую сессию — изолированный доступ, минимально необходимые права. Если решение про данные — только в частном контуре, без выгрузки во внешние сервисы. Детально про соответствие и политики доступов — в материале об управлении ИИ-агентами.
Второй уровень — контроль результата. Каждый сгенерированный фрагмент проходит ревью человеком. Это обязательное правило, а не «желательная» практика. По сути это про «human in the loop» — порог, после которого агент не имеет права самостоятельно довести изменение до продакшена. Для критичных задач — двойная проверка: техлид смотрит логику, ИБ — на предмет уязвимостей. База по тому, как это работает в реальном потоке, — в разборе vibe coding.
Третий уровень — автоматизация проверок. Ревью человеком не заменяет сканирование, оно его дополняет. В пайплайн встраиваем линтеры, анализаторы уязвимостей (SAST), проверку зависимостей, секреты-сканеры, обязательные автотесты. Так «уверенный» код фильтруется ещё до того, как дойдёт до человека.
Отдельно стоит правило про зависимости: агенту нельзя полагаться на «первое попавшееся». Пакеты проходят проверку репутации и версии, и состав фиксируется — так снижается риск бэкдора через непроверенную библиотеку.
4. Как встроить защиту в процесс разработки
Этапы такие.
- Зафиксируйте границы — что агент может и не может (доступы, данные, действия). Это база, без неё безопасность не работает.
- Настройте раздельные права — изолированный доступ, отсутствие общих учёток, минимальные привилегии.
- Обязательное ревью — закрепите правило: сгенерированный код не идёт в основную ветку без проверки человеком.
- Автотесты и сканеры — подключите SAST, проверку зависимостей, линтеры, секреты-сканеры и автотесты.
- Логируйте и разбирайте — фиксируйте, что и кто сгенерировал; ведите историю инцидентов для пересмотра политики.
- Проводите регулярный аудит — сверяйте практику с политикой на регулярной основе, а не после первого происшествия.
Если команда уже использует агентов, безопаснее всего пройти эти шаги в «догонку», чем ждать полноценного регламента. Полчаса на настройку прав и ревью дают больше, чем месяцы ожидания идеального положения.
5. Вопросы и ответы
Правда ли, что код от ИИ хуже по безопасности? — Не сам по себе, но у него выше доля пограничных случаев: модель склонна выбирать «удобную» реализацию, а не «безопасную». Контроль и верификация снимает эту разницу.
Как защитить персональные данные, если ИИ работает с документами? — Запретить выгрузку чувствительных данных во внешние сервисы, размещать решение в частном контуре, использовать изолированные доступы и логировать действия.
Нужен ли секрет-сканер, если у команды есть ревью? — Да. Ревью человеком не ловит всё: скан ищет секреты, уязвимости и зависимости автоматически и системно, а человек вносит инженерную оценку.
Что делать, если зависимость «мусорная»? — Запретить прямые добавления без проверки, подключать проверенные и обновляемые пакеты, фиксировать состав в файле зависимостей.
Зачем логировать, если всё и так под контролем? — Для разбора инцидента и для аудита. Без следа невозможно понять, что и кто изменил и на каком этапе ушло.
Это обязательно только для крупных компаний? — Нет. Правило о запрете утечки данных и обязательном ревью стоит малому бизнесу так же, как большому; просто объём формальностей меньше.
Частые вопросы
Правда ли, что код от ИИ хуже по безопасности?
Не сам по себе, но у него выше доля пограничных случаев: модель склонна выбирать «удобную» реализацию, а не «безопасную». Контроль и верификация снимает эту разницу.
Как защитить персональные данные, если ИИ работает с документами?
Запретить выгрузку чувствительных данных во внешние сервисы, размещать решение в частном контуре, использовать изолированные доступы и логировать действия.
Нужен ли секрет-сканер, если у команды есть ревью?
Да. Ревью человеком не ловит всё: скан ищет секреты, уязвимости и зависимости автоматически и системно, а человек вносит инженерную оценку.
Что делать, если зависимость «мусорная»?
Запретить прямые добавления без проверки, подключать проверенные и обновляемые пакеты, фиксировать состав в файле зависимостей.
Зачем логировать, если всё и так под контролем?
Для разбора инцидента и для аудита. Без следа невозможно понять, что и кто изменил и на каком этапе ушло.
Это обязательно только для крупных компаний?
Нет. Правило о запрете утечки данных и обязательном ревью стоит малому бизнесу так же, как большому; просто объём формальностей меньше.