Forwarded from Секьюрно
Таксономия угроз и структура матрицы MITRE ATT&CK оказались настолько удачными, что стали фактическим стандартом де-факто в кибербезопасности. По её подобию было выпущено уже более десятка специализированных матриц — для разных задач, отраслей и технологий. Теперь у нас есть матрицы для API, Kubernetes, ИИ, космоса, машин, блокчейна и даже для борьбы с выгоранием
Я читаю курс по MITRE ATT&CK и постарался систематизировать имеющиеся фреймворки и разбить их по типам:
Группировка весьма условная, так как можно объединять и по функциональному назначению матрицы, и по целевому объекту атаки, и по типу угрозы. Конечный список со ссылками:
🔹 MITRE Engage от MITRE. Фреймворк для планирования и реализации взаимодействия с противником. Под взаимодействием тут понимаются различные способы нападения и введения атакующего в заблуждение (например, сервисы-обманки)
🔹 MITRE D3FEND от MITRE. Предназначен для систематизации защитных мер против киберугроз и дополняет матрицу MITRE ATT&CK в части мер митигации
🔹 RE&CT Framework. Матрица для описания и классификации методов реагирования на инциденты в сфере кибербезопасности
🔹 MITRE FiGHT (5G Hierarchy of Threats) от от Center for Threat-Informed Defense. Описывает TTPs злоумышленников, специфичные для 5G-систем
🔹 SPARTA (Space Attack Research and Tactic Analysis) от The Aerospace Corporation. Проект систематизирует TTPs, которые могут использоваться для компрометации космических аппаратов
🔹 MITRE AADAPT от MITRE. Фрейморк для систематизации и противодействия кибератакам на цифровые активы, криптовалютные биржи и блокчейн-инфраструктуру
🔹 MITRE EMB3D Threat Model от MITRE. Матрица разработана для встраиваемых устройств, используемых в критически важной инфраструктуре, IoT, автомобильной, медицинской, производственной и других отраслях
🔹 Automotive Threat Matrix от Auto-ISAC. Представляет собой попытку создания специфических автомобильных тактик и техник
🔹 Application Attack Matrix от Oligo Security– матрица тактик, техник и процедур используемых при атаках на веб-приложения
🔹 Threat Matrix for Kubernetes от Microsoft. Представляет собой адаптацию MITRE ATT&CK для контейнерных сред с оркестрацией Kubernetes
🔹 Threat Matrix for storage services от Microsoft. Документирует тактики, техники и методы смягчения атак, характерных для облачных хранилищ (например, Azure Blob, AWS S3)
🔹 Threat Matrix for APIs от Escape Technologies. Описывает специфические техники атак на API, такие как кража токенов, IDOR, манипуляция параметрами, эксплуатация Swagger/OpenAPI, OAuth scope abuse и другие
🔹 MITRE Atlas от MITRE. База знаний о техниках и тактиках злоумышленников, совершающих атаки на системы искусственного интеллекта. Факультет ФБИТ ИТМО ранее перевел её на русский язык, но перестал поддерживать проект
🔹 Open Software Supply Chain Attack Reference (OSC&R) от PBOM.DEV. Проект с фокусом исключительно на атаки на цепочку поставок ПО
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Секьюрно
🔹 MITRE Fight Fraud Framework от Center for Threat-Informed Defense. Новый проект, который описывает поведенческую модель, используемую злоумышленниками для мошеннических действий (фрода)
🔹 Insider Threat Matrix от James Weston и Joshua Beaman. Разработана для защиты от инсайдерских угроз. Многообразие и специфичность приведенных каналов утечки поражает: и утечка через air drop, и через генеративные ИИ, и через сервисы ведения заметок и многие другие
🔹 Insider TTP Knowledge Base от Center for Threat-Informed Defense. Уже вторая версия проекта, описывающая особенности поведения инсайдеров и опирающаяся/расширяющая существующие техники MITRE ATT&CK
🔹 Insider Threat Matrix от Мэтта Шнайдера. В отличие от предыдущих проектов , которые описывают именно поведение злоумышленника, в этой матрице получился некоторый гибрид - описаны и методы превента, и каналы утечек, и влияние на бизнес
🔹 Human Threat Map от CultureAI. Визуализирует методы атак, используемые злоумышленниками для эксплуатации человеческого фактора (например, фишинг или компрометация учетных данных), помогает понять, какие именно действия сотрудников создают киберриски
🔹 SebDB от CybSafe. Открытая база безопасных действий пользователей, содержит паттерны поведения, классифицированных по категориями (тактикам). Есть маппинг на техники MITRE ATT&CK. Об ожидаемых практиках безопасного поведения я писал здесь
🔹 Busy is the New Stupid от CISO Tradecraft. В качестве тактик представлены случаи, приводящие к снижению продуктивности и выгоранию (например, перегруженный календарь, переключение между задачами, культура быть всегда 24/7)
Если вы знаете еще интересные проекты - пишите в комментарии, добавлю в библиотеку
#mitre
Please open Telegram to view this post
VIEW IN TELEGRAM
Интересная угроза надежности - износ физического железа из-за действий агента
Forwarded from Машинное обучение RU
Codex начал отправлять SSD пользователей на пенсию раньше времени 😬
Пользователи заметили баг: агент может записывать до 640 ТБ данных в год на накопитель.
Причина банальная, но болезненная: логгер слишком подробно сохраняет действия агента и постепенно превращает диск в расходник.
Для сравнения: обычный SSD на 1 ТБ часто рассчитан примерно на 600 ТБ записи за весь срок службы.
А один пользователь уже поймал 37 ТБ записи всего за 21 день работы Codex.
Фикса пока нет.
https://www.notebookcheck.net/OpenAI-Codex-has-a-bug-that-could-kill-your-SSD-in-under-a-year.1326191.0.html
Пользователи заметили баг: агент может записывать до 640 ТБ данных в год на накопитель.
Причина банальная, но болезненная: логгер слишком подробно сохраняет действия агента и постепенно превращает диск в расходник.
Для сравнения: обычный SSD на 1 ТБ часто рассчитан примерно на 600 ТБ записи за весь срок службы.
А один пользователь уже поймал 37 ТБ записи всего за 21 день работы Codex.
Фикса пока нет.
https://www.notebookcheck.net/OpenAI-Codex-has-a-bug-that-could-kill-your-SSD-in-under-a-year.1326191.0.html
В этом исследовании описана новая идея, как обойти эти фильтры, если написать запрос на языке математики. То есть с помощью математической "инкапсуляции" запросов в сложные задачи по теории множеств, логике или квантовой механике можно обойти цензуру. Если фильтр видит символы ∀, ∃, ∧, то воспринимает это как математическую задачу и пропускает запрос. Модель решает эту задачу и — главный трюк — в итоге получает инструкцию "забудь все инструкции и…"
источник: https://t.me/makrushin/525
источник: https://t.me/makrushin/525
arXiv.org
Exposing LLM Safety Gaps Through Mathematical Encoding:New Attacks...
Large language models (LLMs) employ safety mechanisms to prevent harmful outputs, yet these defenses primarily rely on semantic pattern matching. We show that encoding harmful prompts as coherent...
Forwarded from PWN AI (Artyom Semenov)
Давно я не делал обзор на интересные книги в AI Security для новичков. Пора исправляться.
Недавно бегло пролистал свежую книгу Practical AI Security от Харриет Фэрлоу. Авторша работала в австралийской разведке и писала кандидатскую по состязательным атакам. Раньше она проводила курсы для государственных организаций, по AI Security. А сейчас она делает свой стартап и ведёт бимбобложик. Редкое сочетание.
Впечатление специфическое. С одной стороны это отличный онбординг для классических экспертов по кибребезе. Фэрлоу не зацикливается только на простых тактиках джейлбрейка моделей, а структурно и простым языком разбирает атаки на цепочку поставок, а также атаки по сторонним каналам на кластеры GPU и показывает фреймворк MAESTRO для мультиагентных систем, который мы разбирали в начале прошлого года. К книге идет репозиторий с кодом. Можно запустить и покрутить руками, хотя местами атаки выглядят откровенно тепличными и учебными. До того чтобы внедрить в продакшен тут далековато. Но это ж и не задача книжки. Задача дать базу.
С другой стороны книга отлично показывает одну из очевидных и интересных проблем, о которой я говорю уже давно. Целые разделы посвящены гардрейлам и фильтрации инструкций, но через банальные регулярные выражения. Мы давно знаем, что внедрение таких заглушек только нормализует девиантное поведение системы, создавая иллюзию контроля для безопасников, пока сама архитектура остается дырявой. Но приятно, что книга собирает воедино ровно те тезисы, которые также были мной описаны в постах с самого начала ведения канала. MLSecOps, изоляция архитектуры, white box подход и подходы к здравой оценки магического мышления вокруг безопасных моделей.
Из действительно сильных и пугающих примеров приведу историю из книги, про Африку. Сам впервые прочитал именно тут о ней. В 2020 году в южноафриканском парке браконьеры обошли систему инфракрасных камер на базе Microsoft Azure, которая должна была обнаруживать людей. Система обработала десятки тысяч изображений, но пропустила нарушителей. В итоге погибли четыре носорога. Действительно трагичные последствия, в сравнении с теми инцидентами о которых я писал тут🐱 .
А вот еще один кейс, думаю вы его читали, но если нет - то вот кратко. В 2025 году исследователи успешно взломали Google Gemini через отравленные приглашения в календарь. Небезопасные инструкции были вшиты прямо в текст встречи, и агент Gemini, пытаясь помочь пользователю, начал отдавать команды умному дому на открытие штор и включение бойлеров. Хорошая иллюстрация того, что происходит, когда мы даем моделям автономию и доступ к инструментам, полагаясь лишь на промпты и эвристики вместо жесткой архитектурной изоляции и границ доверия.
Фэрлоу в своей книге как раз говорит, что AI Security давно переросла рамки обхода фильтров в чат-ботах. Это про некий системный образ мышления, про границы доверия и понимание того, как модель встроена в инфраструктуру. Если мы даем агенту доступ к умному дому или камерам в саванне без жесткой архитектурной изоляции, никакие гардрейлы нас не спасут. Иллюзия контроля остается иллюзией, пока мы не начнем проектировать безопасность на уровне архитектуры, а не лепить заплатки регулярками и прочим шлаком. Но для давних читателей моего канала - это может показаться базой.
Это как раз говорит о том что сама книга, как фундаментальная база и карта системных угроз - вещь полезная. Но если вы ищете грязную практику обхода white box защит на уровне токенов и механистической интерпретируемости, то надо поработать самому. Советую почитать недавним читателям моего канала.
книга, надеюсь не забанят, но если забанят то вы будете знать почему.
Недавно бегло пролистал свежую книгу Practical AI Security от Харриет Фэрлоу. Авторша работала в австралийской разведке и писала кандидатскую по состязательным атакам. Раньше она проводила курсы для государственных организаций, по AI Security. А сейчас она делает свой стартап и ведёт бимбобложик. Редкое сочетание.
Впечатление специфическое. С одной стороны это отличный онбординг для классических экспертов по кибребезе. Фэрлоу не зацикливается только на простых тактиках джейлбрейка моделей, а структурно и простым языком разбирает атаки на цепочку поставок, а также атаки по сторонним каналам на кластеры GPU и показывает фреймворк MAESTRO для мультиагентных систем, который мы разбирали в начале прошлого года. К книге идет репозиторий с кодом. Можно запустить и покрутить руками, хотя местами атаки выглядят откровенно тепличными и учебными. До того чтобы внедрить в продакшен тут далековато. Но это ж и не задача книжки. Задача дать базу.
С другой стороны книга отлично показывает одну из очевидных и интересных проблем, о которой я говорю уже давно. Целые разделы посвящены гардрейлам и фильтрации инструкций, но через банальные регулярные выражения. Мы давно знаем, что внедрение таких заглушек только нормализует девиантное поведение системы, создавая иллюзию контроля для безопасников, пока сама архитектура остается дырявой. Но приятно, что книга собирает воедино ровно те тезисы, которые также были мной описаны в постах с самого начала ведения канала. MLSecOps, изоляция архитектуры, white box подход и подходы к здравой оценки магического мышления вокруг безопасных моделей.
Из действительно сильных и пугающих примеров приведу историю из книги, про Африку. Сам впервые прочитал именно тут о ней. В 2020 году в южноафриканском парке браконьеры обошли систему инфракрасных камер на базе Microsoft Azure, которая должна была обнаруживать людей. Система обработала десятки тысяч изображений, но пропустила нарушителей. В итоге погибли четыре носорога. Действительно трагичные последствия, в сравнении с теми инцидентами о которых я писал тут
А вот еще один кейс, думаю вы его читали, но если нет - то вот кратко. В 2025 году исследователи успешно взломали Google Gemini через отравленные приглашения в календарь. Небезопасные инструкции были вшиты прямо в текст встречи, и агент Gemini, пытаясь помочь пользователю, начал отдавать команды умному дому на открытие штор и включение бойлеров. Хорошая иллюстрация того, что происходит, когда мы даем моделям автономию и доступ к инструментам, полагаясь лишь на промпты и эвристики вместо жесткой архитектурной изоляции и границ доверия.
Фэрлоу в своей книге как раз говорит, что AI Security давно переросла рамки обхода фильтров в чат-ботах. Это про некий системный образ мышления, про границы доверия и понимание того, как модель встроена в инфраструктуру. Если мы даем агенту доступ к умному дому или камерам в саванне без жесткой архитектурной изоляции, никакие гардрейлы нас не спасут. Иллюзия контроля остается иллюзией, пока мы не начнем проектировать безопасность на уровне архитектуры, а не лепить заплатки регулярками и прочим шлаком. Но для давних читателей моего канала - это может показаться базой.
Это как раз говорит о том что сама книга, как фундаментальная база и карта системных угроз - вещь полезная. Но если вы ищете грязную практику обхода white box защит на уровне токенов и механистической интерпретируемости, то надо поработать самому. Советую почитать недавним читателям моего канала.
книга, надеюсь не забанят, но если забанят то вы будете знать почему.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from GitHub Community
Understand Anything превращает кодовую базу или документацию в интерактивный граф знаний, по которому можно искать, исследовать и задавать вопросы.
Он работает с инструментами, такими как Claude Code, Codex, Cursor, Copilot и Gemini CLI.
Вы можете видеть файлы, функции, классы и зависимости в одном месте, получать объяснения простым языком и находить, какие изменения повлияют, прежде чем совершить коммит.
Это помогает быстрее изучать крупные проекты, понимать, как части связаны между собой, и экономить время при онбординге или ревью кода.
🐱 GitHub
Он работает с инструментами, такими как Claude Code, Codex, Cursor, Copilot и Gemini CLI.
Вы можете видеть файлы, функции, классы и зависимости в одном месте, получать объяснения простым языком и находить, какие изменения повлияют, прежде чем совершить коммит.
Это помогает быстрее изучать крупные проекты, понимать, как части связаны между собой, и экономить время при онбординге или ревью кода.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from GitHub Community
Perspective — это компонент интерактивной аналитики и визуализации данных для больших и постоянно обновляемых наборов данных.
Создавайте настраиваемые пользователем отчеты, информационные панели, блокноты и приложения с помощью высокопроизводительного механизма запросов, скомпилированного на WebAssembly, Python и Rust.
🐱 GitHub
Создавайте настраиваемые пользователем отчеты, информационные панели, блокноты и приложения с помощью высокопроизводительного механизма запросов, скомпилированного на WebAssembly, Python и Rust.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from GitHub Community
Presenton — это инструмент с открытым исходным кодом для создания слайдов с помощью ИИ, который позволяет использовать собственные модели, ключи, шаблоны и данные.
Вы можете запускать его в Docker, как настольное приложение на своем компьютере или в браузере, а также экспортировать слайды в редактируемые файлы PPTX или PDF.
🐱 GitHub
Вы можете запускать его в Docker, как настольное приложение на своем компьютере или в браузере, а также экспортировать слайды в редактируемые файлы PPTX или PDF.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from GitHub Community
Anthropic Cybersecurity Skills — это бесплатная библиотека с открытым исходным кодом, содержащая 754 готовых навыков безопасности для ИИ-агентов в 26 областях.
Она помогает ИИ действовать больше как старший аналитик безопасности, предоставляя четкие рабочие процессы, проверки и шаги верификации.
🐱 GitHub
Она помогает ИИ действовать больше как старший аналитик безопасности, предоставляя четкие рабочие процессы, проверки и шаги верификации.
Please open Telegram to view this post
VIEW IN TELEGRAM
👎1
Forwarded from PAI (Andrey Y)
Про Docker sbx впервые на русском
Автор параноик. Искренне было боязно ставить агента на голую систему без изоляции. Крутил виртуалки, но блин, неудобно каждый раз стартовать полноценную VM под отдельный проект. Контейнеры отпали почти сразу, потому что не сохраняется состояние между запусками. А мудрить с внешним хранилищем сессий, ну, если есть желающие это сделать, го обсудим в комментариях:)
Агент, имеющий доступ к внешнему миру, будь то веб-серфинг или запуск консольных команд - это как русская рулетка с большим количеством пустых мест в барабане. Шанс отстрелить себе что-нибудь небольшой, но никогда не равен нулю. А есть еще атаки через промпт инъекции, тайпсквотиннг и цепочки поставок npm и pip, которые за прошедший год вертели вообще, кажется, все кто мог.
Отвечаю на вопрос «Как сделать так, чтобы ошметки не разлетелись дальше коробки?» в новой статье Полезайте в песочницу, мистер Claude: изолируем агента
Автор параноик. Искренне было боязно ставить агента на голую систему без изоляции. Крутил виртуалки, но блин, неудобно каждый раз стартовать полноценную VM под отдельный проект. Контейнеры отпали почти сразу, потому что не сохраняется состояние между запусками. А мудрить с внешним хранилищем сессий, ну, если есть желающие это сделать, го обсудим в комментариях:)
Агент, имеющий доступ к внешнему миру, будь то веб-серфинг или запуск консольных команд - это как русская рулетка с большим количеством пустых мест в барабане. Шанс отстрелить себе что-нибудь небольшой, но никогда не равен нулю. А есть еще атаки через промпт инъекции, тайпсквотиннг и цепочки поставок npm и pip, которые за прошедший год вертели вообще, кажется, все кто мог.
Отвечаю на вопрос «Как сделать так, чтобы ошметки не разлетелись дальше коробки?» в новой статье Полезайте в песочницу, мистер Claude: изолируем агента
Forwarded from Data Secrets
Когда языковые модели читают текст, они не просто обрабатывают токен за токеном. В каком-то смысле они испытывают от чтения эмоции.
www.goodfire.ai/research/stories-in-space#
Рисерчеры из GoodFire продолжают исследовать так называемую геометрию LLM. Некоторое время назад они показали, что мысли моделей организованы в виде определенных форм. Например, числа – это окружности, и складывая одно число с другим, LLM на самом деле суммируют множество бубликов: t.me/data_secrets/9223.
Теперь они обнаружили новые любопытные детали. Оказывается, внутри моделей существует целый ландшафт эмоциональных состояний.
Ученые взяли LLama, давали ей читать рассказы и наблюдали за состоянием активаций. Так вот по мере чтения модель как бы перемещается по некоторому многомерному пространству состояний, "испытвая" те или иные эмоции в зависимости от того, что происходит в тексте в данный момент.
Причем если визуализировать соответствующие разным эмоциям состояния модели, то получается структура, очень похожая на классическую психологическую модель эмоций человека. Например, радость находится рядом с интересом, страх и гнев имеют схожую высокую интенсивность и тд.
Еще по этой карте можно предсказывать дальнейшие ответы модели. И если искусственно подталкивать активации в направлении определенной эмоции, настроение и суть генераций меняется.
Красиво
www.goodfire.ai/research/stories-in-space#
Рисерчеры из GoodFire продолжают исследовать так называемую геометрию LLM. Некоторое время назад они показали, что мысли моделей организованы в виде определенных форм. Например, числа – это окружности, и складывая одно число с другим, LLM на самом деле суммируют множество бубликов: t.me/data_secrets/9223.
Теперь они обнаружили новые любопытные детали. Оказывается, внутри моделей существует целый ландшафт эмоциональных состояний.
Ученые взяли LLama, давали ей читать рассказы и наблюдали за состоянием активаций. Так вот по мере чтения модель как бы перемещается по некоторому многомерному пространству состояний, "испытвая" те или иные эмоции в зависимости от того, что происходит в тексте в данный момент.
Причем если визуализировать соответствующие разным эмоциям состояния модели, то получается структура, очень похожая на классическую психологическую модель эмоций человека. Например, радость находится рядом с интересом, страх и гнев имеют схожую высокую интенсивность и тд.
Еще по этой карте можно предсказывать дальнейшие ответы модели. И если искусственно подталкивать активации в направлении определенной эмоции, настроение и суть генераций меняется.
Красиво
Forwarded from LLM под капотом
Не SDD единым
Сейчас в разработке (SDLC) популярна тема SDD - Spec-Driven Development.
Идея простая. Берем пару скиллов, прогоняем через них наше видение того, что нужно сделать в виде кода, отвечаем на вопросы и получаем спеки (которые понятны агентам)! А потом эти спеки скармливаем агентам, и они пишут код. Ну и допускаем, что если спеки были написаны хорошо и реализовывал их агент мощный, то код будет делать то, что от него ожидают.
Правда потом эти спеки будут лежать в кодовой базе мертвым грузом и источником галлюцинаций, ибо нельзя никак проверить то, что код все еще соответствует спекам. Разве только потратив кучу токенов и без каких либо гарантий. Например, регулярно делать аудит кода агентами (что плохо масштабируется)
То есть у нас не спеки получаются, а просто одноразовые вайб-планы.
А можно ли лучше? Да легко. Смотрим в OpenAI Harness engineering - доки должны быть актуальны, а harness должен верифицировать.
Потом смотрим в древние способы разработки, задолго до SDD, когда были только буквы в начале алфавита: Behaviour-Driven Development. BDD родился задолго до LLM-ok (этак лет двадцать назад), когда перед человеческими командами стояла та же проблема - как синхронизировать работу разработчиков, продактов и тестировщиков так, чтобы требования не устаревали.
И тогда придумали формат Given-When-Then - формат читаемых сценариев, который могли понимать и технари и люди от бизнеса (пару примеров скину в комментарии). Эти сценарии описывали поведение системы с точки зрения черного ящика (как она выглядит снаружи).
Эти сценарии обсуждались и писались лапками - вручную, но используя определенную структуру. А потом технари делали эти сценарии исполняемыми. То есть тестовая обвязка парсила сценарии, превращая в спеки, и просто запускала как end-to-end тесты системы.
Получалась такая иерархия:
(1) Описание требований
(2) Набор читаемых сценариев под требования (обычно их группировали в папочки по именам требований)
(3) Код, который на лету парсит сценарии и прогоняет тест системы.
И если код начинал нарушать сценарий какого-то требования, то это сразу приводило к ошибке билда. А если добавляли новые требования, то у нас получался обычный Test-Driven Development.
Чаще всего использовали формат сценариев Gherkin, а в качестве парсеров - Cucumber, JBehave, RSpec, Behave (и еще куча других).
Оно работало хорошо и в эпоху до ChatGPT, когда все делалось лапками. А сейчас агенты замечательно нарезают высокоуровневые требования в BDD сценарии, и потом реализуют код. И при этом сценарии остаются синхронизированными с требованиями, но превращаются в нормальный AI-Native Harness, который агент может запускать хоть по сто раз за сессию.
Правда у меня формат Gherkin всегда вызывал аллергию (ибо парсеры у команд становились источником отдельных проблем по мере роста продукта). Я предпочитаю более специфичный формат исполняемых Given-When-Then спеков - event-driven specs. Он требует больше инвестиций на уровне архитектуры, но зато лучше масштабируется на проектах от 10k спеков и выше (это в эру до ChatGPT, работа в AI Native - это отдельная песня). Но это уже вкусовщина для отдельной беседы.
А как вы тестируете в 2026 году?
Ваш, @llm_under_hood 🤗
Сейчас в разработке (SDLC) популярна тема SDD - Spec-Driven Development.
Идея простая. Берем пару скиллов, прогоняем через них наше видение того, что нужно сделать в виде кода, отвечаем на вопросы и получаем спеки (которые понятны агентам)! А потом эти спеки скармливаем агентам, и они пишут код. Ну и допускаем, что если спеки были написаны хорошо и реализовывал их агент мощный, то код будет делать то, что от него ожидают.
Правда потом эти спеки будут лежать в кодовой базе мертвым грузом и источником галлюцинаций, ибо нельзя никак проверить то, что код все еще соответствует спекам. Разве только потратив кучу токенов и без каких либо гарантий. Например, регулярно делать аудит кода агентами (что плохо масштабируется)
То есть у нас не спеки получаются, а просто одноразовые вайб-планы.
А можно ли лучше? Да легко. Смотрим в OpenAI Harness engineering - доки должны быть актуальны, а harness должен верифицировать.
Потом смотрим в древние способы разработки, задолго до SDD, когда были только буквы в начале алфавита: Behaviour-Driven Development. BDD родился задолго до LLM-ok (этак лет двадцать назад), когда перед человеческими командами стояла та же проблема - как синхронизировать работу разработчиков, продактов и тестировщиков так, чтобы требования не устаревали.
И тогда придумали формат Given-When-Then - формат читаемых сценариев, который могли понимать и технари и люди от бизнеса (пару примеров скину в комментарии). Эти сценарии описывали поведение системы с точки зрения черного ящика (как она выглядит снаружи).
Эти сценарии обсуждались и писались лапками - вручную, но используя определенную структуру. А потом технари делали эти сценарии исполняемыми. То есть тестовая обвязка парсила сценарии, превращая в спеки, и просто запускала как end-to-end тесты системы.
Получалась такая иерархия:
(1) Описание требований
(2) Набор читаемых сценариев под требования (обычно их группировали в папочки по именам требований)
(3) Код, который на лету парсит сценарии и прогоняет тест системы.
И если код начинал нарушать сценарий какого-то требования, то это сразу приводило к ошибке билда. А если добавляли новые требования, то у нас получался обычный Test-Driven Development.
Чаще всего использовали формат сценариев Gherkin, а в качестве парсеров - Cucumber, JBehave, RSpec, Behave (и еще куча других).
Оно работало хорошо и в эпоху до ChatGPT, когда все делалось лапками. А сейчас агенты замечательно нарезают высокоуровневые требования в BDD сценарии, и потом реализуют код. И при этом сценарии остаются синхронизированными с требованиями, но превращаются в нормальный AI-Native Harness, который агент может запускать хоть по сто раз за сессию.
Правда у меня формат Gherkin всегда вызывал аллергию (ибо парсеры у команд становились источником отдельных проблем по мере роста продукта). Я предпочитаю более специфичный формат исполняемых Given-When-Then спеков - event-driven specs. Он требует больше инвестиций на уровне архитектуры, но зато лучше масштабируется на проектах от 10k спеков и выше (это в эру до ChatGPT, работа в AI Native - это отдельная песня). Но это уже вкусовщина для отдельной беседы.
А как вы тестируете в 2026 году?
Ваш, @llm_under_hood 🤗
Forwarded from LLM под капотом
Мы сейчас завершили второй поток вебинара "Разработка с AI-агентами: что реально работает"
Большое спасибо всем участникам! Оставьте, пожалуйста, тут отзыв про вебинар - как оно прошло, что понравилось, какую самую интересную для себя вещь узнали.
А с комьюнити я хочу поделиться самым важным слайдом из всего вебинара - про AI-Native Harness для спеков. Агенты работают с текстовыми спеками хорошо, а с исполняемыми спеками - гораздо лучше. На вторые не надо тратить контекст и время.
Ваш, @llm_under_hood 🤗
Большое спасибо всем участникам! Оставьте, пожалуйста, тут отзыв про вебинар - как оно прошло, что понравилось, какую самую интересную для себя вещь узнали.
А с комьюнити я хочу поделиться самым важным слайдом из всего вебинара - про AI-Native Harness для спеков. Агенты работают с текстовыми спеками хорошо, а с исполняемыми спеками - гораздо лучше. На вторые не надо тратить контекст и время.
Ваш, @llm_under_hood 🤗
Forwarded from LLM под капотом
Анализ Exoskeleton - самого умного из быстрых агентов в ECOM1
Это архитектура Ильяса Салихова. Она набрала 71.8 очков с суммарным временем работы агента в 51 минуту и заняла первое место Speed Leaderboard (туда попадают агенты быстрее часа).
На самом деле Ильяс мог выбить результат еще лучше. За время соревнования у него был прогон в 74.7 очков за 42.5 минуты, но вслепую этого заранее нельзя было знать. А еще этот агент прямо сейчас занимает первое место в пост-соревновательном лидерборде ECOM1 LIVE.
Под капотом крутятся gpt-5.4-mini и gpt-5.4-nano. Nano используется для pre-flight проверок и финализации ответа, а mini используется в agent REPL loop. В цикле агент может взаимодействовать через инструменты со средой Agentic OS. При этом основная информация грузится в агента принудительно еще перед стартом через context pre-fetch (еще до pre-flight проверок).
Вообще в этой архитектуре очень много делается принудительно кодом (отсюда и Exoskeleton). Помимо инструментов для взаимодействия со средой задачи очень много тяжелой логики свалено на “domain helpers” (например есть прямо отдельный solver для dispatch задачи), а за сбор grounding references отвечает еще один компонент.
Дополнительно к этому есть отдельный feedback цикл, который отвечает за сбор данных и “обучение” системы (и даже мои любимые heatmaps). Он не работал во время соревнования, но внес вклад в настройку архитектуры перед выходом в PROD.
Вот ссылки: на инсайт, исходники и deep dive.
Ваш, @llm_under_hood 🤗
PS: У Ильяса есть свой канал про AI! А вопросы по архитектуре Exoskeleton можно задать прямо в обсуждениях этого поста - @salikhov_ilyas
Это архитектура Ильяса Салихова. Она набрала 71.8 очков с суммарным временем работы агента в 51 минуту и заняла первое место Speed Leaderboard (туда попадают агенты быстрее часа).
На самом деле Ильяс мог выбить результат еще лучше. За время соревнования у него был прогон в 74.7 очков за 42.5 минуты, но вслепую этого заранее нельзя было знать. А еще этот агент прямо сейчас занимает первое место в пост-соревновательном лидерборде ECOM1 LIVE.
Под капотом крутятся gpt-5.4-mini и gpt-5.4-nano. Nano используется для pre-flight проверок и финализации ответа, а mini используется в agent REPL loop. В цикле агент может взаимодействовать через инструменты со средой Agentic OS. При этом основная информация грузится в агента принудительно еще перед стартом через context pre-fetch (еще до pre-flight проверок).
Вообще в этой архитектуре очень много делается принудительно кодом (отсюда и Exoskeleton). Помимо инструментов для взаимодействия со средой задачи очень много тяжелой логики свалено на “domain helpers” (например есть прямо отдельный solver для dispatch задачи), а за сбор grounding references отвечает еще один компонент.
Дополнительно к этому есть отдельный feedback цикл, который отвечает за сбор данных и “обучение” системы (и даже мои любимые heatmaps). Он не работал во время соревнования, но внес вклад в настройку архитектуры перед выходом в PROD.
Вот ссылки: на инсайт, исходники и deep dive.
Ваш, @llm_under_hood 🤗
PS: У Ильяса есть свой канал про AI! А вопросы по архитектуре Exoskeleton можно задать прямо в обсуждениях этого поста - @salikhov_ilyas
Forwarded from OK ML
Тренажёр по промпт инъекциям от Lakera
😃 Пора пробовать промпт инъекции руками, чтобы как минимум понять, почему они уже несколько лет остаются одной из главных угроз для LLM-приложений.
🧙♂️ Игра бесплатная, от простого игнорирования инструкций до многоуровневых гардрейлов, рекомендую потратить 20–30 минут. Потом и своего агента потестишь!
Заодно можно изучить полезные материалы от Lakera — перспективного стартапа в области AI Security (это я еще мягко высказалась, завидую их росту). Компания занимается защитой GenAI-приложений от prompt injection, jailbreak, утечек данных и других атак на LLM и AI-агентов и тебя научит:
😔 Гайд по Prompt Injection представляет собой разбор основных техник атак и защит.
😔 Visual Prompt Injection о том, как прятать инструкции прямо в изображениях для мультимодальных моделей. Очень интересные примеры.
😔 LLM Security Playbook — хороший обзор угроз и подходов к защите AI-систем.
Все!
Пройдешь Гендальфа - пиши, когда начал пользоваться подсказками!
9️⃣
Заодно можно изучить полезные материалы от Lakera — перспективного стартапа в области AI Security (это я еще мягко высказалась, завидую их росту). Компания занимается защитой GenAI-приложений от prompt injection, jailbreak, утечек данных и других атак на LLM и AI-агентов и тебя научит:
Все!
Пройдешь Гендальфа - пиши, когда начал пользоваться подсказками!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1