Нейросеть для написания кода в команде: где возникают риски утечки

Нейросети для кода уже стали частью реальной разработки, но во многих компаниях используются без понятных правил. При этом корпоративные правила часто отстают от реальной практики. Вместе с запросами во внешние сервисы могут попадать фрагменты закрытого кода, логи, ключи доступа, данные клиентов и архитектурная информация. С распространением ИИ-агентов, получающих доступ к репозиториям и другим внутренним системам, эти риски возрастают. Поэтому компаниям важно не запрещать ИИ, а контролировать сценарии его использования, доступы и передаваемые данные.

Риск определяется доступами агента

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

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

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

Любую информацию, переданную внешнему ИИ-сервису или доступную агенту, следует рассматривать как потенциально доступную третьим лицам. Особенно это касается паролей, токенов, ключей доступа, персональных данных, закрытого кода, логов, конфигурационных файлов и сведений об инфраструктуре. Даже небольшой фрагмент может раскрыть адреса внутренних систем, идентификаторы клиентов, секреты или важную часть бизнес-логики.

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

Не запрещать, а управлять

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

При использовании внешнего ИИ часть контроля над информацией переходит поставщику: компания зависит от его инфраструктуры, правил хранения данных, доступности сервиса и условий работы.

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

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

При этом полный запрет на ИИ только усилит риски. Разработчики уже используют такие инструменты для рутинных задач, анализа кода и поиска ошибок. Если компания не предложит удобную разрешенную альтернативу, часть сотрудников продолжит работать через личные аккаунты и публичные сервисы. Так возникает Shadow AI: ИТ- и ИБ-подразделения не знают, какие инструменты применяются, какие данные им передаются и где они хранятся.

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

Однако перевести использование ИИ в контролируемый контур значит не только выбрать разрешенные сервисы и установить правила. Необходимо также ограничить возможности самих агентов на уровне инфраструктуры.

Защита должна начинаться с архитектуры

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

Риск утечек снижают DLP-системы, secret scanning, прокси, аудит, ограничения на IDE-плагины, песочницы и ИИ-файрволы. Но ни одно из этих решений не обеспечивает полной защиты само по себе. Secret scanning обнаружит ключ в коде, но не остановит передачу архитектурной информации. DLP заблокирует известные категории данных, но может не распознать фрагмент бизнес-логики. ИИ-файрвол отфильтрует часть опасных запросов, но не компенсирует избыточные права агента.

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

Поэтому защита должна быть многоуровневой и начинаться с архитектуры. Агентам нужны отдельные учетные записи, минимальные привилегии и изолированная среда. Следует контролировать подключаемые инструменты, MCP-серверы и трафик, ограничивать контекст необходимыми файлами, блокировать доступ к секретам и заменять постоянные права временными.

Критические операции должны требовать подтверждения человека. Агент может подготовить изменение, но не должен самостоятельно выполнять команды в промышленной среде или разворачивать код без дополнительной проверки.

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

Как изменится проверка кода

ИИ ускоряет написание кода, но не его проверку. Ревью перемещается на и так перегруженные элементы системы: синьоров и лидов, которых заваливает лавина кода от джунов, мидлов и LLM одновременно.

Если говорить прямо: человек проиграет машине в гонке ревью по объёму. Уже появляются альтернативы GitHub, изначально спроектированные под порядки возросший поток кода от ИИ-агентов, которые пушат его круглосуточно. Фронтирный ИИ — например, системы уровня Fable или GPT-5.6 — уже работает с кодом как минимум не хуже людей. Поэтому логика одна: переложить основное первичное ревью на автоматизированные системы, а человека оставить только в критически важных точках — архитектурные решения, механизмы авторизации, обработка чувствительных данных, ключевая бизнес-логика, изменения в продакшн-инфраструктуре.

Роль разработчика не исчезает — она смещается: меньше кодинга, больше постановки задач и контроля результатов. Но это «контроль» другого уровня — не каждой строки, а решений с потенциально высокими последствиями.

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

Как выстроить управление ИИ в разработке

Использование ИИ находится на стыке компетенций — и не попадает целиком ни в одну из них. ИТ, скорее всего, неплохо разберётся, как использовать ИИ для разработки, но вряд ли задумается о безопасности. ИБ придётся ещё разобраться с тем, как вообще работает ИИ, чтобы меры безопасности не убили продуктивность. DevSecOps знает, как сделать разработку безопасной, но вряд ли сходу настроит ИИ-агентов. Нас ждут интересную пару лет, в которые из первичного бульона проб и ошибок выкристаллизуются Best Practices. Возможно, это будет MLSecOps — а может и нет. Поживём-увидим. Пока же правила должны формироваться совместно, но для каждого процесса нужен конкретный владелец: кто утверждает инструменты, выдаёт права агентам, контролирует их действия и допускает изменения в продакшн.

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

Затем необходимо оценить риски каждого сценария и понять реальные потребности разработчиков — и исходя из этого, как перенаправить их из Shadow AI в рамки безопасного использования ИИ. Иначе правила окажутся либо слишком общими, либо настолько строгими, что сотрудники продолжат обходить их.

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

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

И напоследок — вопрос, который помогает расставить приоритеты лучше любого фреймворка: что бы вы сами искали у конкурента в его переписке с ИИ или в логах его агентов, если бы могли их увидеть? Ответ на него покажет, что защищать в первую очередь.

Автор- Александр Лебедев, старший ML-разработчик продукта Innostage AIDR.