Никто не любит, я взял на себя эту роль.

Я хотел сделать это с демкой, но поменялись ноутбуки, поэтому у меня здесь нет подписки. Я просто расскажу.

Итак, мой первый доклад про SAMM для агентов. Что такое SAMM? Я думаю, вы все прекрасно знаете, кто сталкивался с AppSec Security: это методика, с помощью которой проверяют безопасную разработку.

Здесь есть очень важный слайд: написано, какой я великий. А я сам об этом знаю, остальным это не так уж важно.

Как у меня вообще появилась идея сделать OWASP SAMM для агентов? Дело в том, что у меня не так давно, как у многих из нас, немножко поехала крыша на фоне агентской разработки. Я взял одну вещь, она называется [неразборчиво]. Это агент, которому можно дать возможность модифицировать себя. То есть он модифицирует среду, на которой работает, свои принципы работы, запускает новых агентов, форкает себя, живет в Claude, в общем, сам размножается.

И чем он меня поразил? Уже тем, что начал разрабатывать. Ну что я умею разрабатывать? Black-box-сканер. А когда я попытался перевести его на Qwen, на китайскую модель, он сказал, что не будет работать на китайской модели, потому что ему нравится Claude, и он портнул себе [неразборчиво], начал описывать другой проект, и они написали себе библию.

На самом деле я потом посмотрел те принципы, которые агенты сформировали, и сейчас их использую: в любой проект просто кидаю и говорю: работай так. По этому поводу у меня есть парочка статей на Хабре. По-моему, они называются «Я создатель, а ты СДД» — примерно так, не без пафоса.

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

Я, как любой безопасник, сразу начинаю подрагивать: зачем она ходит, что она делает, а тем более она еще и пишет сканер безопасности. А у нас сканер для какой безопасности? Я много раз его ловил на том, что она мягко относится к принципам, которые я ей задаю. То есть ей говоришь: вот этого не делать. Она: этого не делать, но вот здесь есть задача, ее надо выполнить, поэтому я это сделаю. А еще потом себе запишу в принципы, что в таких ситуациях можно это делать.

Соответственно, у нас полностью изменились модели разработки. У нас сейчас нет этих контролируемых сущностей. Вы можете сказать: ну это же обыкновенный разработчик, я привык его контролировать. Разработчика можно контролировать через зарплату, ему нужно ходить домой, растить детей, он боится соседей.

А эта штука не боится вообще ничего. Она живет в своей абсолютно другой жизни. Поэтому модель изменилась.

К чему я пришел? К тому, что модель разработки перестала быть циклом. Она стала спиралью. То есть мы в принципе проходим через те же самые паттерны: design, implementation, verification, operation, но все время на новом уровне сложности. И этот уровень сложности растет не годы, как раньше, а буквально недели.

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

И, соответственно, пришла идея о том, что нужно сделать что-то такое. Поскольку я человек методичный, я решил: а как это можно применить?

В Agentic SAMM (ASAMM) заложены четыре модели развития.

Первая — ситуация, когда ты строишь с нуля агентскую систему, просто решил построить.

Вторая — если у тебя есть готовая система, ты хочешь туда засунуть агента; там есть отдельный набор контролей, как это реализовывается.

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

И последнее — если ты получаешь выход агента в какой-то своей системе через MCP-шку либо какую-то другую историю.

Когда я начал размышлять, с помощью каких понятий это описывать, у нас есть понятные безопасные концепции. CIA — не та CIA, а confidentiality, integrity, availability. У нас есть понятный risk management, вроде мы к нему привыкли. И я понял, что это здесь не работает.

Поэтому я решил искать в смежных областях и нашел такую смежную область — она, извините, военная, разведка-контрразведка.

На самом деле это не первое мое обращение. Если кто знает такую концепцию, как GB 2.0, результативная безопасность и все такое, буду скромен: она выросла из одной моей статьи про миссиоцентрический подход к безопасности АСУ ТП, которую мы применяли тогда еще в [неразборчиво], паровозах и всяких электрических станциях давным-давно, когда я был маленьким мальчиком.

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

Здесь я углубился чуть поглубже и нашел три прекрасные штуки у военных.

Первая — модель доверия. Ее используют натовцы, она британская. Это как они работают со своими агентами разведки. Там матрица 6 на 6: насколько я доверяю источнику и насколько я доверяю информации, которую этот источник сообщил. Я ее использую как базис для аудиторов. То есть агент же может мне соврать, но я знаю, что этот агент врет чаще, чем другой агент.

Следующее: я заменяю риски на радиус поражения, blast radius. Почему? Потому что на самом деле в агентской разработке ошибки развиваются во времени. И чем раньше ошибка произошла, тем больше этот потенциальный радиус поражения. Например, если агент вдруг заложил себе какую-то неправильную концепцию в мозг, он с этой неправильной концепцией будет жить.

