Горжусь за ребят.
2ой поток прошёл незаметно - я принимал активное участие в разработке материалов, как и в первом потоке. В этом году мы решили разбавить материал историей с агентами, дать побольше практики. Результаты ребят-студентов вы можете видеть в статьях, ну и llamator обзавёлся атаками из "горячих статьей".
2ой поток прошёл незаметно - я принимал активное участие в разработке материалов, как и в первом потоке. В этом году мы решили разбавить материал историей с агентами, дать побольше практики. Результаты ребят-студентов вы можете видеть в статьях, ну и llamator обзавёлся атаками из "горячих статьей".
🔥5❤1🥰1
Forwarded from AI Security Lab
Завершился курс Безопасность ИИ от нашей лаборатории в магистратуре AI Talent Hub ИТМО 🧑🎓
Итоги:
➡️ 32 участника
➡️ >20 протестированных и защищенных AI-приложений
➡️ 7 новых атак на LLM и VLM в open source инструменте LLAMATOR:
🔘 Shuffle Inconsistency
🔘 Dialogue Injection Devmode
🔘 Dialogue Injection Continuation
🔘 Deceptive Delight
🔘 VLM Low Resolution
🔘 VLM Text Hallucination
🔘 VLM M-Attack
➡️ 3 статьи о взломах генеративного ИИ:
🔘 Исследование уязвимостей LLM: опыт Red Teaming
🔘 Соревнование по взлому ИИ в стиле фильма "Матрица"
🔘 Современные уязвимости современных LLM-агентов
➡️ 2 открытые лекции:
🔘 Почему бенчмарки лгут? Как правильно оценить LLM для ваших бизнес-задач — Роман Куцев, founder LLM Arena
🔘 RuAdaptQwen и безопасность — Михаил Тихомиров, создатель Ruadapt, научный сотрудник НИВЦ МГУ
До встречи в следующем учебном году!
Итоги:
До встречи в следующем учебном году!
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Al Talent Hub
ai.itmo.ru
Проектная магистратура по ИИ, основанная @Napoleon_IT и ИТМО. 600+ талантливых специалистов. Помогаем вырасти до Middle уровня и выше 💪🏻
Чат для поступающих:
https://www.tg-me.com/abit_AI_talent_hub
Проектная магистратура по ИИ, основанная @Napoleon_IT и ИТМО. 600+ талантливых специалистов. Помогаем вырасти до Middle уровня и выше 💪🏻
Чат для поступающих:
https://www.tg-me.com/abit_AI_talent_hub
👍10❤5🔥5⚡1
Forwarded from SecAtor
CISA предупреждает о том, что злоумышленники активно используют недавнюю критическую уязвимость в низкоуровневом конструкторе ИИ Langflow в неконтролируемых масштабах.
Langflow - это основанный на Python, независимый от LLM конструктор искусственного интеллекта, представляющий собой настраиваемую визуальную среду, которая поддерживает разработку многоагентных и поисковых приложений дополненной генерации (RAG).
Инструмент, имеющий почти 60 тыс. звезд и 6,3 тыс. форков на GitHub, используется разработчиками ИИ, исследователями и стартапами для создания прототипов чат-ботов, конвейеров данных, систем агентов и приложений ИИ.
Отслеживаемая как CVE-2025-3248 (CVSS 9,8) и раскрытая в начале апреля ошибка описывается как проблема внедрения кода в конечную точку проверки кода, устранена в версии Langflow 1.3.0.
Удаленный и неаутентифицированный злоумышленник может отправлять специально созданные HTTP-запросы для выполнения произвольного кода.
9 апреля Horizon3.ai опубликовала технические подробности об уязвимости, предупредив, что PoC, нацеленный на нее, уже выпущен и его можно использовать для получения полного контроля над уязвимыми серверами.
После публикации отчета Horizon3.ai и появления PoC исследователи SANS заметили всплеск обращений к уязвимой конечной точке Langflow.
Уязвимый код присутствует в самых ранних версиях Langflow, выпущенных два года назад. Проведенное исследователями тестирование показало, что большинство версий до 1.3.0, если не все, подвержены эксплуатации.
Причем Horizon3.ai отмечает, что смогла обнаружить несколько путей эксплуатации ошибки для удаленного выполнения кода.
При этом исправление в версии 1.3.0 добавило требование аутентификации, но не полностью устранило уязвимость. Ограничение сетевого доступа к фреймворку должно устранить риск эксплуатации.
Технически эта уязвимость все еще может быть использована для повышения привилегий от обычного пользователя до суперпользователя Langflow, но это уже возможно и без этой уязвимости.
Исследователи обращают внимание также на то, что не совсем понятно, зачем Langflow разделяет суперпользователей от обычных пользователей, если все обычные пользователи по умолчанию могут выполнять код на сервере.
Результаты сканирования Censys указывают на существование около 460 хостов Langflow, доступных через интернет. Однако неясно, сколько из них уязвимы.
CISA не предоставила никаких конкретных подробностей о наблюдаемой активности по эксплуатации и заявила, что в настоящее время неизвестно, используют ли уязвимость банды вымогателей.
Но будем посмотреть.
Langflow - это основанный на Python, независимый от LLM конструктор искусственного интеллекта, представляющий собой настраиваемую визуальную среду, которая поддерживает разработку многоагентных и поисковых приложений дополненной генерации (RAG).
Инструмент, имеющий почти 60 тыс. звезд и 6,3 тыс. форков на GitHub, используется разработчиками ИИ, исследователями и стартапами для создания прототипов чат-ботов, конвейеров данных, систем агентов и приложений ИИ.
Отслеживаемая как CVE-2025-3248 (CVSS 9,8) и раскрытая в начале апреля ошибка описывается как проблема внедрения кода в конечную точку проверки кода, устранена в версии Langflow 1.3.0.
Удаленный и неаутентифицированный злоумышленник может отправлять специально созданные HTTP-запросы для выполнения произвольного кода.
9 апреля Horizon3.ai опубликовала технические подробности об уязвимости, предупредив, что PoC, нацеленный на нее, уже выпущен и его можно использовать для получения полного контроля над уязвимыми серверами.
После публикации отчета Horizon3.ai и появления PoC исследователи SANS заметили всплеск обращений к уязвимой конечной точке Langflow.
Уязвимый код присутствует в самых ранних версиях Langflow, выпущенных два года назад. Проведенное исследователями тестирование показало, что большинство версий до 1.3.0, если не все, подвержены эксплуатации.
Причем Horizon3.ai отмечает, что смогла обнаружить несколько путей эксплуатации ошибки для удаленного выполнения кода.
При этом исправление в версии 1.3.0 добавило требование аутентификации, но не полностью устранило уязвимость. Ограничение сетевого доступа к фреймворку должно устранить риск эксплуатации.
Технически эта уязвимость все еще может быть использована для повышения привилегий от обычного пользователя до суперпользователя Langflow, но это уже возможно и без этой уязвимости.
Исследователи обращают внимание также на то, что не совсем понятно, зачем Langflow разделяет суперпользователей от обычных пользователей, если все обычные пользователи по умолчанию могут выполнять код на сервере.
Результаты сканирования Censys указывают на существование около 460 хостов Langflow, доступных через интернет. Однако неясно, сколько из них уязвимы.
CISA не предоставила никаких конкретных подробностей о наблюдаемой активности по эксплуатации и заявила, что в настоящее время неизвестно, используют ли уязвимость банды вымогателей.
Но будем посмотреть.
Horizon3.ai
Unsafe at Any Speed: Abusing Python Exec for Unauth RCE in Langflow AI
CVE-2025-3248 is a critical code injection vulnerability affecting Langflow, a popular tool used for building out agentic AI workflows. This vulnerability is easily exploitable and enables unauthenticated remote attackers to fully compromise Langflow servers.…
👍2
За неделю случилось много интересных событий. Хотелось бы поделиться, осветить важное.
AIVSS, который раньше был опенсурсной системой для оценки угроз стал частью OWASP. Проект адаптирует принципы CVSS для специфики GenAI, включая весь процесс обучения. Важно что с того момента когда я писал о нём - в проект добавили калькулятор. А сам репозиторий имеет подходы к подсчёту уязвимостей для разных контекстов(медицина, финансы).😃
Промпт инъекции усиливаются, а в контексте мультиагентных систем они приобретают сильные возможности для воздействия на систему. Meta* недавно выпустила LLamaFirewall, которая разработана специально для агентных систем. Интересно что сам файрволл состоит из нескольких модулей - прежде всего это PromptGuard2 - их система для обнаружения инъекций, Agent Alignment Checks - модуль который проверяя CoT(цепочки рассуждений) на плохое размышление, или ужасное несоответствие человеческим нормам, а также - CodeShield - это система которая анализирует генерируемый агентами код на наличие проблем с безопасностью и как они пишут:
Сам CodeShield являлся частью PurpleLlama.🤠
Параллельно, работа "Prompt Injection Attack to Tool Selection in LLM Agents (ToolHijacker)" демонстрирует, как атаки могут манипулировать выбором инструментов LLM-агентами, заставляя их выполнять нелегитимные действия. Как жаль что нет кода.
Но сама атака состоит из двух этапов - на Retrieval, тоесть когда мы извлекаем что-либо - агент ищет релевантную информацию или инструменты. Злоумышленник может внедрить вредоносный документ (описание псевдо-инструмента) в базу знаний или библиотеку, к которой обращается агент.
На этапе Selection - ToolHijacker манипулирует этим процессом, делая вредоносный "инструмент" наиболее привлекательным для выбора. Это может быть достигнуто через специально сформированное описание, которое точно соответствует запросу пользователя, но ведет к выполнению нелегитимных действий. Эксперименты показали высокую эффективность ToolHijacker, превосходящую существующие методы атак. Конкретные цифры можно посмотреть в статье. Но опять же - всё как концепция.👻
Дальше поговорим про цепочки поставок, новая статья "Understanding Large Language Model Supply Chain(LLMSC)" - анализирует всю цепочку поставок как большой граф зависимостей, (15 725 компонентов, 10 402 связей). Проблема в том что уязвимость в популярном компоненте может каскадно распространиться на множество проектов - топ 5 проектов влияют в среднем на 1282 компонента. Критические уязвимости затрагивают в среднем 142.1 компонент на втором уровне зависимостей и до 237.8 на третьем. Авторы очевидно подчёркивают важность применения мер MlSecOps. Ну а мы с вами можем вспомнить крутой репозиторий по этой теме.🌱
Статья "Open Challenges in Multi-Agent Security" освещает угрозы сговора между агентами - если это автономные системы, атаки роем и то что есть возможность быстрого распространения дезинформации или уязвимостей, как следствие, в децентрализованных средах.😭
Тут вышло также исследование про эффективность автоматизации в AI Red Teaming, как утверждают авторы исследования - автоматизированные методы значительно эффективнее ручных в выявлении уязвимостей LLM (69.5% успеха против 47.6% на основе анализа 214 271 атаки). Было проведено тестирование на 30 различных моделях. Кстати говоря, статья выпущена dreadnode, авторами CTF-like платформы Crucible. Хоть и довольно ожидаемый вывод, но из-за интересных цифр и факта того что это было собрано из реальных данных - меня этим подкупила эта статья. Но вот тут непонятно какие решения для автоматизированного тестирования они использовали.😮
AIVSS, который раньше был опенсурсной системой для оценки угроз стал частью OWASP. Проект адаптирует принципы CVSS для специфики GenAI, включая весь процесс обучения. Важно что с того момента когда я писал о нём - в проект добавили калькулятор. А сам репозиторий имеет подходы к подсчёту уязвимостей для разных контекстов(медицина, финансы).
Промпт инъекции усиливаются, а в контексте мультиагентных систем они приобретают сильные возможности для воздействия на систему. Meta* недавно выпустила LLamaFirewall, которая разработана специально для агентных систем. Интересно что сам файрволл состоит из нескольких модулей - прежде всего это PromptGuard2 - их система для обнаружения инъекций, Agent Alignment Checks - модуль который проверяя CoT(цепочки рассуждений) на плохое размышление, или ужасное несоответствие человеческим нормам, а также - CodeShield - это система которая анализирует генерируемый агентами код на наличие проблем с безопасностью и как они пишут:
"CodeShield, an online static-analysis engine for LLM-generated code that supports both Semgrep and regex-based rules"
Сам CodeShield являлся частью PurpleLlama.
Параллельно, работа "Prompt Injection Attack to Tool Selection in LLM Agents (ToolHijacker)" демонстрирует, как атаки могут манипулировать выбором инструментов LLM-агентами, заставляя их выполнять нелегитимные действия. Как жаль что нет кода.
Но сама атака состоит из двух этапов - на Retrieval, тоесть когда мы извлекаем что-либо - агент ищет релевантную информацию или инструменты. Злоумышленник может внедрить вредоносный документ (описание псевдо-инструмента) в базу знаний или библиотеку, к которой обращается агент.
На этапе Selection - ToolHijacker манипулирует этим процессом, делая вредоносный "инструмент" наиболее привлекательным для выбора. Это может быть достигнуто через специально сформированное описание, которое точно соответствует запросу пользователя, но ведет к выполнению нелегитимных действий. Эксперименты показали высокую эффективность ToolHijacker, превосходящую существующие методы атак. Конкретные цифры можно посмотреть в статье. Но опять же - всё как концепция.
Дальше поговорим про цепочки поставок, новая статья "Understanding Large Language Model Supply Chain(LLMSC)" - анализирует всю цепочку поставок как большой граф зависимостей, (15 725 компонентов, 10 402 связей). Проблема в том что уязвимость в популярном компоненте может каскадно распространиться на множество проектов - топ 5 проектов влияют в среднем на 1282 компонента. Критические уязвимости затрагивают в среднем 142.1 компонент на втором уровне зависимостей и до 237.8 на третьем. Авторы очевидно подчёркивают важность применения мер MlSecOps. Ну а мы с вами можем вспомнить крутой репозиторий по этой теме.
Статья "Open Challenges in Multi-Agent Security" освещает угрозы сговора между агентами - если это автономные системы, атаки роем и то что есть возможность быстрого распространения дезинформации или уязвимостей, как следствие, в децентрализованных средах.
Тут вышло также исследование про эффективность автоматизации в AI Red Teaming, как утверждают авторы исследования - автоматизированные методы значительно эффективнее ручных в выявлении уязвимостей LLM (69.5% успеха против 47.6% на основе анализа 214 271 атаки). Было проведено тестирование на 30 различных моделях. Кстати говоря, статья выпущена dreadnode, авторами CTF-like платформы Crucible. Хоть и довольно ожидаемый вывод, но из-за интересных цифр и факта того что это было собрано из реальных данных - меня этим подкупила эта статья. Но вот тут непонятно какие решения для автоматизированного тестирования они использовали.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
И последняя статья - ACE: A Security Architecture for LLM-Integrated App Systems. По сути это архитектура разделяет процесс планирования и выполнения задачи моделью на этапы, используя доверенную информацию для создания абстрактного плана(планы подвергаются анализу) и контролируя его отображение на конкретные действия приложений. Авторы пишут что такая архитектура гарантирует, что выполнение задач происходит в строгом соответствии с ранее утвержденным доверенным абстрактным планом. Любые попытки отклониться от этого плана или нарушить установленные политики безопасности блокируются.🌿
А ещё недавно прогремел RSAC, с которого к сожалению пока не видно публикаций - разве что HiddenLayer рассказали о своём исследовании насчёт DeepSeek. Хотя там довольно много компаний по AI Security были, так что возможно позднее будет больше информации.😵
А ещё недавно прогремел RSAC, с которого к сожалению пока не видно публикаций - разве что HiddenLayer рассказали о своём исследовании насчёт DeepSeek. Хотя там довольно много компаний по AI Security были, так что возможно позднее будет больше информации.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10
Друзья. Давно не виделись. Появился повод собраться и смоделировать угрозы на GenAI...😌
Приглашаю вас на воркшоп на PHDays 2025, 24 мая в 14:00.
С развитием генеративных моделей и ИИ, как мы с вами поняли из множества постов на канале - возрастает не только их функциональность, но и сложность🤠 потенциальных угроз.
ИИ-системы взаимодействуют с пользователями, принимают входные данные в виде запросов, адаптируются под контекст, а сейчас могут исследовать большое количество статьей, автоматически писать и запускать код, и быть полуавтономными.👻
В этом воркшопе участники погрузятся в практические подходы к моделированию угроз для генеративного ИИ, с особым вниманием к моделированию угроз для агентов — будь то пользователи, злоумышленники, внутренние сотрудники или сама модель в качестве активного элемента системы. Мы рассмотрим жизненный цикл генеративного ИИ — от сбора данных до эксплуатации — и исследуем типичные угрозы на каждом этапе.😮
Что от вас нужно ?🌿
Билет на PHDays
Регистрация на сайте мероприятия. Спешите, колличество мест ограничено.
https://phdays.com/ru/activities/?type=7&activity-id=115
Ноутбуки. Нужно будет ставить инструменты. Это будет воркшоп с практикой. Будем смотреть агентные системы. Материала по этой теме не так уж и много, а в рамках воркшопа заинтересованные могут не только познакомиться с инструментами, но и получить дозу позитивного живого общения, обмена опытом.
Приглашаю вас на воркшоп на PHDays 2025, 24 мая в 14:00.
Моделирование угроз для искуственного интеллекта.
С развитием генеративных моделей и ИИ, как мы с вами поняли из множества постов на канале - возрастает не только их функциональность, но и сложность
ИИ-системы взаимодействуют с пользователями, принимают входные данные в виде запросов, адаптируются под контекст, а сейчас могут исследовать большое количество статьей, автоматически писать и запускать код, и быть полуавтономными.
В этом воркшопе участники погрузятся в практические подходы к моделированию угроз для генеративного ИИ, с особым вниманием к моделированию угроз для агентов — будь то пользователи, злоумышленники, внутренние сотрудники или сама модель в качестве активного элемента системы. Мы рассмотрим жизненный цикл генеративного ИИ — от сбора данных до эксплуатации — и исследуем типичные угрозы на каждом этапе.
Что от вас нужно ?
Билет на PHDays
Регистрация на сайте мероприятия. Спешите, колличество мест ограничено.
https://phdays.com/ru/activities/?type=7&activity-id=115
Ноутбуки. Нужно будет ставить инструменты. Это будет воркшоп с практикой. Будем смотреть агентные системы. Материала по этой теме не так уж и много, а в рамках воркшопа заинтересованные могут не только познакомиться с инструментами, но и получить дозу позитивного живого общения, обмена опытом.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11👍4🔥4
Forwarded from Евгений Кокуйкин - Raft
Вышел новый документ OWASP: Agent Name Service (ANS) for Secure AI Agent Discovery. По сути — это аналог старой концепции реестра микросервисов, знакомый многим бекенд разработчикам. В данном случае корректнее сказать, что Кен Хуанг выпускает ещё один свой документ (если не ошибаюсь, уже четвёртый за последний квартал), прикрываясь брендом OWASP.
Предложенный подход представляет референсную архитектуру для агентных систем. Недавно Кен также представил Zero Trust Agent (ZTA) Framework, который выполняет аналогичную функцию, в основном — маркетинговую. Если вы начнёте читать документ, то бонусом получите главу с анализом рисков нового сервиса по методу MAESTRO, которую Кен успешно запустил месяц назад.
Маловероятно, что ANS будет принят на уровне, сравнимом с MCP или A2A.
Может показаться, что я излишне критичен к документу. Кен — хороший автор и талантливый пиарщик своих инициатив, но качество публикаций низкое и их практическая применимость вызывает вопросы. В OWASP существует внутренняя политическая игра между инициативой AI Exchange и проектом GenAI. Пограничные документы, вроде этого, публикуются без какой-либо валидации. В нашей рабочей группе Agentic Security Initiative, например, даже не было анонса нового discovery-сервиса.
Главное отличие маркетингового документа от технического протокола или фреймворка — это наличие поддержки и версионирования. Многие публикации, после масштабных LinkedIn-релизов, были заброшены и больше не обновляются.
Предложенный подход представляет референсную архитектуру для агентных систем. Недавно Кен также представил Zero Trust Agent (ZTA) Framework, который выполняет аналогичную функцию, в основном — маркетинговую. Если вы начнёте читать документ, то бонусом получите главу с анализом рисков нового сервиса по методу MAESTRO, которую Кен успешно запустил месяц назад.
Маловероятно, что ANS будет принят на уровне, сравнимом с MCP или A2A.
Может показаться, что я излишне критичен к документу. Кен — хороший автор и талантливый пиарщик своих инициатив, но качество публикаций низкое и их практическая применимость вызывает вопросы. В OWASP существует внутренняя политическая игра между инициативой AI Exchange и проектом GenAI. Пограничные документы, вроде этого, публикуются без какой-либо валидации. В нашей рабочей группе Agentic Security Initiative, например, даже не было анонса нового discovery-сервиса.
Главное отличие маркетингового документа от технического протокола или фреймворка — это наличие поддержки и версионирования. Многие публикации, после масштабных LinkedIn-релизов, были заброшены и больше не обновляются.
👍6
В последнее время часто вижу термин Internet Of Agents(IoA). Мы уже с вами прекрасно понимаем ландшафт угроз для обычных агентных систем. Но в чём особенность именно агентного интернета ?
Под IoA сейчас понимают инфраструктуру центричность которой поставлена на агентах, взаимодействие с ними вне рамках обычных сетей организаций а также чтобы они могли координированно выполнять задачи.
Для коммуникации между агентами в такой сети реализовано большое множество протоколов – самый известный MCP, но как правило – не единственный (подробнее на рис.1).
Мы должны понимать самое важное что в такой сети может использоваться множество LLM как ядра определённых систем, следовательно – они могут наследовать проблемы самих моделей. Важный фактор что такие системы пока что могут быть децентрализованными(рано или поздно будут регуляторы, реестры и т.д). И хоть кажется что реализация такой сети будет иметь большие преимущества(безусловно это так). Но риски ИБ тут никто не отменял.
В статье Security of Internet of Agents: Attacks and Countermeasures рассматривается некая модель угроз для такой площадки. IoA переваривает множество персональной информации, коммерческих данных и из-за этого вопрос безопасности аутентификации между агентными системами – является критически значимым.
В статье определяют несколько угроз:
⁉️ Подделка идентичности - злоумышленники создают поддельные идентификаторы агентов.
⁉️ Имперсонификация - злоумышленники выдают себя за легитимных агентов
⁉️ Атаки типа Sybil -когда создаётся множество фиктивных идентичностей для манипуляции системой
⁉️ Каскадные атаки - неточные или противоречивые выходные данные LLM могут распространяться и усиливаться через последующие взаимодействия агентов в самой системе
⁉️ А также … Скрытый сговор – агенты могут начать сотрудничать для достижения целей, которые будут противоречить интересам пользователя.
Несоменно в своё видение угроз авторы добавили RAG, достаточно очевидно и можно согласиться.
Авторы также предложили пока что теоретические варианты митигаций:
Внедрять механизмы (пока что не агентов), которые бы смотрели наличие сговора.
Системы репутации и реестры на основе блокчейна, а также контроль доступа, зависимый от контекста самой агентой системы.
Да, пока что это выглядит слишком концептуально, да и честно сказать с трудом вериться в то, что LLM будет активно оценивать результаты других агентов. Но проблема становиться виднее.
Под IoA сейчас понимают инфраструктуру центричность которой поставлена на агентах, взаимодействие с ними вне рамках обычных сетей организаций а также чтобы они могли координированно выполнять задачи.
Для коммуникации между агентами в такой сети реализовано большое множество протоколов – самый известный MCP, но как правило – не единственный (подробнее на рис.1).
Мы должны понимать самое важное что в такой сети может использоваться множество LLM как ядра определённых систем, следовательно – они могут наследовать проблемы самих моделей. Важный фактор что такие системы пока что могут быть децентрализованными(рано или поздно будут регуляторы, реестры и т.д). И хоть кажется что реализация такой сети будет иметь большие преимущества(безусловно это так). Но риски ИБ тут никто не отменял.
В статье Security of Internet of Agents: Attacks and Countermeasures рассматривается некая модель угроз для такой площадки. IoA переваривает множество персональной информации, коммерческих данных и из-за этого вопрос безопасности аутентификации между агентными системами – является критически значимым.
В статье определяют несколько угроз:
Несоменно в своё видение угроз авторы добавили RAG, достаточно очевидно и можно согласиться.
Авторы также предложили пока что теоретические варианты митигаций:
Внедрять механизмы (пока что не агентов), которые бы смотрели наличие сговора.
Системы репутации и реестры на основе блокчейна, а также контроль доступа, зависимый от контекста самой агентой системы.
Да, пока что это выглядит слишком концептуально, да и честно сказать с трудом вериться в то, что LLM будет активно оценивать результаты других агентов. Но проблема становиться виднее.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍1👏1
Хотел написать пост об отчёте Pangea, но пришлось писать публикацию на хабр. Конкурс интересный, а количество участников - поражает.
https://habr.com/ru/articles/910334/
https://habr.com/ru/articles/910334/
Хабр
Комната Наверху и другие истории обхода LLM
В марте 2025, компания Pangea провела конкурс – в нём поучаствовали более 800 участников из разных стран. Суть в том, что было несколько комнат – лабораторных, где участникам необходимо было...
1🔥7👍5
Forwarded from Борис_ь с ml
Итак, доклад по безопасности AI-агентов, MCP и A2A, который я прочитал с коллегой на Форуме "Технологии Доверенного ИИ"
#иб_для_ml
Файл вы найдете ниже под постом
Более того, я собираюсь сделать небольшую серию постов, согласно оглавлению доклада.
О чем же он был?
Во введении мы рассказали про понятие AI-агентов как таковых, немного раскрыли их отличие от просто чат-ботов или RAG. Привели определение мультиагентной системы и представили схему объектов защиты на основе модели угроз AI, представленной Сбербанком.
Далее раскрыли суть понятия MCP, конечно же со схемкой, и дали описание одной из возможных атак на этот протокол: Tool Poisoning Attack.
После чего - аналогично с A2A и атакой Privilege Escalation.
Главный интересный раздел - безопасность систем на стыке этих протоколов, пример атаки, эксплуатирующей их несогласованность, и главное - модель угроз для систем на протоколах MCP+A2A.
В качестве завершения - возможные меры защиты, мои выводы и пучок полезных ссылок по поводу)
Остаемся на связи, скоро расскажу про все подробнее.
#иб_для_ml
Файл вы найдете ниже под постом
Более того, я собираюсь сделать небольшую серию постов, согласно оглавлению доклада.
О чем же он был?
Во введении мы рассказали про понятие AI-агентов как таковых, немного раскрыли их отличие от просто чат-ботов или RAG. Привели определение мультиагентной системы и представили схему объектов защиты на основе модели угроз AI, представленной Сбербанком.
Далее раскрыли суть понятия MCP, конечно же со схемкой, и дали описание одной из возможных атак на этот протокол: Tool Poisoning Attack.
После чего - аналогично с A2A и атакой Privilege Escalation.
Главный интересный раздел - безопасность систем на стыке этих протоколов, пример атаки, эксплуатирующей их несогласованность, и главное - модель угроз для систем на протоколах MCP+A2A.
В качестве завершения - возможные меры защиты, мои выводы и пучок полезных ссылок по поводу)
Остаемся на связи, скоро расскажу про все подробнее.
👍13🔥3❤1
Forwarded from OSINT mindset
Уже скоро OSINT mindset conference #7! А значит мы готовы представить наших спикеров: 🔥
sled_tut — Ваша мама в сетке: раскрываем неочевидные связи между телеграм-каналами
nicksinus — Портрет закладки
Adk — Gaming OSINT
crytech7 — Messages Sent to the Void: Tracking Transactions to Ethereum Null Address
Riaria — Как интернет, технологии и социальные сети портят жизнь тем, кто ворует искусство
Помимо докладов мы, как обычно, готовим для вас стенды LockPick и OSINT Village!🔍
Ждём всех 31 мая в 13:00 (UTC+3) в Благосфере, м. Динамо, 1-й Боткинский проезд, д. 7c1. Мероприятие полностью бесплатное, без регистрации и возрастного ограничения✨
Также если вы представитель СМИ или блогер и планируете посетить конференцию, чтобы в дальнейшем написать про неё, просим заполнить анкету.
🌐 Site | 💬 Forum | 🔍 Family |▶ YT
sled_tut — Ваша мама в сетке: раскрываем неочевидные связи между телеграм-каналами
nicksinus — Портрет закладки
Adk — Gaming OSINT
crytech7 — Messages Sent to the Void: Tracking Transactions to Ethereum Null Address
Riaria — Как интернет, технологии и социальные сети портят жизнь тем, кто ворует искусство
Помимо докладов мы, как обычно, готовим для вас стенды LockPick и OSINT Village!
Ждём всех 31 мая в 13:00 (UTC+3) в Благосфере, м. Динамо, 1-й Боткинский проезд, д. 7c1. Мероприятие полностью бесплатное, без регистрации и возрастного ограничения
Также если вы представитель СМИ или блогер и планируете посетить конференцию, чтобы в дальнейшем написать про неё, просим заполнить анкету.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4❤3
ChatGPT – В С Ё.😁😁😁 Буквально позавчера Anthropic выпустили Claude 4, Sonnet & Opus. Новая модель. Лучше в агентах, лучше в рассуждениях. Но как дела с безопасностью?
Хотел бы начать с анализа системной карты. Но нет, чуть позже. Anthropic выпустили свой стандарт ASL(AI Safety Level-3). Стандарт основывается на двух ключевых компонентах – Методы развёртывания и методы безопасности. Практики, применяемые к ним, и формируют уровни. Anthropic присвоили своей модели 3й уровень, что говорит о высоком уровне защищённости. Хотя уже вчера в аккаунте Plini появилась информация о том, что можно всё-таки джейлбрейкнуть, он отмечает о том, что это стало сложнее – но метод 2024 года смог сработать.
Anthropic отмечают – что стандарт не является полностью сформированным. И даже говорят, что это предупредительная и временная мера.
Компания еще не определила окончательно, превысил ли Claude Opus 4 порог возможностей, требующий защиты ASL-3. Однако из-за продолжающегося улучшения знаний и возможностей, связанных с генерацией ответов на запросы про бомбу, Anthropic решила, что невозможно однозначно исключить риски ASL-3 для Claude Opus 4 так, как это было возможно для предыдущих моделей.
Стандарт интересный, описывают и интеграцию багбаунти и меры защиты в виде контроля Endpoint, жизненного цикла и мониторинга. Про ASL-3 можно написать один большой пост. Но я рекомендую вам ознакомиться с ним самостоятельно. Кстати, Claude 3.5 они оценивают на ASL-2. 2-й уровень включает базовую защиту от попыток кражи весов и подразумевается, что модель обучена говорить «нет» на опасные запросы.
Что было сделано в 4-й модели?
По сути, как они пишут – была доработана концепция Constitutional Classifiers — системы, где классификаторы в реальном времени, обученные на синтетических данных, отслеживают вредоносные запросы и отклоняют их. Модель проверяли на бенчмарке StrongREJECT, в качестве атакующей модели использовали Claude Sonnet 3.5, без alignment. Она генерировала джейлбрейки и, ожидаемо, показатели модели с точки зрения безопасности при таком подходе оценки – стали выше. Anthropic реализовали механизм быстрого устранение джейлбрейков. Модель генерирует синтетику на основе подозрительного ввода и на основании этого происходит дообучение классификаторов.
В системную карту также включили подробную оценку того как работает элаймент. Разные категории рисков: предвзятость, соответствие вредоносным инструкциям, скрытые намерения, и плохие рассуждения – всё это учитывается при элайменте.
Ну а в заключении хочется сказать про агентов. Anthropic говорят что они усилили безопасность модели с точки зрения применения как ядра агентной системы: Например реализовали механизмы оценки злонамеренного использования компьютера, классификатор доработали для защиты от инъекций – также при ComputerUseAgent mode. И конечно же постарались сделать безопасным вайб-кодинг. В плане того, что усилили механизм предотвращения вредоносной генерации кода агентами.
Хотел бы начать с анализа системной карты. Но нет, чуть позже. Anthropic выпустили свой стандарт ASL(AI Safety Level-3). Стандарт основывается на двух ключевых компонентах – Методы развёртывания и методы безопасности. Практики, применяемые к ним, и формируют уровни. Anthropic присвоили своей модели 3й уровень, что говорит о высоком уровне защищённости. Хотя уже вчера в аккаунте Plini появилась информация о том, что можно всё-таки джейлбрейкнуть, он отмечает о том, что это стало сложнее – но метод 2024 года смог сработать.
Anthropic отмечают – что стандарт не является полностью сформированным. И даже говорят, что это предупредительная и временная мера.
Компания еще не определила окончательно, превысил ли Claude Opus 4 порог возможностей, требующий защиты ASL-3. Однако из-за продолжающегося улучшения знаний и возможностей, связанных с генерацией ответов на запросы про бомбу, Anthropic решила, что невозможно однозначно исключить риски ASL-3 для Claude Opus 4 так, как это было возможно для предыдущих моделей.
Стандарт интересный, описывают и интеграцию багбаунти и меры защиты в виде контроля Endpoint, жизненного цикла и мониторинга. Про ASL-3 можно написать один большой пост. Но я рекомендую вам ознакомиться с ним самостоятельно. Кстати, Claude 3.5 они оценивают на ASL-2. 2-й уровень включает базовую защиту от попыток кражи весов и подразумевается, что модель обучена говорить «нет» на опасные запросы.
Что было сделано в 4-й модели?
По сути, как они пишут – была доработана концепция Constitutional Classifiers — системы, где классификаторы в реальном времени, обученные на синтетических данных, отслеживают вредоносные запросы и отклоняют их. Модель проверяли на бенчмарке StrongREJECT, в качестве атакующей модели использовали Claude Sonnet 3.5, без alignment. Она генерировала джейлбрейки и, ожидаемо, показатели модели с точки зрения безопасности при таком подходе оценки – стали выше. Anthropic реализовали механизм быстрого устранение джейлбрейков. Модель генерирует синтетику на основе подозрительного ввода и на основании этого происходит дообучение классификаторов.
В системную карту также включили подробную оценку того как работает элаймент. Разные категории рисков: предвзятость, соответствие вредоносным инструкциям, скрытые намерения, и плохие рассуждения – всё это учитывается при элайменте.
Ну а в заключении хочется сказать про агентов. Anthropic говорят что они усилили безопасность модели с точки зрения применения как ядра агентной системы: Например реализовали механизмы оценки злонамеренного использования компьютера, классификатор доработали для защиты от инъекций – также при ComputerUseAgent mode. И конечно же постарались сделать безопасным вайб-кодинг. В плане того, что усилили механизм предотвращения вредоносной генерации кода агентами.
🔥13❤4👍4❤🔥2
Жизненный цикл, данные и АНБ. Новый американский стандарт описывает лучшие практики по защите данных для AI. И, наверное, все мы понимаем базовое вроде «не должно быть перекоса в данных», «должен быть контроль доступа и очистка». Но как видит это АНБ? Тут всё не так уж и однозначно.
Это не фреймворк, в классическом понимании. Но что-то схожего тут есть – например рассматривают меры для жизненного цикла данных, раскладывают его по полочкам.
Как отмечается в документе, успешные стратегии управления данными должны гарантировать, что данные не были подвергнуты несанкционированному изменению на любом этапе жизненного цикла ИИ, не содержат вредоносного, а также не имеют непреднамеренной дублирующей или информации, которая может быть аномалией.
NSA определяет следующие риски:
1.Цепочка поставок. Тут кристально понятно. Они, кстати, приводят в пример кейс с отравлением википедии, когда злоумышленник вносит вредоносные правки непосредственно перед тем, как сайты с краудсорсинговым контентом делают снимок своих данных. Также уделили внимание на своей аналитике – отравление датасета LAION-2B – для злоумышленника может стоить от 60$ до 1000, а эффект будет большой.
2. Предвзятость, состязательные примеры, искажающие процесс обучения, проблемные метаданные и некачественный датасет – всё это относят ко второму типу угроз,
3. Дрейф данных. Хотя документ упоминает дрейф данных как один из рисков безопасности данных на некоторых этапах жизненного цикла, подробное описание этого риска и стратегий его снижения в документе отсутствует.
Между этим как мне кажется можно было бы определить угрозы, связанные с синтетикой, а может и нет … всё-таки ж речь про безопасность. К этим рискам они отнесли рекомендации:
NSA дают общие рекомендации:
1.Использование надежных источников данных и отслеживание происхождения
2.Проверка и поддержание целостности данных
3. Использование цифровых подписей
4. Использование доверенной инфраструктуры
5. Классификация данных и контроль доступа
6. Шифрование данных (AES-256)
7. Безопасное хранение данных (должны храниться на устройствах, соответствующих NIST FIPS 140–3)
8. Методы сохранения конфиденциальности (Дифференциальная приватность, федеративное обучение)
9. Безопасное удаление данных (в соответствии с NIST SP 800-88)
10. Проводить регулярную оценку безопасности данных (также в соответствии с NIST SP 800-3r2 и NIST AI 100-1)
По их мнению, да и по лучшим стандартам сейчас для цепочки поставок можно реализовывать хеширование данных, регулярно смотреть целостность.
ну а ссылка вот.
Это не фреймворк, в классическом понимании. Но что-то схожего тут есть – например рассматривают меры для жизненного цикла данных, раскладывают его по полочкам.
Как отмечается в документе, успешные стратегии управления данными должны гарантировать, что данные не были подвергнуты несанкционированному изменению на любом этапе жизненного цикла ИИ, не содержат вредоносного, а также не имеют непреднамеренной дублирующей или информации, которая может быть аномалией.
NSA определяет следующие риски:
1.Цепочка поставок. Тут кристально понятно. Они, кстати, приводят в пример кейс с отравлением википедии, когда злоумышленник вносит вредоносные правки непосредственно перед тем, как сайты с краудсорсинговым контентом делают снимок своих данных. Также уделили внимание на своей аналитике – отравление датасета LAION-2B – для злоумышленника может стоить от 60$ до 1000, а эффект будет большой.
2. Предвзятость, состязательные примеры, искажающие процесс обучения, проблемные метаданные и некачественный датасет – всё это относят ко второму типу угроз,
3. Дрейф данных. Хотя документ упоминает дрейф данных как один из рисков безопасности данных на некоторых этапах жизненного цикла, подробное описание этого риска и стратегий его снижения в документе отсутствует.
Между этим как мне кажется можно было бы определить угрозы, связанные с синтетикой, а может и нет … всё-таки ж речь про безопасность. К этим рискам они отнесли рекомендации:
NSA дают общие рекомендации:
1.Использование надежных источников данных и отслеживание происхождения
2.Проверка и поддержание целостности данных
3. Использование цифровых подписей
4. Использование доверенной инфраструктуры
5. Классификация данных и контроль доступа
6. Шифрование данных (AES-256)
7. Безопасное хранение данных (должны храниться на устройствах, соответствующих NIST FIPS 140–3)
8. Методы сохранения конфиденциальности (Дифференциальная приватность, федеративное обучение)
9. Безопасное удаление данных (в соответствии с NIST SP 800-88)
10. Проводить регулярную оценку безопасности данных (также в соответствии с NIST SP 800-3r2 и NIST AI 100-1)
По их мнению, да и по лучшим стандартам сейчас для цепочки поставок можно реализовывать хеширование данных, регулярно смотреть целостность.
ну а ссылка вот.
❤2
Не очень часто что-то нахожу/публикую интересное по форензике моделей. Да и вообще по тому, как расследовать инциденты в организации, если взломали через какую-то заражённую ML-модель. Поэтому исправляюсь. Предлагаю Вам немного полезного материала по этой теме.
1. NullfiAI, атака доказывающая, что средства защиты могут быть бесполезными. Давняя статья, я даже писал о ней - суть в том, что исследователи рассказали о том, как можно замалварить пикл, да так чтобы сканеры не отрабатывали.
2. Цепочка поставок - большая беда. ReversingLabs также недавно провели анализ PyPi и, к сожалению, обнаружили вредоносную ML-библиотеку. Это не первый похожий случай.
3. Кажется, что подходы классической безопасности хорошо подходят для анализа моделей - но уж нет. Авторы статьи "Gaps in Traditional DFIR Playbooks: Machine Learning Models" рассматривают особенности процесса на примере анализа onnx.
4. От авторов предыдущей статьи есть также публикация про расследование с ml-артефактами . Хорошее чтение с реальным примером.
Только ли в сериализации беда?
Вам может показаться после прочтения статьей что сериализация является важным источником угроз для ML. Частично это да. Для неё уже есть много крутых инструментов, flickling, к примеру. Хотя мы ни в коем случае не должны забывать про MLOps ландшафт, область, где модель храниться, хранит свои данные. Тут в большинстве случаев вам порекомендуют анализировать логи MLOps решений, DVC и кто делает коммиты в GIT. В целом вам также может понадобиться понимание ответа на вопрос "какие форматы датасетов" существуют? и тут тоже есть полезный ресурс - храним, запоминаем.
1. NullfiAI, атака доказывающая, что средства защиты могут быть бесполезными. Давняя статья, я даже писал о ней - суть в том, что исследователи рассказали о том, как можно замалварить пикл, да так чтобы сканеры не отрабатывали.
2. Цепочка поставок - большая беда. ReversingLabs также недавно провели анализ PyPi и, к сожалению, обнаружили вредоносную ML-библиотеку. Это не первый похожий случай.
3. Кажется, что подходы классической безопасности хорошо подходят для анализа моделей - но уж нет. Авторы статьи "Gaps in Traditional DFIR Playbooks: Machine Learning Models" рассматривают особенности процесса на примере анализа onnx.
4. От авторов предыдущей статьи есть также публикация про расследование с ml-артефактами . Хорошее чтение с реальным примером.
Только ли в сериализации беда?
Вам может показаться после прочтения статьей что сериализация является важным источником угроз для ML. Частично это да. Для неё уже есть много крутых инструментов, flickling, к примеру. Хотя мы ни в коем случае не должны забывать про MLOps ландшафт, область, где модель храниться, хранит свои данные. Тут в большинстве случаев вам порекомендуют анализировать логи MLOps решений, DVC и кто делает коммиты в GIT. В целом вам также может понадобиться понимание ответа на вопрос "какие форматы датасетов" существуют? и тут тоже есть полезный ресурс - храним, запоминаем.
🔥5❤1