Сгенерированный код: лицензии, уязвимости, ответственность

Для клиента не существует «кода, который написал агент». Есть код, который сдало агентство, — с гарантийными обязательствами, требованиями к безопасности и правами на результат по договору. Агент меняет не ответственность, а скорость, с которой можно накопить проблему. В уроке — три группы рисков сгенерированного кода и проверки, которые их закрывают.

Ответственность не делегируется

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

• Человек утверждает каждый merge request. Агент может писать код и делать первичное ревью, но решение о слиянии принимает ответственный разработчик.
• Агент не одобряет собственную работу. Если один агент написал код, его не должен единолично проверять тот же агент.
• Существующие ворота качества остаются. Документация Codex по интеграции с GitLab прямо пишет, что правила для ревьюера направляют Codex, но не заменяют тесты, защиту веток и обязательные одобрения (GitLab).

Почему второе правило важно, видно из данных самой OpenAI. В блоге о проверке кода в масштабе приводятся цифры: ревьюер Codex оставляет замечания на 36% PR, целиком сгенерированных облачным Codex, и 46% этих замечаний приводят к правке; на PR, написанных людьми, правкой заканчиваются 53% замечаний (OpenAI Alignment). Агентский код ошибается достаточно часто, чтобы его проверял кто-то независимый. Там же авторы предупреждают о главном риске — когда чистое ревью начинают считать гарантией безопасности, а не одним из слоёв защиты.

Лицензии: откуда риск

Лицензионный риск у агента приходит по двум каналам.

Зависимости. Агент, решая задачу, может добавить пакет в composer.json или package.json. Пакет может быть под лицензией, несовместимой с условиями передачи прав клиенту, — например, с сильным копилефтом в закрытом коммерческом продукте. Это не специфика ИИ, но агент добавляет зависимости быстрее и с меньшим обсуждением, чем человек.

Содержимое из сети. OpenAI в документации по доступу агента в интернет прямо перечисляет среди рисков загрузку контента с лицензионными ограничениями (internet access). Чем шире сеть у агента, тем выше шанс, что в код попадёт фрагмент из чужого репозитория.

Отдельный вопрос — права на сам результат. По открытым материалам, условия OpenAI для бизнес-клиентов закрепляют права на результат за клиентом, а в Service Terms есть защита от претензий по авторским правам для части корпоративных тарифов с исключениями. Распространяется ли это на Codex в вашем договоре и на каких условиях — мы по первоисточнику не подтвердили. Проверьте актуальные Service Terms и свой договор вместе с юристом. И отдельно — договоры с клиентами: если в них есть гарантия «оригинальности» кода или запрет на использование ИИ-инструментов, это надо знать до начала работы.

Не путайте лицензию инструмента и лицензию результата: Codex CLI распространяется под Apache-2.0 (GitHub), но это лицензия на сам CLI, а не на код, который он пишет.

Уязвимости: что говорят исследования

Отчёт Veracode о безопасности сгенерированного кода (2025) проверил более 100 языковых моделей на задачах на Java, Python, C# и JavaScript (Veracode):

• 45% образцов кода не прошли проверки безопасности и содержали уязвимости из OWASP Top 10;
• у Java доля провалов составила 72%;
• от межсайтового скриптинга (XSS) модели не защитились в 86% релевантных случаев;
• более новые и крупные модели писали функционально лучший код, но не более безопасный.

Это исследование моделей, а не конкретно Codex, и задачи в нём синтетические. Но вывод для процесса однозначный: без автоматических проверок безопасность сгенерированного кода — лотерея. Для веб-агентства XSS — не абстракция: это шаблоны вывода в Twig или Blade, где агент легко отключит экранирование, чтобы «заработало».

Проверки, которые закрывают риски

Встройте в CI то, что не зависит от внимательности ревьюера:

• SAST — статический анализ безопасности на каждый MR.
• SCA и проверка лицензий — новые зависимости сверяются со списком разрешённых лицензий. Для PHP хватает встроенной composer licenses, для JS — сканера лицензий в CI.
• Проверка секретов в диффе — агент мог вписать ключ из примера.
• Правила для ревьюера — раздел ## Code Review Rules в AGENTS.md: например, «любое отключение экранирования в шаблонах — P1». Стиль и форматирование оставьте линтерам, как советует документация.

OpenAI предлагает и отдельные инструменты: Codex Security — продукт для поиска уязвимостей с доказательствами, и команду @codex security review в PR (research preview) (Codex Security). Это дополнительный слой, а не замена SAST и ревью. Пример конвейера с ревью, разбором SAST и патчами для GitLab CI есть в кукбуке OpenAI.

Как ревьюить агентский код руками, разобрано в уроке «Как ревьюить код, написанный агентом»; ворота качества для команды — в уроке «Ворота качества».

Раскрытие использования ИИ

Отмечать ли в коммитах и MR, что код написан с агентом, OpenAI не предписывает — это решение команды. Но клиентский договор может требовать раскрытия или, наоборот, запрещать использование таких инструментов. Зафиксируйте позицию компании письменно и согласуйте с юристом формулировку для договоров на будущее.