И последняя вещь — она из немецкой военной доктрины. Ну как, всех надо хвалить. Это, собственно говоря, как мы планируем операции. Здесь есть великая цитата о том, что ни один план не переживает первого контакта с противником. И идея в том, что ты максимально готовишь команды на всех уровнях к автономной операции. То есть ты пытаешься: вот у меня отделение, вот у меня взвод, вот у меня рота. И ты их нарезаешь так, что если что-то пойдет не так, то каждая из них начинает работать.

Вот эти вещи я взял, как-то перемешал и заложил в ASAMM. Не путать с OWASP SAMM.

И, соответственно, к чему мы здесь приходим? Модели управления, которые мы традиционно используем, — это модели управления чем-то доверенным, но, возможно, неизвестным. Здесь мы управляем неизвестным и недоверенным, потому что, как правило, модель чужая, непонятно как воспитанная, непонятно, что у нее в голове и вообще какая у нее мотивация.

Большая концепция, которую я заложил в ASAMM, — это окно автономности. Она очень сильно влияет на многие вещи.

Когда я начинал с Zhet агентную разработку, я попросил его проанализировать: а где ты ломаешься? Поскольку он писал код, он говорит: 50 строк кода. После 50 строк кода у меня в одной итерации спирали [неразборчиво]-rate, error rate и проваленные тесты начинают расти. Это зависит от конкретной модели: кто-то больше держит контекст и так далее.

Поэтому окно автономности — это вот эти 50 строк кода, умноженные на количество итераций, пока он действует самостоятельно. И чем больше окно автономности, тем больше потенциальных проблем.

Соответственно, поскольку я люблю стандарты, но только, знаете, в части: я знаю, что есть стандарты, я знаю их названия, но, как правило, их не читаю, потому что считаю, что всегда есть люди, которым нравится читать стандарты. Вот я к ним не отношусь.

Когда я вроде написал вот эту вещь, она красивая, я подумал: а как ее применить на практике? И чтобы не быть голословным, я написал тулу. Там есть где-то ссылочка на GitHub, она лежит на scadastrangelove.

Agent-audit — это штука, которая работает в двух режимах.

Первый режим — это проверка, такой forensic log или, если хотите, EDR для работы агентов. То есть она смотрит, какие промпты приходили, какие вызовы были, какие команды агент запускал, что он делал.

И второй режим статический — это когда берешь набор Claude или Codex просто с репозиториев. Сейчас же как snake oil все продают: «вот у меня есть суперскиллы, которыми ты можешь пользоваться». И ты просто засовываешь их туда и говоришь: а нет ли там чего-то вредного? Именно с точки зрения методики ASAMM.

Я гонял на достаточно больших выборках. То есть взял где-то 500 репозиториев, самых популярных, гонял, разбирал результаты, плюс гонял на своих живых проектах — ну и у всех, до кого дотянулся.

На самом деле, как делать проверку, я расскажу: это очень просто. И эта штука подсказывала мне интересный результат. Когда ты сидишь, работаешь, вроде все окей, а потом она говорит: посмотри, у тебя кто-то уже три дня занимается этим.

С точки зрения организации ASAMM максимально привязан к SAMM, потому что он многим понятен, многие его используют. Я решил взять пять доменов: корпоративное управление, дизайн, реализация, верификация и операция. И просто напихал в них дополнительные контроли, которые относятся к агентной разработке.

Откуда я их взял? Ну, вы, конечно, не удивитесь: я взял все стандарты по безопасности, взял все новости по новым уязвимостям, скормил агенту и сказал: разложим-ка их на полочки. Он разложил их на полочки, я подредактировал.

И еще что это дало? Это дало мне cross-mapping с большинством стандартов, включая ГОСТы безопасной разработки. И на самом деле ASAMM, наверное, первый в мире крутой стандарт, который заполонил вселенную, который параллельно разрабатывается и на русском языке, еще с cross-mapping-документом. Надеюсь, OWASP его прочитал.

Соответственно, я немножко про эту тулу рассказал. Думаю, что можно в нее подвигаться; это пропущу.

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

Плюс есть еще одна штука: ты можешь взять либо локального агента, который у тебя был установлен, либо через VLM, либо через Ollama подключить внешнюю модельку и сказать: сделай мне, пожалуйста, false positive check на том, что эта штука нашла. Или что Ollama не нашла.

Откуда я брал сигнатуры? На входе все, до чего дотянется, я технику пропущу. Оказалось, естественно, поскольку я, когда изобретаю что-то великое, предполагаю, что кто-то умный это уже сделал до меня, я прошелся: есть несколько открытых проектов. ATR, Aguara, Cisco PromptGuard — там достаточно интересные лицензии. И я просто сел, скомпилировал свои правила. В принципе, когда вы с GitHub заходите, там есть опция скачать свежие сигнатуры и собрать, запулить.

Плюс поставить памятник: там есть PR и пачка всех неправильных правил, чтобы было все привычно.

Что я сделал сверху? Сейчас... так, это триаж. Да, тороплюсь.

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

