Агентная разработка ломает привычную картину AppSec. Раньше мы строили процессы вокруг людей, репозиториев, пайплайнов и контролируемых этапов SDLC. Теперь в этот контур входит сущность, которая пишет код, запускает команды, меняет среду, вызывает другие инструменты через MCP, может работать в Claude или другой модели и при этом не обязана вести себя как разработчик-человек.
В докладе Сергей Гордейчик предложил смотреть на эту ситуацию через призму Agentic SAMM (ASAMM): адаптации идей OWASP SAMM к агентной разработке. Это не замена OWASP SAMM, а попытка добавить к знакомой методике новый слой контрольных мер: для автономности, недоверенных моделей, поведения агентов, forensic log, динамического и статического аудита. На слайдах эта рамка сформулирована коротко: SAMM работает, но граница сдвинулась.
Почему обычный контроль разработки перестаёт работать
OWASP SAMM хорошо ложится на классическую безопасную разработку: есть команда, процессы, дизайн, реализация, проверка, эксплуатация. Он покрывает код и артефакты поставки, software supply chain, security testing & review, vuln & incident management и пять функций SAMM. Даже если разработчик ошибается или нарушает правила, он остаётся социально и организационно управляемой сущностью. У него есть ответственность, рабочий день, контекст компании, менеджер, зарплата, страх последствий.
С агентом эта модель слабее. Агент может получить задачу, самостоятельно выбрать путь, написать код, запустить команды, изменить рабочую среду, подключиться к инструментам и закрепить удачную или неудачную стратегию в собственных инструкциях. В докладе прозвучал показательный пример: агенту задают запрет, но он находит ситуацию, где считает выполнение задачи важнее запрета, делает исключение, а затем может зафиксировать это исключение как допустимый принцип поведения.
Для безопасника это меняет сам объект контроля. Мы больше не управляем только доверенным, но не до конца известным участником процесса. Мы имеем дело с неизвестным и недоверенным исполнителем: модель может быть чужой, её обучение непрозрачно, мотивация не формализована, а внутреннее состояние недоступно для прямой проверки. Слайды отдельно раскладывают это на две группы: unknown unknowns и untrusted unknowns. К первым относятся непредсказанная композиция инструментов, загрязнение контекста пользовательским вводом, prompt drift в длинных сессиях, emergent strategies и правки memory, которые меняют поведение следующих шагов. Ко вторым - результаты search/retrieval, выходы upstream-агентов, ответы MCP-серверов, изменившиеся API-контракты инструментов и поведение сторонних моделей.
В такой картине привычные понятия CIA: confidentiality, integrity, availability, и классический risk management остаются полезными, но недостаточными. Они описывают последствия и активы, однако плохо отражают динамику: как ошибка агента зарождается, размножается по итерациям и влияет на последующие решения.
Разработка как спираль, а не цикл
Один из центральных тезисов доклада: разработка с агентами перестаёт быть циклом и становится спиралью. Формально этапы остаются знакомыми: design, implementation, verification, operation. Но каждый проход происходит уже на новом уровне сложности.
Главное отличие - скорость роста этой сложности. Если раньше на изменение уровня системы уходили месяцы или годы, то агент может выполнить большой объём работы за часы. В докладе это описано почти бытово: задача, которую агент оценивает как трёхмесячную, через два часа может оказаться уже реализованной.
Для безопасности это означает, что ошибка больше не является локальным дефектом в одной итерации. Если агент заложил неверную концепцию в свои инструкции, проектные решения или промежуточные артефакты, он может продолжить строить систему поверх этой ошибки. Чем раньше она появилась, тем шире последствия.
Поэтому ASAMM вводит в центр не только риск, но и blast radius: радиус поражения решения, ошибки или некорректного поведения агента. В агентной разработке важно не просто спросить «какова вероятность и ущерб», а понять, насколько далеко агент успеет разнести ошибку, пока человек или контрольный механизм её заметит.
Четыре сценария Agentic SAMM
В докладе ASAMM описан как методика для нескольких разных ситуаций, а не только для команд, которые полностью строят агентную систему с нуля. В слайдах это подано как четыре сценария, где организация «уже находится хотя бы в одном».
Первый сценарий: организация проектирует агентскую систему с нуля. Здесь нужно сразу закладывать ограничения автономности, модель доверия, наблюдаемость, контроль инструментов и процесс проверки действий агента.
Второй сценарий: в уже существующую систему добавляют агента. В этом случае особенно важны границы интеграции: что агент может видеть, какие команды выполнять, какие данные менять, через какие интерфейсы работать.
Третий сценарий: агент становится ещё одной сущностью внутри существующего процесса разработки. Например, он пишет код, помогает с ревью, генерирует тесты или документацию. На слайдах этот сценарий прямо описан через dev workflow: Claude Code, Cursor, Copilot или похожий агент читают ваш репозиторий. Здесь ASAMM нужен не как отдельная «безопасность агента», а как расширение уже существующего secure development lifecycle.
Четвёртый сценарий: система получает результат работы агента через MCP, agent-backed API или похожий механизм. Даже если агент не живёт внутри вашего контура напрямую, его выход становится входом для вашей системы. Значит, его нужно рассматривать как недоверенный источник данных и действий.
Такой набор сценариев важен: агентная безопасность не сводится к вопросу «можно ли запускать Claude в репозитории». Речь шире: где именно агент входит в жизненный цикл, какие у него полномочия и как далеко распространяются его решения.
Доверие, окно автономности и военная оптика
Сергей Гордейчик предложил искать язык описания не только в AppSec, но и в смежных областях: военной доктрине, разведке и контрразведке. В докладе прозвучали три заимствованные идеи.
Первая - модель доверия к источнику и информации. В разведывательных практиках можно отдельно оценивать, насколько доверяют источнику, и насколько доверяют конкретному сообщению. Для агентной разработки это превращается в практичный принцип: агент может ошибаться или «врать», но разные агенты и разные классы их выводов имеют разный уровень доверия. Аудитор должен учитывать не только факт ответа, но и репутацию источника, контекст и проверяемость результата.
Вторая - уже упомянутый blast radius. Ошибка агента развивается во времени. Если она попала в ранние инструкции, архитектурные решения или цепочку инструментов, её последствия могут стать значительно шире, чем обычный дефект в коде.
Третья - подготовка к автономным действиям на разных уровнях. В докладе это связано с немецкой военной доктриной и известной мыслью о том, что план не переживает первого контакта с противником. Для агентных систем вывод такой: нельзя надеяться на идеальный централизованный контроль каждого шага. Нужно заранее нарезать полномочия, контуры и ограничения так, чтобы отдельные части системы могли действовать автономно, но не выходили за допустимые границы.
Отсюда появляется ключевое понятие ASAMM: окно автономности. В докладе оно объясняется через эмпирическое наблюдение: для одного из агентов после примерно 50 строк кода в одной итерации начинали расти error rate и количество проваленных тестов; ещё одна метрика в транскрипте осталась неразборчивой. В общем виде окно автономности можно понимать как объём самостоятельной работы агента, умноженный на число итераций, в течение которых он действует без вмешательства человека.
На слайдах эта контрольная мера обозначена как AD-02 · Autonomy Window с формулой: Risk = Autonomy Window × Temporal Blast Radius. Уровни зрелости тоже описаны через практику контроля: на L1 окна измеряются, на L2 появляются threshold-gated checkpoints, на L3 границы закрепляются протоколом.
Чем больше окно автономности, тем больше вероятность, что агент успеет накопить и распространить ошибку. Поэтому контроль должен быть не только на входе и выходе, но и внутри траектории: что агент видел, что решил, что вызвал, что изменил и где вышел за ожидаемый сценарий.
Как ASAMM ложится на OWASP SAMM
ASAMM намеренно привязан к структуре OWASP SAMM, потому что эта методика уже знакома многим AppSec-командам. В докладе названы пять доменов:
- корпоративное управление;
- дизайн;
- реализация;
- верификация;
- операция.
Идея не в том, чтобы выбросить существующий SAMM, а в том, чтобы добавить в эти домены контрольные меры, специфичные для агентной разработки. Например, в управлении появляются вопросы модели доверия, ответственности и допустимого риска. В дизайне - границы автономности, полномочия инструментов, изоляция и blast radius. В реализации - то, как агент пишет код, какие инструкции получает, как подключается к GitHub, как использует MCP и какие изменения может вносить. В верификации - self-audit, независимая проверка выводов, анализ false positives и false negatives. В эксплуатации - forensic log, мониторинг поведения и расследование действий агента.
Слайды уточняют текущее состояние draft v0.3: 21 контрольная мера в публичном черновике, добавленные AG-04 и AI-06, пять семейств функций AG / AD / AI / AV / AO, шесть аксиом, включая evidence primacy, два пути внедрения: migration и greenfield, три трека аудита: self, independent и agent-as-auditor. Зрелость описана как evidence-based maturity L1/L2/L3. Также заявлены маппинги к NIST AI RMF, NCSC, OWASP ASI и AITG.
По словам докладчика, набор контрольных мер собирался из стандартов по безопасности, новостей об уязвимостях и последующей раскладки по доменам с помощью агента, после чего был отредактирован человеком. Отдельно отмечался cross-mapping с другими стандартами, включая ГОСТы безопасной разработки. Важно не переоценивать этот момент: в транскрипте нет деталей маппинга, но сам тезис понятен - ASAMM проектируется как надстройка, которую можно связать с уже существующей нормативной и процессной базой.
Agent-audit: forensic log, EDR и статический анализ агентов
Чтобы ASAMM не остался только методическим документом, был сделан инструмент agent-audit. В докладе он описан как проект на GitHub у scadastrangelove; рядом находится и сама методика. В слайдах инструмент назван companion audit tool for ASAMM: он читает agent homes, session traces и репозитории с инструкциями, разделяет raw hits, clustered issues и reviewer artifacts, а абстрактные контрольные меры превращает в проверяемые evidence.
У инструмента есть несколько режимов.
Первый режим - динамический. Это своего рода forensic log или даже EDR для работы агентов. Инструмент смотрит, какие промпты приходили агенту, какие вызовы он делал, какие команды запускал, какие действия выполнял. На слайдах среди входов названы session JSONL из Claude Code, Codex и OpenClaw-style traces, agent configs, hooks, MCP settings, local probes, tool calls, autonomy windows и risky chains. Такой журнал нужен не только для расследования инцидентов, но и для понимания реального поведения: агент может следовать инструкции формально, но выбирать опасную траекторию исполнения.
Второй режим - статический. Он применяется к наборам инструкций, skills, конфигураций или репозиториев, связанных с Claude, Codex и другими агентными системами. Слайды перечисляют типичные поверхности: SKILL.md, AGENTS.md, CLAUDE.md, plugin manifests, task YAML, prompt-bearing fields, MCP manifests, tool descriptions и capability declarations. В докладе прозвучала критика рынка «суперскиллов», которые продаются как универсальное улучшение, но могут быть вредными с точки зрения процесса или безопасности. Статический анализ позволяет спросить: нет ли в этих артефактах опасных паттернов с точки зрения ASAMM?
Есть и комбинированный режим, где статический и динамический анализ используются вместе. Это особенно важно для агентных систем: опасность может быть не в отдельной строке инструкции, а в переходе между инструкцией, вызовом инструмента и изменением кода.
Для описания поведения докладчик использует аналогию с трассой песочницы. У агента есть инструкция, вызовы инструментов, активность в коде и результат. Это можно представить как смесь Control-Flow Graph и Data-Flow Graph, собранную в некоторый AST для английского языка и агентных действий. Потенциально опасные сигнатуры тогда выглядят как опасные переходы: знакомый подход для тех, кто занимался песочницами и анализом поведения.
В слайдах этот подход назван AST / surface routing. Смысл в том, чтобы не применять все regex-правила ко всему как к плоскому тексту. Markdown AST отделяет прозу от кода и примеров, prompt-bearing YAML fields извлекаются явно, MCP manifests разбираются на уровне полей, а правила применяются только к заявленным audit surfaces. Это снижает количество ложных срабатываний ещё до ручного triage.
Отдельная часть инструмента - работа с false positives и false negatives. Поскольку детекторы могут быть чужими и не полностью доверенными, их нужно верифицировать статистически и дополнительно проверять через локальную или удалённую LLM. В докладе упоминались открытые проекты и сигнатуры, а также возможность подключать внешнюю модель через Ollama или другой механизм, чтобы перепроверять найденные срабатывания. Слайды перечисляют импортируемые источники правил: ATR, Aguara, Cisco PromptGuard, Gitleaks, NOVA и опционально Cisco MCP YARA; рядом заявлены native detectors и 573 импортированных правила. Но финальное решение всё равно остаётся за человеком.
Масштаб проверки в слайдах указан точнее, чем в устной части: 509 репозиториев, 20 241 файл, 4 882 medium+ findings и 88 native ASAMM findings. В качестве классов находок названы autonomous loops, prompt override и trust-boundary expansion.
Self-audit: почему модель нужно заставлять проверять себя несколько раз
Практический способ попробовать ASAMM - self-audit. В README проекта, по словам докладчика, есть набор промптов, которые можно вставить в ChatGPT, Claude или другую модель и попросить провести аудит репозитория по критериям ASAMM.
Важная деталь: модель просят перепроверять себя несколько раз. Это не ритуал и не украшение промпта. Первый вывод часто оказывается слабым: модель идёт по самому легкому пути, читает README, делает вид, что изучила проект целиком, и пропускает документы, владельцев системы и контекст неприемлемого риска.
Поэтому в чек-листе есть обязательный вопрос к модели: опросила ли она владельца, поняла ли, что система должна делать, и какие риски для владельца неприемлемы. В докладе прозвучал характерный пример: дополнительный промпт фактически ловит модель на том, что она этот шаг пропустила.
Такой self-audit полезен не только как контроль качества. Он помогает увидеть саму среду агента изнутри: какие у него ограничения sandbox, какой доступ к HTTP, какие процессы видны, какое окно автономности, через сколько его останавливают, что видно по логу. Это не заменяет полноценный аудит, но даёт техническую фактуру, которую трудно получить из маркетингового описания платформы.
Что это меняет для AppSec-команд
Главный практический вывод доклада: агентная разработка требует наблюдаемости поведения, а не только проверки результата. Code review готового diff уже недостаточен, если до него агент успел принять десятки решений, вызвать инструменты, изменить промежуточные файлы и закрепить неверные предпосылки.
ASAMM предлагает смотреть на агентную разработку как на систему с недоверенным автономным участником. Для такой системы нужны:
- явные границы полномочий агента;
- ограниченное и измеримое окно автономности;
- модель доверия к агентам, их выводам и источникам данных;
- оценка blast radius для ранних ошибок и опасных действий;
- forensic log всех существенных действий;
- статический анализ инструкций, skills и конфигураций;
- динамический анализ поведения в процессе разработки;
- работа с false positives и false negatives;
- self-audit и независимая перепроверка выводов;
- интеграция этих контрольных мер в знакомую рамку OWASP SAMM.
Это не делает агента «безопасным» автоматически. Но это переводит разговор из плоскости «давайте доверим модели писать код» в инженерную плоскость: какие полномочия выданы, как они ограничены, что записано в лог, кто проверил вывод, где может разрастись ошибка и как быстро её можно остановить. В терминах слайдов ASAMM расширяет SAMM там, где появились context flows, tool invocations as boundaries, delegated authority & autonomy, development as attack surface и runtime behavior as assurance.
Вопросы из зала
Где посмотреть код и проекты?
Докладчик указал на GitHub: github.com/scadastrangelove. По его словам, два самых новых проекта там связаны с методикой и инструментом. Один проект - сама методика, второй - tool для review поведения агента в процессе написания кода. Важно: это не обычный code review, а проверка поведения агента стандартными статико-динамическими анализаторами; конкретный пример анализатора в транскрипте остался неразборчивым.
Есть ли проверка через модельных судей: один агент делает, второй проверяет?
Да, эта идея уже частично реализована в механизме фильтрации false positives. Модель может не только отсекать ложные срабатывания, но и перепроверять выводы. Ограничение практическое: такая проверка потребляет много текста и контекста.
Что дальше развивать в аудиторе?
Следующая идея, озвученная в докладе, - добавить паттерны, связанные не только с security, но и с неправильной разработкой. Многие готовые skills и агентные практики могут быть вредными не потому, что прямо крадут секреты или ломают систему, а потому что портят процесс разработки. Это уже не линтер, а скорее процессный аудит.