Евгений Кокуйкин про AI Security - AI Dev Podcast (Рубрика AI4SDLC)
Посмотрел подкаст с AI Dev Conf, в котором участвовали Евгений Кокуйкин, Андрей Дмитриев и я. Мы поговорили о том, что происходит с безопасностью разработки, когда у нас кодяру начинают писать не только люди, но и агенты с разными инструментами, доступами и правами на изменения. Если говорить про гостя, то Евгений Кокуйкин - это CEO HiveTrace, со-основатель Raft, руководитель AI Security Lab в ИТМО и участник OWASP Agentic Security. То есть это точка зрения практика AppSec/AI security, который видит и технологию, и поверхность атаки.
Главная мысль выпуска крутится вокруг того, что в агентной разработке безопасность становится частью архитектуры процесса: кто действует, от чьего имени, какие права получает, что логируется, где нужен approval и как быстро можно откатиться. Наше общение можно разделить на отдельные блоки
1️⃣ Почему coding agents вообще так быстро продвинулись В обычных GenAI-приложениях трудно понять, насколько ответ хорош: пользователь поставил палец вверх или вниз, но это слабая обратная связь. В разработке иначе. У нас уже есть компиляторы, линтеры, тесты, git-история, баг-трекеры, CI/CD и код-ревью. Можно взять старый баг, восстановить состояние репозитория, дать агенту задачу и проверить решение теми же тестами. SDLC уже содержит заготовку для evals. Отсюда растёт автономность. Агент может решить задачу, получить обратную связь от тестов, перезапустить попытку, передать изменения на ревью. Для внешнего клиента режим "попробуйте ещё раз" выглядел бы странно, а внутри разработки retry, тесты и ревью становятся нормальной частью контура.
Но дальше начинается неприятная часть. Если агент становится участником SDLC, его нельзя воспринимать как безобидную подсказку в IDE. Он похож на внутреннего сотрудника или сервисный аккаунт: identity, доступы, токены, возможность читать репозитории, дергать API, смотреть логи, иногда деплоить или помогать с инцидентами. Проблема service accounts и раньше была болезненной, но агентная разработка умножает её на порядок.
Часто разговоры про AI security быстро уезжают в область prompt injection, jailbreaks и красивых атак на модель. Но во многих реальных сценариях ломается более скучный слой: права доступа, секреты, supply chain, разделение dev/stage/prod, аудит действий и зависимости. Евгений приводил примеры из мира coding assistants, MCP-серверов, Postmark, LiteLLM и других supply-chain историй. Паттерн здесь прост: если агент или его инструмент подтянул заражённую зависимость, обычные unit tests могут ничего не заметить.
2️⃣ Экономика и метрики Бизнесу легко пообещать "заменим половину разработки агентами", но реальность сложнее. Нужно считать не только токены и GPU, но и платформу: gateway, routing между моделями, sandboxing, аутентификацию, авторизацию, квоты, наблюдаемость. А бенефит нельзя сводить к количеству AI-кода: интереснее смотреть на конкретные job'ы внутри SDLC - миграции, багфиксы, ревью, тесты, инциденты, повторяемые изменения.
3️⃣ Надёжность Если SRE-агент в 2 часа ночи может собрать анамнез инцидента, это полезно. Если он может сам перезапускать сервисы, менять конфигурацию или выполнять план восстановления, это уже другой класс риска. Если каждое опасное действие агента уезжает на senior approval, узкое место просто переехало к самым загруженным людям. Значит, нужны более тонкие политики риска: что агент может делать сам, где нужен второй контур проверки, где требуется изоляция среды, а где действие запрещено всегда.
4️⃣ Ответственность Мы обсуждали агента почти как классическую пару принципала и агента (из теории управления): человек или компания задаёт цель, агент действует от их имени, а дальше появляются misalignment, побочные действия и вопрос "кто отвечает?". Эта логика из менеджмента теперь просачивается в технический контур одного инженера и его агентов.
Для инженеров главный вывод такой: AI security в SDLC - это не отдельная "галочка ИБ", а проектирование производственной системы. Нужны evals, threat modeling, least privilege, sandboxing, разделение сред, audit trail, model routing, контроль секретов, политика для non-human identities и наблюдаемость агентных действий.
И ещё более практично: если в компании появляются кодинговые агенты, то не стоит начинать с вопроса "какую модель выбрать", а с карты прав и последствий. Что агент читает? Что пишет? Какие инструменты вызывает? Может ли он достать данные? Может ли деплоить? Кто увидит его действия? Как остановить, откатить и расследовать результат? Без этих вопросов "ускорение разработки" очень легко превращается в ускорение риска.
#AI #AI4SDLC #Security #Engineering #Architecture #DevSecOps #Agents