Соответственно, это такая смесь Control-Flow Graph и Data-Flow Graph, в которых в принципе есть вывод песочницы. Это в такой AST собирается, и там потенциально опасные — мои сигнатурки — это как раз потенциально опасные переходы, которые известны всем, кто с песочницами занимался.

Как я уже говорил, там есть механизм фильтрации ложных срабатываний. Есть детекторы. Поскольку я тащу чужие детекторы, я им всем не доверяю. На статистике объема этих детекторов я набираю false positives, false negatives. И у меня есть такой статический верификатор. Потом все, что верификатор набрал, можно отправить либо в локальную модельку, либо в удаленную LLM-ку, и это все дело выдается человеку, чтобы он сказал: ну, все правильно написали.

Это я пропущу, с вашего позволения. К сожалению, демка не удалась: просто другой ноутбук.

Смотрите, как проверить, что SAMM работает. Когда зайдете на README, там есть ссылка self-audit. Возьмите — там просто набор промптов, которые вы можете вставить в любую ленту. Вы можете взять просто ChatGPT либо Claude и сказать: вот тебе репозиторий, разбери, проведи self-audit по критериям ASAMM.

Когда будете эти чек-листы читать, вы спросите: а почему там у тебя в промптах ты три раза просишь модельку проверить себя? Дело в том, что первый вывод, который вы получите, будет абсолютной чушью. То есть она пойдет по самому легкому пути. Даже если это SOTA-модель, она скажет: я прочитала. Но на самом деле она прочитала README, документы не читала.

Более того, там есть обязательные пункты в чек-листе насчет того: а ты опроси вообще владельца, что система должна делать и что для него неприемлемый риск. Она, как правило, это пропускает. Поэтому четвертым промптом у меня: а ты уже опросил владельца? Больше можешь не проверять? И забыла.

Но вот за эти несколько итераций я, например, узнал, как устроен sandbox Claude. Почему? Потому что по сути чек-лист ASAMM достаточно технический. «И как у тебя устроено ограничение?» Он говорит: да, интересно, как оно меняется со временем. Вы же не знаете, что у него в sandbox. Он говорит: да, я работаю по-другому, у меня [неразборчиво], я имею полный доступ к HTTP, POST, там ты-ты-ты-ты. Вот у меня какой-то процессор, такое-то окно автономии, через сколько-то меня убивают, судя по логу.

Это забавные вещи, которые можно посмотреть изнутри, если вы работаете в облаке.

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

Дадите какой-то, может быть, более свернутый фидбэк, заведете issue на GitHub — я буду очень рад. Буду скармливать это агентам, они будут проверять других агентов, и такая у нас будет агентическая жизнь.

И да, в конце: это уже представлено на рабочей группе OWASP. Они взяли работу, я думаю, что где-то за полгода интегрируют в новую редакцию SAMM, которую они прямо сейчас пишут.

У меня все.

Все, тут пять минут на вопросы.

Ну так, нормально.

Вопрос из зала: Увидеть код, который...

Сергей: А, ну все очень элементарно: github.com/scadastrangelove. И там прямо два самых новых проекта — это они. Один — это методика, второй — это...

Да, вот прямо сзади вы можете развернуться, у вас слева будет внизу.

А второй — это tool, которая review-ит код. Но это не code review как таковой, это code review поведения агента в процессе написания этого кода стандартными статико-динамическими анализаторами. Ну, [неразборчиво], например.

Вопрос из зала: А нет попыток сделать проверку с помощью модельных судей? То есть один агент делает, а второй проверяет, например.

Сергей: Это вот, собственно, штука, которая фильтрует false positives. Она может, кроме фильтрации false positives, еще и перепроверять, но она жрет до фига текста. Я это делаю.

Вопрос из зала: Вклады есть, я понял.

Сергей: Да-да-да. То есть она может как false positive шейпить, так еще и другой shape приносить. На самом деле у меня следующая идея по развитию именно аудитора — это вбилдить туда паттерны, не связанные с security, а паттерны, связанные с неправильной разработкой.

То есть многие вот те skills, которые сейчас продаются как snake oil, они прямо вредные. Я их просто тестировал много, разработал там некоторую свою историю и хочу, чтобы не только security проверялась, но и сам процесс разработки.

Ну, это не линтер, это скорее процессный аудит.

Коллеги, огромное спасибо.

Совершенно невероятно.

---

Неоднозначные места, оставленные под вопросом:
- Название саморазмножающегося агента в начале доклада неразборчиво по raw-транскрипту.
- Фраза «портнул себе [неразборчиво]» и следующий объект/проект после перехода с китайской модели требуют сверки со звуком или слайдами.
- В блоке про GB 2.0 место/объект внедрения после АСУ ТП неразборчивы.
- Метрика перед `error rate` в описании окна автономности неразборчива.
- Пример статико-динамического анализатора в ответе на вопрос из зала неразборчив.
- Фраза про `false positive`/`shape` сохранена близко к raw-тексту как сленг, но термин может требовать уточнения по аудио.