OWASP SAMM получил расширение Agentic SAMM для безопасной разработки с AI-агентами

Вокруг OWASP SAMM появился новый draft-проект Agentic SAMM, или ASAMM, — расширение для команд, которые строят продукты с AI-агентами и используют модели в разработке. Его цель — закрыть риски, которые классический secure SDLC видит плохо: вредоносный контекст, опасные вызовы инструментов и слишком длинные окна автономии.

Почему старого SAMM мало

Классический OWASP SAMM хорошо работает там, где главные объекты защиты — код, сборка, релиз и инфраструктура поставки. Но в агентных системах поверхность атаки уходит дальше: в документы, задачи в трекере, описания инструментов, результаты веб-поиска, CI-логи и любой другой контент, который модель читает как часть рабочего контекста. Если этот контекст влияет на поведение агента, то он уже становится частью control plane, а не просто входными данными.

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

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

Что предлагает ASAMM ASAMM задуман не как замена OWASP SAMM, а как

надстройка для команд, которые внедряют AI-агентов, MCP-серверы и автоматизацию с делегированными полномочиями. Фреймворк добавляет отдельный слой гарантий там, где заканчиваются привычные проверки кода: на границе вызовов инструментов, в потоке контекста, в approval checkpoints и в поведении системы во время исполнения. Он не отменяет базовые практики SAMM, а расширяет их на runtime-поведение и делегированные действия.

• Таксономию угроз для агентных систем, где контекст рассматривается как потенциальная команда Двухосевую модель доверия для агентов, инструментов, MCP-серверов и источников контекста Набор контролей по пяти функциям SAMM с уровнями зрелости и сценариями внедрения Два маршрута запуска: миграция с существующей security-программы или развёртывание с нуля Маппинг на NIST AI RMF и рекомендации NCSC для команд, которым нужна совместимость с уже знакомыми рамками Отдельный акцент сделан на среде разработки. IDE-плагины, pre-commit хуки, CI-агенты и внешние MCP-коннекторы работают с привилегиями разработчика, но часто живут вне полноценной threat model. Для ASAMM это не побочный элемент, а полноценная цель для анализа: если агент может читать, вызывать и изменять больше, чем команда реально отслеживает, зелёные статусы в дашбордах перестают что-либо гарантировать. Фактически разработческая среда становится продакшеном для самого агента.

Где команды уже ошибаются В материале перечислены типовые промахи,

которые особенно заметны в агентной разработке. Команда может считать threat model завершённой, хотя в ней вообще нет источников контекста и путей вызова инструментов. Code review может покрывать весь код в PR, но не затрагивать системные промпты, схемы tool calls и конфиги агентов. DAST может показывать чистый результат, хотя никто не проверял, как агент ведёт себя при враждебном контексте. А least privilege нередко реализуют только на уровне сервисных аккаунтов, не ограничивая сами действия, которые разрешены через инструменты.

«Ни один план не переживает первого контакта».

Эту мысль автор использует как принцип проектирования: системный промпт должен задавать намерение, а не пытаться жёстко расписать весь алгоритм поведения. Отсюда и ещё один важный параметр риска — произведение окна автономии на blast radius доступных инструментов. Чем дольше агент действует без человеческой контрольной точки и чем шире набор его возможностей, тем выше потенциальный ущерб даже при формально корректных правах доступа. Именно поэтому окна автономии здесь становятся архитектурным, а не только операционным параметром.

Что это значит

Agentic SAMM фиксирует сдвиг, который уже произошёл в AI-разработке: безопасность теперь проверяет не только код, но и поведение системы после релиза. Для команд, которые строят продукты поверх агентов и vibe coding, это сигнал пересматривать threat model, code review и контроль инструментов до того, как первая автономная ошибка превратится в полноценный инцидент.