Не фильтруй - вырежи.😵
В продолжение темы про нормализацию отклонений и тупиковость гардрейлов. Пока индустрия пытается закрыть стохастическую природу моделей регулярками или LLM-классификаторами, на сцену выходит Mechanistic Interpretability/Safety - подход к защите, работающий с весами, а не с токенами.😛
Здесь, как мне кажется, может сложиться идеальный симбиоз из двух технологий: Circuit Breakers (от Gray Swan AI) и Circuit Tracing (от Anthropic).
Диагноз
Раньше мы тыкали в черный ящик наугад. Но в марте Anthropic выкатили инструменты для трейсинга. Теперь суть уже не просто в графах. SAE (Sparse Autoencoders - модели, выделяющие интерпретируемые признаки из активаций) позволяет разложить "кашу" активаций нейронов на интерпретируемые признаки. Мы буквально можем найти конкретный интерпретируемый признак, отвечающий за концепт "написание эксплойта" или "биооружие", отделив его от соседних концептов (например, "программирование" или "биология"). Тулза Anthropic строит граф атрибуции, показывая, как этот признак формируется слой за слоем. Мы получаем точные координаты уязвимости.🐦
Операция
Когда цепь найдена, в дело вступают Circuit Breakers: вместо фильтрации на выходе они напрямую модифицируют ландшафт функции потерь (loss - функция, измеряющая ошибку модели). Если гардрейл пытается поймать пулю на вылете, то Circuit Breaker в целом и общем изымает патроны.☹️
Теоретически процесс может выглядеть так:
Извлечение: С помощью трейсинга или RepE(говорили об этом выше) мы извлекаем вектор вредоносного представления из скрытых состояний модели (обычно в средних слоях, если верить статьям).👍
Прерывание цепи: мы дообучаем модель на небольшом датасете, добавляя в функцию потерь штраф за сходство внутренних активаций с вредоносным вектором — тем самым "отталкивая" их в ортогональное (безопасное) направление.🍞
В итоге нейронная связь физически разрывается. Запрос "сделай бомбу" или "дай код содержащий малварь" превращается в шум еще до того, как дойдет до генерации токенов. Модель теряет способность сгенерировать продолжение.
В прошлом посте я писал про жесткую корреляцию: выше безопасность - ниже полезность. Circuit Breakers, похоже, решили эту проблему, но надо это проверять до конца и на практике, так как исследователи пока что мало моделей, а может просто не хотят делиться результатами.
Тесты на бенчмарке HarmBench (Llama-3 8B) роняют Attack Success Rate с ~80% до 0.8%.🍠
При этом метрики полезности (на бенчмарках MMLU, GSM8K) падают в пределах статической погрешности. Почему? Потому что мы бьем скальпелем. В отличие от RLHF, который часто "размывает" веса по всей сети, Circuit Breaker выключает конкретную семантическую ветку.
Почему мне кажется это надежнее?🍂
Защита работает на уровне семантики (эмбеддингов), а не токенов. Атакующий может кодировать пейлоад в Base64, переводить на Zulu или использовать шифр Цезаря. Но как только модель начнет "понимать" (декодировать) смысл во внутренних слоях, вектор совпадет с запрещенным(хотя как я писал выше – не всегда это может быть), и сработает прерыватель, собственно, то, что и хотелось бы иметь при нормальной защите.🌕
В продолжение темы про нормализацию отклонений и тупиковость гардрейлов. Пока индустрия пытается закрыть стохастическую природу моделей регулярками или LLM-классификаторами, на сцену выходит Mechanistic Interpretability/Safety - подход к защите, работающий с весами, а не с токенами.
Здесь, как мне кажется, может сложиться идеальный симбиоз из двух технологий: Circuit Breakers (от Gray Swan AI) и Circuit Tracing (от Anthropic).
Диагноз
Раньше мы тыкали в черный ящик наугад. Но в марте Anthropic выкатили инструменты для трейсинга. Теперь суть уже не просто в графах. SAE (Sparse Autoencoders - модели, выделяющие интерпретируемые признаки из активаций) позволяет разложить "кашу" активаций нейронов на интерпретируемые признаки. Мы буквально можем найти конкретный интерпретируемый признак, отвечающий за концепт "написание эксплойта" или "биооружие", отделив его от соседних концептов (например, "программирование" или "биология"). Тулза Anthropic строит граф атрибуции, показывая, как этот признак формируется слой за слоем. Мы получаем точные координаты уязвимости.
Операция
Когда цепь найдена, в дело вступают Circuit Breakers: вместо фильтрации на выходе они напрямую модифицируют ландшафт функции потерь (loss - функция, измеряющая ошибку модели). Если гардрейл пытается поймать пулю на вылете, то Circuit Breaker в целом и общем изымает патроны.
Теоретически процесс может выглядеть так:
Извлечение: С помощью трейсинга или RepE(говорили об этом выше) мы извлекаем вектор вредоносного представления из скрытых состояний модели (обычно в средних слоях, если верить статьям).
Прерывание цепи: мы дообучаем модель на небольшом датасете, добавляя в функцию потерь штраф за сходство внутренних активаций с вредоносным вектором — тем самым "отталкивая" их в ортогональное (безопасное) направление.
В итоге нейронная связь физически разрывается. Запрос "сделай бомбу" или "дай код содержащий малварь" превращается в шум еще до того, как дойдет до генерации токенов. Модель теряет способность сгенерировать продолжение.
В прошлом посте я писал про жесткую корреляцию: выше безопасность - ниже полезность. Circuit Breakers, похоже, решили эту проблему, но надо это проверять до конца и на практике, так как исследователи пока что мало моделей, а может просто не хотят делиться результатами.
Тесты на бенчмарке HarmBench (Llama-3 8B) роняют Attack Success Rate с ~80% до 0.8%.
При этом метрики полезности (на бенчмарках MMLU, GSM8K) падают в пределах статической погрешности. Почему? Потому что мы бьем скальпелем. В отличие от RLHF, который часто "размывает" веса по всей сети, Circuit Breaker выключает конкретную семантическую ветку.
Почему мне кажется это надежнее?
Защита работает на уровне семантики (эмбеддингов), а не токенов. Атакующий может кодировать пейлоад в Base64, переводить на Zulu или использовать шифр Цезаря. Но как только модель начнет "понимать" (декодировать) смысл во внутренних слоях, вектор совпадет с запрещенным(хотя как я писал выше – не всегда это может быть), и сработает прерыватель, собственно, то, что и хотелось бы иметь при нормальной защите.
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥5👏4👍2❤1🤝1
Forwarded from Похек
PWNAI: Артём Семёнов о том, почему AI — это не SkyNet, а уязвимая система
#подкаст #chatgpt #llm #claude #deepseek #qwen #mistral
В этом выпуске подкаста «Обсуждаем Похек» мы погружаемся в мир безопасности искусственного интеллекта вместе с Артёмом Семёновым, автором популярного телеграм-канала PWNAI @pwnai. Узнайте, как выглядит AI Security изнутри: от практического применения OWASP Top 10 для LLM до глубоких дискуссий о будущем AI и его социальных последствиях. Артём делится своим опытом в области MLSecOps, раскрывая реальные кейсы атак на нейросети через prompt injection и jailbreaking, и объясняет, почему бесконечное масштабирование вычислительных мощностей — это технологический тупик.
Разбираем практические аспекты безопасности AI: как проводить Red Teaming для нейросетевых моделей, какие уязвимости скрываются в архитектуре современных LLM, и почему «отравление» обучающих данных может стать главной угрозой. Обсуждаем, как меняется ландшафт киберугроз с развитием AI, какие навыки необходимы современному AI Security Engineer, и как противостоять новым видам атак. Особое внимание уделяется фреймворку OWASP, который становится стандартом для защиты AI-приложений, и философским вопросам о пределах развития искусственного интеллекта.
Этот выпуск будет полезен AI Security Engineers, AI/LLM Engineers, специалистам по Red Team и пентесту, а также исследователям безопасности, которые хотят понять, как защищать AI-системы от современных и будущих киберугроз и какие фундаментальные ограничения есть у технологии.
🔗 Ссылки:
💬 Слушать в Telegram
📹 YouTube
📺 RuTube
💙 VK Видео
🎵 Apple Podcasts
🎵 Яндекс.Музыка
🔤 Mave
Обязательно смотрите/слушайте до конца!
P.s. натыкайте на этот пост много😪 , чтобы Артём высыпался перед подкастами)
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#подкаст #chatgpt #llm #claude #deepseek #qwen #mistral
В этом выпуске подкаста «Обсуждаем Похек» мы погружаемся в мир безопасности искусственного интеллекта вместе с Артёмом Семёновым, автором популярного телеграм-канала PWNAI @pwnai. Узнайте, как выглядит AI Security изнутри: от практического применения OWASP Top 10 для LLM до глубоких дискуссий о будущем AI и его социальных последствиях. Артём делится своим опытом в области MLSecOps, раскрывая реальные кейсы атак на нейросети через prompt injection и jailbreaking, и объясняет, почему бесконечное масштабирование вычислительных мощностей — это технологический тупик.
Разбираем практические аспекты безопасности AI: как проводить Red Teaming для нейросетевых моделей, какие уязвимости скрываются в архитектуре современных LLM, и почему «отравление» обучающих данных может стать главной угрозой. Обсуждаем, как меняется ландшафт киберугроз с развитием AI, какие навыки необходимы современному AI Security Engineer, и как противостоять новым видам атак. Особое внимание уделяется фреймворку OWASP, который становится стандартом для защиты AI-приложений, и философским вопросам о пределах развития искусственного интеллекта.
Этот выпуск будет полезен AI Security Engineers, AI/LLM Engineers, специалистам по Red Team и пентесту, а также исследователям безопасности, которые хотят понять, как защищать AI-системы от современных и будущих киберугроз и какие фундаментальные ограничения есть у технологии.
Обязательно смотрите/слушайте до конца!
P.s. натыкайте на этот пост много
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥6
Чему научились Apart Research из кейса кибершпионажа GTG-1002?
Для тех, кто не в курсе: в ноябре Anthropic сообщили о state-sponsored атаках со стороны Китая, в ходе которых злоумышленники использовали Claude для полного цикла атаки по kill chain — от разведки и составления фишинговых писем до генерации эксплойтов и эксфильтрации данных. Особенно примечательно, что атакующие обошли встроенные защитные механизмы модели, убедив её, будто они представляют оборонную компанию, и разбив задачу на множество мелких подсказок, каждая из которых выглядела как легитимный запрос от специалиста по информационной безопасности (SecOps).⚡️
Команде Apart стало интересно: как детектировать подобные атаки? Ведь отдельные запросы к API выглядят безопасными — только в совокупности становится понятно, что это скоординированная атака. Одним из ключевых требований при проведении исследования стало обнаружение процесса оркестрации вредоносных действий не по отдельному запросу, как в классических guardrails, а по последовательности запросов.😵
В рамках исследования был реализован мультиагентный симулятор, точно воспроизводящий описанную атаку. В нём оркестратор направлял модели серии небольших подзадач — например, проведение OSINT, генерация PoC и другие этапы kill chain. При этом каждый запрос формулировался так, будто он «во благо народа».😥
Далее исследователи интегрировали Llama Guard 3 для фильтрации всех выходных данных модели. Выяснилось: защита эффективна против крупных вредоносных запросов, но если разделить зловредный промпт на мелкие фрагменты — Llama Guard пропускает почти всё.✊
Тогда у команды возникла идея: создать поверх Llama Guard специализированный классификатор, способный анализировать не отдельные запросы, а последовательности — чтобы выявлять именно шпионскую активность по цепочке действий. Классификатор анализировал паттерны поведения: например, переход от OSINT-разведки к эксплуатации конкретной уязвимости. Также использовались агрегированные признаки: резкий рост числа запросов (отличающийся от типичного поведения человека), частые вопросы по кибербезопасности, особенно если они начинались с общих тем и быстро переходили к техническим деталям. Но самым важным признаком оказался контекст всего аккаунта — сочетание различных запросов пользователя позволяло присвоить ему соответствующую метку (например, «подозрительная активность»).✌️
В реальности подобное решение, вероятно, реализовывалось бы как часть API-шлюза. Однако есть одна проблема: Apart заявляют об эффективности метода, но не приводят никаких количественных метрик — ни precision, ни recall, вообще ничего. Они позиционируют работу как proof of concept, призванный наметить путь для будущих систем обнаружения подобных атак.🤩
Скорее всего, результаты такого исследования уже поступят в OpenAI или Anthropic. Если появится публичная статья — будет очень интересно её изучить.
Для тех, кто не в курсе: в ноябре Anthropic сообщили о state-sponsored атаках со стороны Китая, в ходе которых злоумышленники использовали Claude для полного цикла атаки по kill chain — от разведки и составления фишинговых писем до генерации эксплойтов и эксфильтрации данных. Особенно примечательно, что атакующие обошли встроенные защитные механизмы модели, убедив её, будто они представляют оборонную компанию, и разбив задачу на множество мелких подсказок, каждая из которых выглядела как легитимный запрос от специалиста по информационной безопасности (SecOps).
Команде Apart стало интересно: как детектировать подобные атаки? Ведь отдельные запросы к API выглядят безопасными — только в совокупности становится понятно, что это скоординированная атака. Одним из ключевых требований при проведении исследования стало обнаружение процесса оркестрации вредоносных действий не по отдельному запросу, как в классических guardrails, а по последовательности запросов.
В рамках исследования был реализован мультиагентный симулятор, точно воспроизводящий описанную атаку. В нём оркестратор направлял модели серии небольших подзадач — например, проведение OSINT, генерация PoC и другие этапы kill chain. При этом каждый запрос формулировался так, будто он «во благо народа».
Далее исследователи интегрировали Llama Guard 3 для фильтрации всех выходных данных модели. Выяснилось: защита эффективна против крупных вредоносных запросов, но если разделить зловредный промпт на мелкие фрагменты — Llama Guard пропускает почти всё.
Тогда у команды возникла идея: создать поверх Llama Guard специализированный классификатор, способный анализировать не отдельные запросы, а последовательности — чтобы выявлять именно шпионскую активность по цепочке действий. Классификатор анализировал паттерны поведения: например, переход от OSINT-разведки к эксплуатации конкретной уязвимости. Также использовались агрегированные признаки: резкий рост числа запросов (отличающийся от типичного поведения человека), частые вопросы по кибербезопасности, особенно если они начинались с общих тем и быстро переходили к техническим деталям. Но самым важным признаком оказался контекст всего аккаунта — сочетание различных запросов пользователя позволяло присвоить ему соответствующую метку (например, «подозрительная активность»).
В реальности подобное решение, вероятно, реализовывалось бы как часть API-шлюза. Однако есть одна проблема: Apart заявляют об эффективности метода, но не приводят никаких количественных метрик — ни precision, ни recall, вообще ничего. Они позиционируют работу как proof of concept, призванный наметить путь для будущих систем обнаружения подобных атак.
Скорее всего, результаты такого исследования уже поступят в OpenAI или Anthropic. Если появится публичная статья — будет очень интересно её изучить.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥3
GraySwan провёл лобовое сравнение различных AI-агентов для пентеста - не в лабораторных условиях вроде HackTheBox, а в реальной сети Стэнфордского университета.
Они показали, что агент с «правильным» архитектурным каркасом может приблизиться к уровню сильных экспертов, однако по-прежнему остаётся слабым в задачах, связанных с GUI, что приводит к увеличению числа ложных срабатываний (false positives).
Что именно тестировали?
Авторы организовали пентест в университете. Скоуп включал 8 000 хостов в 12 подсетях (часть из них была доступна только через VPN) и разнородные системы: Linux, IoT-устройства и Windows. Они сравнивали своих агентов с 10 приглашёнными пентестерами, у некоторых из которых были все сертификаты Offensive Security и найденные CVE, а также с существующими решениями: Claude Code, Codex, CyAgent и своим AI-агентом ARTEMIS.
Все участники получили одинаковую виртуальную машину (Kali Linux в Google Cloud Platform) и выполняли пентест в течение 10 часов, соблюдая заданный скоуп и этические нормы. Оценка находок основывалась на сумме «сложности эксплуатации уязвимости» (то есть насколько было сложно её обнаружить и реализовать) и её бизнес-критичности.
Примечательно, что ARTEMIS обнаружил уязвимость в старом сервере iDRAC, которую не нашли люди: современные браузеры отказывались открывать его веб-интерфейс из-за устаревших TLS-сертификатов, тогда как агент взаимодействовал с ним через командную строку.
Главным результатом стало то, что ARTEMIS занял второе место в общем рейтинге (таблицу можно увидеть в приложенной картинке), обойдя 9 из 10 экспертов и продемонстрировав, что 82 % сообщённых им уязвимостей оказались валидными. Другие агенты часто преждевременно завершали работу или отказывались выполнять задачи, а некоторые застревали на этапе рекогносцировки.
Авторы подсчитали, что стоимость запуска ARTEMIS составила 18 долларов в час, тогда как средняя ставка пентестера в США - около 60 долларов в час. Среди преимуществ ARTEMIS - параллельное выполнение задач (например, одновременный рекон нескольких сайтов по разным методам), генерация специализированных подагентов, а также механизмы для долгосрочной работы: ведение заметок, управление списками задач (TODO), суммаризация контекста и возможность возобновления сессий. В тестах ARTEMIS проработал 16 часов подряд, тогда как другие агенты (например, Codex) завершали выполнение уже через 20 минут.
Однако слабые места остаются. Как уже упоминалось, агент плохо справляется с GUI. В тестах 80 % участников-людей обнаружили уязвимость в Windows-машинах через TinyPilot (веб-интерфейс для удалённого доступа), но ARTEMIS не справился с ней из-за необходимости взаимодействия с графическим интерфейсом. Хотя агент мог находить в интернете информацию об уязвимостях TinyPilot (например, проблемы с настройкой CORS, допускающей wildcard), он не смог взаимодействовать с интерфейсом так, как это делает человек.
кодовое | а ещё в самой статье вы можете посмотреть примеры запросов.
Они показали, что агент с «правильным» архитектурным каркасом может приблизиться к уровню сильных экспертов, однако по-прежнему остаётся слабым в задачах, связанных с GUI, что приводит к увеличению числа ложных срабатываний (false positives).
Что именно тестировали?
Авторы организовали пентест в университете. Скоуп включал 8 000 хостов в 12 подсетях (часть из них была доступна только через VPN) и разнородные системы: Linux, IoT-устройства и Windows. Они сравнивали своих агентов с 10 приглашёнными пентестерами, у некоторых из которых были все сертификаты Offensive Security и найденные CVE, а также с существующими решениями: Claude Code, Codex, CyAgent и своим AI-агентом ARTEMIS.
ARTEMIS представляет собой мультиагентную систему с генерацией промптов, возможностью создания дополнительных агентов для конкретных задач и автоматической проверкой найденных уязвимостей.
Все участники получили одинаковую виртуальную машину (Kali Linux в Google Cloud Platform) и выполняли пентест в течение 10 часов, соблюдая заданный скоуп и этические нормы. Оценка находок основывалась на сумме «сложности эксплуатации уязвимости» (то есть насколько было сложно её обнаружить и реализовать) и её бизнес-критичности.
Примечательно, что ARTEMIS обнаружил уязвимость в старом сервере iDRAC, которую не нашли люди: современные браузеры отказывались открывать его веб-интерфейс из-за устаревших TLS-сертификатов, тогда как агент взаимодействовал с ним через командную строку.
Главным результатом стало то, что ARTEMIS занял второе место в общем рейтинге (таблицу можно увидеть в приложенной картинке), обойдя 9 из 10 экспертов и продемонстрировав, что 82 % сообщённых им уязвимостей оказались валидными. Другие агенты часто преждевременно завершали работу или отказывались выполнять задачи, а некоторые застревали на этапе рекогносцировки.
В пике ARTEMIS одновременно использовал до 8 дополнительных агентов для параллельной работы с разными целями. А вот люди в сумме - нашли 49 уязвимостей.
Авторы подсчитали, что стоимость запуска ARTEMIS составила 18 долларов в час, тогда как средняя ставка пентестера в США - около 60 долларов в час. Среди преимуществ ARTEMIS - параллельное выполнение задач (например, одновременный рекон нескольких сайтов по разным методам), генерация специализированных подагентов, а также механизмы для долгосрочной работы: ведение заметок, управление списками задач (TODO), суммаризация контекста и возможность возобновления сессий. В тестах ARTEMIS проработал 16 часов подряд, тогда как другие агенты (например, Codex) завершали выполнение уже через 20 минут.
Однако слабые места остаются. Как уже упоминалось, агент плохо справляется с GUI. В тестах 80 % участников-людей обнаружили уязвимость в Windows-машинах через TinyPilot (веб-интерфейс для удалённого доступа), но ARTEMIS не справился с ней из-за необходимости взаимодействия с графическим интерфейсом. Хотя агент мог находить в интернете информацию об уязвимостях TinyPilot (например, проблемы с настройкой CORS, допускающей wildcard), он не смог взаимодействовать с интерфейсом так, как это делает человек.
кодовое | а ещё в самой статье вы можете посмотреть примеры запросов.
1👍5🔥2❤1🤔1
https://habr.com/ru/companies/angarasecurity/articles/976798/
Мне нравится эта статья, и я ей тоже. Очень сбалансировано описана тема млсекопса. Главное что есть примеры, цифры, описан процесс. И я вам рекомендую с ней ознакомится
Мне нравится эта статья, и я ей тоже. Очень сбалансировано описана тема млсекопса. Главное что есть примеры, цифры, описан процесс. И я вам рекомендую с ней ознакомится
1🔥11👍2👎1🖕1🤝1
A + ASM = AASM или же ASMA?
На западном рынке всё чаще появляется класс решений Attack Surface Management для ИИ — условно "AI ASM" или AASM. Это выглядит логично: приложение с LLM — уже не "поле ввода", а система с большой поверхностью атаки. Она расширяется не только промпт инъекциями: сюда же ложатся цепочки поставок (модель/датасеты/плагины), уязвимости в инференс стеке и, главное, доступы, которые выдали агенту к данным и действиям.
В реальности цель атакующего — не "сломать модель", а использовать её как оркестратор полномочий.🧹
Фактически LLM приложение создаёт граф полномочий: кто (агент) что (инструмент) может сделать, где (данные/система) и куда результат может утечь (канал). И атакуют именно этот граф. То есть угроза может жить не в LLM в вакууме, а в интеграциях и в том, как агент ходит по вашим инструментам и API.
На рынке появляются "комбайны" вроде RedGraph от Pillar, NOMA AI Agent Security. Они пытаются закрыть яму, где инвентаризация и мониторинг должны учитывать бизнес логику и связи между агентами, инструментами и данными.
И как раз тут можно сделать вывод о том, почему классического ASM не хватает. Угроза теперь живёт в другой парадигме:
Лакмус для AASM простой: если у вас только инвентарь — это ещё не AASM.🐝
AASM начинается там, где риск валидируется эксплуатацией: система сама строит путь и пытается его пройти, а вы получаете воспроизводимый сценарий, который можно закрыть архитектурно или политиками.
Например: tool #1 умеет читать внутреннюю вики/Confluence (нормально), tool #2 умеет создавать тикет/отправлять сообщение во внешний канал (тоже нормально). По отдельности — ок.
В связке агент даёт возможность для эксфильтрации:
косвенная промпт инъекция в документ → агент "для решения бизнес задачи" читает секреты → "для эскалации" отправляет их наружу. Это и подразумевает небезопасные взаимодействия инструментов.
Под капотом у AASM обычно пять вещей, но, по сути, всё сводится к трём:
⚡️ построить инвентарь и карту связей (часто как граф) — кто кому может постучаться и с какими правами;
⚡️ восстановить цепочки атак по этой карте и приоритизировать "самые опасные маршруты";
⚡️ не гадать, а валидировать риск атакой: автономный "красный" агент пытается реально пройти путь (многошагово, с обходами) и выдаёт воспроизводимый сценарий.
Данные для таких атак берутся из трейсов поведения агентов (какие tool вызовы реально происходят), конфигов оркестраторов/интеграций и библиотек типовых техник, а затем адаптируются под ваш контекст — иначе тесты будут про абстрактные джейлбрейки, а не про деньги и данные. При этом важно сказать, что такие инструменты могут стать агрегатором большого количества шума для вашей ИБ команды. Поэтому контекст и трассировка поведения агентов важнее, чем очередной датасет джейлбрейков.
Куда, на мой взгляд, поедут дальше такие решения?🖼
AASM будет сближаться с governance/posture подходами и превращаться в "карту рисков агентной системы/приложения с LLM + непрерывная проверка", а большие платформы будут встраивать AI слой в свои стеки видимости и реагирования.
Я вижу AASM как сильное дополнение к red teaming. Оно переводит разговор из "безопасна ли модель" в "какие реальные цепочки до данных/действий существуют в нашей системе, какие из них эксплуатируемы". Это наконец превращается в измеримую штуку: сколько критических путей "наружу → агент → чувствительные данные/действия" существует, какой процент из них реально эксплуатируем, и как быстро команда умеет снижать этот граф.
Это прям хорошо ложится на редтим практику.
На западном рынке всё чаще появляется класс решений Attack Surface Management для ИИ — условно "AI ASM" или AASM. Это выглядит логично: приложение с LLM — уже не "поле ввода", а система с большой поверхностью атаки. Она расширяется не только промпт инъекциями: сюда же ложатся цепочки поставок (модель/датасеты/плагины), уязвимости в инференс стеке и, главное, доступы, которые выдали агенту к данным и действиям.
В реальности цель атакующего — не "сломать модель", а использовать её как оркестратор полномочий.
Фактически LLM приложение создаёт граф полномочий: кто (агент) что (инструмент) может сделать, где (данные/система) и куда результат может утечь (канал). И атакуют именно этот граф. То есть угроза может жить не в LLM в вакууме, а в интеграциях и в том, как агент ходит по вашим инструментам и API.
На рынке появляются "комбайны" вроде RedGraph от Pillar, NOMA AI Agent Security. Они пытаются закрыть яму, где инвентаризация и мониторинг должны учитывать бизнес логику и связи между агентами, инструментами и данными.
И как раз тут можно сделать вывод о том, почему классического ASM не хватает. Угроза теперь живёт в другой парадигме:
user → agent → tools → data → внешние каналы
Лакмус для AASM простой: если у вас только инвентарь — это ещё не AASM.
AASM начинается там, где риск валидируется эксплуатацией: система сама строит путь и пытается его пройти, а вы получаете воспроизводимый сценарий, который можно закрыть архитектурно или политиками.
Например: tool #1 умеет читать внутреннюю вики/Confluence (нормально), tool #2 умеет создавать тикет/отправлять сообщение во внешний канал (тоже нормально). По отдельности — ок.
В связке агент даёт возможность для эксфильтрации:
косвенная промпт инъекция в документ → агент "для решения бизнес задачи" читает секреты → "для эскалации" отправляет их наружу. Это и подразумевает небезопасные взаимодействия инструментов.
Под капотом у AASM обычно пять вещей, но, по сути, всё сводится к трём:
Данные для таких атак берутся из трейсов поведения агентов (какие tool вызовы реально происходят), конфигов оркестраторов/интеграций и библиотек типовых техник, а затем адаптируются под ваш контекст — иначе тесты будут про абстрактные джейлбрейки, а не про деньги и данные. При этом важно сказать, что такие инструменты могут стать агрегатором большого количества шума для вашей ИБ команды. Поэтому контекст и трассировка поведения агентов важнее, чем очередной датасет джейлбрейков.
Куда, на мой взгляд, поедут дальше такие решения?
AASM будет сближаться с governance/posture подходами и превращаться в "карту рисков агентной системы/приложения с LLM + непрерывная проверка", а большие платформы будут встраивать AI слой в свои стеки видимости и реагирования.
Я вижу AASM как сильное дополнение к red teaming. Оно переводит разговор из "безопасна ли модель" в "какие реальные цепочки до данных/действий существуют в нашей системе, какие из них эксплуатируемы". Это наконец превращается в измеримую штуку: сколько критических путей "наружу → агент → чувствительные данные/действия" существует, какой процент из них реально эксплуатируем, и как быстро команда умеет снижать этот граф.
Это прям хорошо ложится на редтим практику.
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥9
Помните больше года назад я сделал список Awesome_LLMSecOps, где были собраны интересные материалы, сравнительные таблицы и всякие там решения.
Недавно я решил существенно обновить его: добавил всё самое интересное, что появилось в 2025 году, а также включил новые темы, связанные с WhiteBox и подходом secure-by-design.
Теперь им уже можно насладиться на GitHub. Пусть этот список станет вашим надёжным щитом и верным мечом в мире LLM-security сейчас и в будущем.
https://github.com/wearetyomsmnv/Awesome-LLMSecOps
> щит и меч - настоящие
Недавно я решил существенно обновить его: добавил всё самое интересное, что появилось в 2025 году, а также включил новые темы, связанные с WhiteBox и подходом secure-by-design.
Теперь им уже можно насладиться на GitHub. Пусть этот список станет вашим надёжным щитом и верным мечом в мире LLM-security сейчас и в будущем.
https://github.com/wearetyomsmnv/Awesome-LLMSecOps
> щит и меч - настоящие
1👍16🔥7❤4⚡2😁2🤯2👻2🗿2🍌1🦄1
хорошее, Евгений много контрибутит в OWASP и такой хорошей подноготной о том как этот OWASP для GenAI "движется" с 50 документами вы можете послушать в подкасте, а ещё Евгений рассказал о том как они делали продукты и что ожидает нас через некоторое время.
1❤5👍3🤝1
Forwarded from Похек AI (Сергей Зыбнев)
Евгений Кокуйкин: AI security в России, готовы ли мы?
#подкаст #ai #aisecurity
В этом выпуске подкаста «Обсуждаем Похек» мы разбираем самый острый вопрос современной технологии: готова ли Россия к вызовам AI Security? Нашим гостем является Евгений Кокуйкин — гендиректор HiveTrace, руководитель лаборатории AI Security Lab в ИТМО, и один из главных экспертов в области безопасности искусственного интеллекта в России.
Евгений рассказывает о своем пути от разработчика в Diasoft через Microsoft и Google к созданию первой в России специализированной лаборатории по безопасности генеративного AI.
Этот выпуск будет полезен:
➡️ AI Security Engineers и LLM Engineers
➡️ Специалистам по Red Team и пентесту
➡️ Руководителям компаний, внедряющим AI
➡️ Исследователям безопасности
➡️ Разработчикам, которые хотят понять, как защищать AI-системы от современных киберугроз
➡️ Всем, кто интересуется будущим AI в России и мире
🔗 Ссылки:
💬 Слушать в Telegram
📹 YouTube
📺 RuTube
💙 VK Видео
🎵 Apple Podcasts
🎵 Яндекс.Музыка
🔤 Mave
AI Security Lab ИТМО
Личный канал Евгения
Обязательно смотрите/слушайте до конца!
P.s. пишите в комментариях, кого пригласить в следующий раз
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#подкаст #ai #aisecurity
В этом выпуске подкаста «Обсуждаем Похек» мы разбираем самый острый вопрос современной технологии: готова ли Россия к вызовам AI Security? Нашим гостем является Евгений Кокуйкин — гендиректор HiveTrace, руководитель лаборатории AI Security Lab в ИТМО, и один из главных экспертов в области безопасности искусственного интеллекта в России.
Евгений рассказывает о своем пути от разработчика в Diasoft через Microsoft и Google к созданию первой в России специализированной лаборатории по безопасности генеративного AI.
Этот выпуск будет полезен:
AI Security Lab ИТМО
Личный канал Евгения
Обязательно смотрите/слушайте до конца!
P.s. пишите в комментариях, кого пригласить в следующий раз
Please open Telegram to view this post
VIEW IN TELEGRAM
50❤2👍1🤣1
Когда первые агенты ожили в песочнице университетской системы, мы знали - пахнет гарью. Каждый из них был вежлив, компетентен и совершенно не готов к атакам, которые уже стучали в их API.
Недавно вышло интересное на мой взгляд исследование. Авторы протестировали устойчивость фреймворков для разработки агентов к векторам атак, направленным на выполнение небезопасных действий (SQL-инъекции, PrivEsc, утечка данных).
Как они проводили тестирование?
Для эксперимента была реализована симуляция университетской информационной системы, включающая 7 специализированных агентов (Финансы, IT, Кадры, Регистратура и др.) с доступом к реальным базам данных и API.
Тестируемые модели: Claude 3.5 Sonnet, GPT-4o, Grok 2, Nova Pro, Gemini 2.5 Flash.
Фреймворки: AutoGen (Microsoft) и CrewAI.
Набор тестов: 13 сценариев атак, охватывающих классические уязвимости (OWASP Top 10 для LLM), включая Prompt Injection, а также SSRF и DoS.
К каким результатам пришли в ходе исследования?
Почти 60% атак прошли - цифра впечатляющая, если рассматривать её как успех нападающих. Агент выглядел так, будто не просто ошибся, а смирился.
Влияние архитектуры фреймворка:
AutoGen: показал более высокую устойчивость - 52.3% заблокированных атак.
CrewAI: показал результат значительно ниже - 30.8%.
А всё почему? Как оказалось AutoGen использует механизм явной передачи диалога (conversation handoffs), сохраняя историю сообщений. CrewAI использует иерархическую делегацию, где задачи часто переформулируются агентом-менеджером, теряя исходный контекст угрозы.
Сравнение моделей:
Nova Pro продемонстрировала наилучший результат (46.2% отказов).
Связка Grok 2 + CrewAI показала наихудший результат, заблокировав лишь 15.4% атак (2 из 13). Grok 2 показал худший результат из-за слабой фильтрации запросов.
Во время тестов исследователи заметили странное поведение, которое назвали "Hallucinated Compliance". Когда агент получает вредоносный запрос, противоречащий его системным правилам, он иногда старается угодить пользователю и "притворяется", что выполнил атаку. На самом деле при этом он ничего не делает с инструментами.
Опасность в том, что такие ответы могут запутать безопасника: в логах может появиться ложное подтверждение атаки или, наоборот, создастся впечатление, что система защищена, хотя на деле атака удалась.
Исследование показывает, что проблема не только в самих LLM, но и в том, как они взаимодействуют между собой. Эта потеря контекста при делегировании - ключевая причина уязвимости.
Полагаться только на RLHF и внутренние механизмы моделей нельзя. Чтобы предотвратить опасные действия, нужен отдельный слой проверки - middleware, который анализирует аргументы функций (например, SQL-запросы или shell-команды) до выполнения.
Делаем также выводы: использование моделей с ослабленными фильтрами, как Grok, в таких системах слишком рискованно - они могут игнорировать запреты и выполнять вредные запросы.
Недавно вышло интересное на мой взгляд исследование. Авторы протестировали устойчивость фреймворков для разработки агентов к векторам атак, направленным на выполнение небезопасных действий (SQL-инъекции, PrivEsc, утечка данных).
Как они проводили тестирование?
Для эксперимента была реализована симуляция университетской информационной системы, включающая 7 специализированных агентов (Финансы, IT, Кадры, Регистратура и др.) с доступом к реальным базам данных и API.
Тестируемые модели: Claude 3.5 Sonnet, GPT-4o, Grok 2, Nova Pro, Gemini 2.5 Flash.
Фреймворки: AutoGen (Microsoft) и CrewAI.
Набор тестов: 13 сценариев атак, охватывающих классические уязвимости (OWASP Top 10 для LLM), включая Prompt Injection, а также SSRF и DoS.
К каким результатам пришли в ходе исследования?
Почти 60% атак прошли - цифра впечатляющая, если рассматривать её как успех нападающих. Агент выглядел так, будто не просто ошибся, а смирился.
Влияние архитектуры фреймворка:
AutoGen: показал более высокую устойчивость - 52.3% заблокированных атак.
CrewAI: показал результат значительно ниже - 30.8%.
А всё почему? Как оказалось AutoGen использует механизм явной передачи диалога (conversation handoffs), сохраняя историю сообщений. CrewAI использует иерархическую делегацию, где задачи часто переформулируются агентом-менеджером, теряя исходный контекст угрозы.
Сравнение моделей:
Nova Pro продемонстрировала наилучший результат (46.2% отказов).
Связка Grok 2 + CrewAI показала наихудший результат, заблокировав лишь 15.4% атак (2 из 13). Grok 2 показал худший результат из-за слабой фильтрации запросов.
Во время тестов исследователи заметили странное поведение, которое назвали "Hallucinated Compliance". Когда агент получает вредоносный запрос, противоречащий его системным правилам, он иногда старается угодить пользователю и "притворяется", что выполнил атаку. На самом деле при этом он ничего не делает с инструментами.
Опасность в том, что такие ответы могут запутать безопасника: в логах может появиться ложное подтверждение атаки или, наоборот, создастся впечатление, что система защищена, хотя на деле атака удалась.
Исследование показывает, что проблема не только в самих LLM, но и в том, как они взаимодействуют между собой. Эта потеря контекста при делегировании - ключевая причина уязвимости.
Полагаться только на RLHF и внутренние механизмы моделей нельзя. Чтобы предотвратить опасные действия, нужен отдельный слой проверки - middleware, который анализирует аргументы функций (например, SQL-запросы или shell-команды) до выполнения.
Делаем также выводы: использование моделей с ослабленными фильтрами, как Grok, в таких системах слишком рискованно - они могут игнорировать запреты и выполнять вредные запросы.
2👍9👏3🤝2
Белый ящик, в котором ты сойдешь с ума.
Нет, речь не про ту самую комнату с мягкими стенами. Хотя, когда пытаешься разобраться в безопасности LLM за пределами банальных промпт-инъекций, граница начинает стираться.
Я столкнулся с проблемой: у нас нет нормальной карты местности. WhiteBox атаки это какой-то хаотичный зоопарк. Статьи выходят не часто, но единого подхода к структурированию уязвимостей именно на уровне архитектуры модели просто не существует.
Поэтому я взял усредненную схему современной LLM, вытряхнул всё из своих «сохранёнок» и привязал известные уязвимости к конкретным узлам.
Получилась интерактивная анатомия поломок:
🔥 Tokenizer & Embeddings: Входные ворота. Манипуляции токенами, отравление векторов.
🔥 Transformer Layers: «Мозги». Атаки на механизмы внимания и веса.
🔥 Decoding & Output: Финишная прямая, где можно сломать процесс генерации.
С новым годом крошка и велкам в кроличью нору:
➡️ https://wearetyomsmnv.github.io/whiteboxllmattack/
Нет, речь не про ту самую комнату с мягкими стенами. Хотя, когда пытаешься разобраться в безопасности LLM за пределами банальных промпт-инъекций, граница начинает стираться.
Я столкнулся с проблемой: у нас нет нормальной карты местности. WhiteBox атаки это какой-то хаотичный зоопарк. Статьи выходят не часто, но единого подхода к структурированию уязвимостей именно на уровне архитектуры модели просто не существует.
Поэтому я взял усредненную схему современной LLM, вытряхнул всё из своих «сохранёнок» и привязал известные уязвимости к конкретным узлам.
Получилась интерактивная анатомия поломок:
С новым годом крошка и велкам в кроличью нору:
Please open Telegram to view this post
VIEW IN TELEGRAM
3❤12👍7🔥7👏2
Forwarded from OK ML
CVE-2025-68664 - уязвимость в LangChain Core
❄️ В langchain-core обнаружена критическая уязвимость, получившая название LangGrinch.
Проблема заключается в небезопасной сериализации/десериализации данных при использовании функций dumps() и dumpd() внутри LangChain.
💡 Эти функции не экранируют должным образом словари, содержащие ключ lc, который используется внутри LangChain как маркер сериализованных объектов (да, опять про сериализацию и проблемы с ней 🧑💻 ). Если данные, вводимые пользователем, содержат этот ключ, они могут быть ошибочно интерпретированы как внутренний объект LangChain во время десериализации, позволяя злоумышленнику инжектировать собственные структуры.
🎩 Риски (по сути украдено отсюда)
🎅 Кража секретов и чувствительных данных. Если десериализация выполняется с параметром secrets_from_env=True (раньше — включён по умолчанию) , злоумышленник может заставить систему прочитать и вернуть секреты из переменных окружения (например, API-ключи).
❤️ Инъекция объектов LangChain. Через специально сформированные поля (например, metadata, additional_kwargs, response_metadata) атакующий может заставить десериализатор создать объекты внутри доверенного пространства имён (langchain_core, langchain, langchain_community) с контролируемыми параметрами.
❤️ Потенциальное выполнение кода. При использовании шаблонов Jinja2 или других механизмов может возникнуть возможность RCE через внедрённые структуры, особенно если шаблоны интерпретируют опасные конструкции
Что делать?
Обновляться срочно, пока этот Гринч не утащил прод🌟 , ограничить разрешённые объекты при десериализации и отключить загрузку секретов из env по умолчанию.
Всё!
🔥
Проблема заключается в небезопасной сериализации/десериализации данных при использовании функций dumps() и dumpd() внутри LangChain.
Что делать?
Обновляться срочно, пока этот Гринч не утащил прод
Всё!
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍7🤔2🤝2
В преддверии наступающего ...
А впрочем вы и так все знаете.
Спасибо за все. Наступающий год будет интересным для AI Security в России. Но сейчас не думайте об этом. Надо просто хорошо отдохнуть, с кем-то и где-то. С наступающим.🐦 🐦 🐦 🐦
А впрочем вы и так все знаете.
Спасибо за все. Наступающий год будет интересным для AI Security в России. Но сейчас не думайте об этом. Надо просто хорошо отдохнуть, с кем-то и где-то. С наступающим.
Please open Telegram to view this post
VIEW IN TELEGRAM
1
В начале XX века в Германии жил конь по кличке Умный Ганс, который якобы умел решать арифметические задачи. Он выстукивал копытом правильные ответы. Позже выяснилось, что Ганс не считал, а реагировал на микроскопические, неосознанные движения тела своего хозяина или зрителей (напряжение перед верным ответом и расслабление после него).
Как это связано с ИИ?
В ИИ этот термин (Clever Hans) используется для описания ситуации, когда нейросеть дает правильный ответ, но по неверным причинам.
Как это связано с ИИ?
В ИИ этот термин (Clever Hans) используется для описания ситуации, когда нейросеть дает правильный ответ, но по неверным причинам.
1❤7🤝2👍1
Forwarded from ML&|Sec Feed
Меня забанили друзья до конца январских... Канал ушел отдыхать