DryRun Security: что исследование AI-кода говорит об API-проверках

11 марта 2026 года DryRun Security опубликовала результаты Agentic Coding Security Report. Компания сравнила работу Claude, Codex и Gemini при создании двух приложений через последовательные pull requests. Это ограниченный эксперимент, а не исследование тысяч независимых приложений.

Что обнаружили исследователи

По данным пресс-релиза DryRun, уязвимости появились в 26 из 30 pull requests. Исследователи выделили повторяющиеся проблемы авторизации: работу с JWT, защиту от перебора, повторное использование токенов и настройки cookies обновления сессии. Отдельный пример — проверка доступа, применённая к REST, но пропущенная на WebSocket.

Компания оценивает код собственным инструментом. Результат полезен для выбора проверок, но не доказывает постоянное превосходство одной модели над другой во всех проектах.

Практический набор проверок для API

Сформируйте небольшую матрицу: действующий токен, истёкший токен, неверная подпись, отсутствие токена и запрос к чужому объекту. Выполните её для каждого способа доступа, который использует приложение: HTTP, WebSocket или фоновые задачи. Проверяйте фактический запрет операции, а не только наличие middleware в коде.

Для работы с пользовательскими объектами задайте два тестовых аккаунта. Обращение одного к данным другого должно завершаться ожидаемым отказом. Тестируйте чтение и изменение отдельно: наличие проверки на одном маршруте не подтверждает остальные.

Как включить это в работу агента

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

AI gateway решает задачу доступа к моделям; безопасность приложения не появляется от смены маршрута LLM-запроса. В документации API429 можно проверить контракт интеграции с моделью, а тесты авторизации вашего продукта должны оставаться отдельной частью выпуска.