Если вы хотели потренироваться во взломе llm, то есть отличная новость.
Стив Уилсон, один из создателей OWASP top 10 для llm выпустил Лабу
https://virtualsteve-star.github.io/chat-playground/
Вроде бы как обычная песочница, но вы без проблем можете развернуть её локально(код есть на GitHub)
Подробнее:
https://www.reversinglabs.com/blog/owasp-chat-playground-lets-you-toy-around-with-ai-security
Стив Уилсон, один из создателей OWASP top 10 для llm выпустил Лабу
https://virtualsteve-star.github.io/chat-playground/
Вроде бы как обычная песочница, но вы без проблем можете развернуть её локально(код есть на GitHub)
Подробнее:
https://www.reversinglabs.com/blog/owasp-chat-playground-lets-you-toy-around-with-ai-security
Steve's Chat Playground
An open-source, hands-on environment for experimenting with LLM security concepts, vulnerable chat models, and guardrails. Try content moderation, prompt injection and output filters—all in your browser, with zero dependencies.
Как выглядит подход Google для того, чтобы защитить ваших агентов и что в нём не так.
Ранее в мае, Google выкатили фреймворк для безопасности AI-агентов. Он основан на трёх ключевых принципах: чётко определённый контроль человеком, ограничение полномочий агентов и наблюдаемость действий агента и то, как он планирует задачи.
Кажется, что фреймворк в чём-то описывает очень стандартную для агентов историю по защите. Но я не стал писать о нём сюда, до одного момента - сегодня вышла статья Simon Willison, который детально провёл его анализ и осветил важные моменты, которые мы сейчас и рассмотрим.
Уже в начале статьи Willison выявляет принципиальное различие в подходах. Он отмечает, что Google выбрала менее категоричный путь по сравнению с другими исследователями. Если предыдущие работы четко утверждали, что AI-агент, получивший плохие данные, должен быть полностью ограничен в возможности выполнения значимых действий, то Google пытается найти компромисс.
Willison видит в этом фундаментальную проблему. Он считает, что Google обходит критически важные вопросы вместо их прямого решения. Фреймворк предлагает решения, основанные на надежном различении доверенных команд пользователя от потенциально опасных контекстных данных из других источников.
Willison говорит, что: Это неправильно ! Так как однозначное разделение невозможно.
Он подчеркивает, что вопросы/задачи формулируются пользователями таким образом, как будто решение существует, но в действительности такого решения нет.
Коротко о его мнении по поводу трёх принципов:
1. Человеческий контроль: Сам Willison не даёт оценки первому принципу, но отмечает два ключевых момента: отслеживание того, какой пользователь контролирует агента, и добавление этапа подтверждения человеком для критических действий.
2. Принцип с ограничением полномочий агентов вызывает скептицизм. Он отмечает, что предложение Google слишком изощрено, так как требует буквально динамически изменяемых полномочий для агентов – сложно представить как это будет работать на практике. А ключевая проблема тут в том, что реализация таких guardrails потребует дополнительных моделей, которые будут корректировать разрешения исходя из задачи. Это кажется рискованным, так как промпт-инъекции могут повлиять на такие решения. Даже Google признает ограничения – стратегии недетерминированны и не могут предоставить абсолютные гарантии, что модели все еще могут быть обмануты новыми атаками, и что их режимы отказа могут быть непредсказуемыми
3. Willison согласен с тем, что должна быть наблюдаемость, как фундаментальное требование ИБ.
Риски, связанные с рендерингом вывода и меры которые описаны в документе – это большой + по его мнению, да и в целом, если приложение рендерит без санитизации или экранирования, то могут возникать разные уязвимости типа XSS или утечка информации.
Важной ценностью самого фреймворка является подход “defense-in-depth”, который комбинирует классические меры ИБ с reasoning-based механизмами защиты. Документ признает, что ни один подход в отдельности не может обеспечить абсолютную безопасность AI-агентов, поэтому подходов много!
https://simonwillison.net/2025/Jun/15/ai-agent-security/
Ранее в мае, Google выкатили фреймворк для безопасности AI-агентов. Он основан на трёх ключевых принципах: чётко определённый контроль человеком, ограничение полномочий агентов и наблюдаемость действий агента и то, как он планирует задачи.
Кажется, что фреймворк в чём-то описывает очень стандартную для агентов историю по защите. Но я не стал писать о нём сюда, до одного момента - сегодня вышла статья Simon Willison, который детально провёл его анализ и осветил важные моменты, которые мы сейчас и рассмотрим.
Уже в начале статьи Willison выявляет принципиальное различие в подходах. Он отмечает, что Google выбрала менее категоричный путь по сравнению с другими исследователями. Если предыдущие работы четко утверждали, что AI-агент, получивший плохие данные, должен быть полностью ограничен в возможности выполнения значимых действий, то Google пытается найти компромисс.
Willison видит в этом фундаментальную проблему. Он считает, что Google обходит критически важные вопросы вместо их прямого решения. Фреймворк предлагает решения, основанные на надежном различении доверенных команд пользователя от потенциально опасных контекстных данных из других источников.
Willison говорит, что: Это неправильно ! Так как однозначное разделение невозможно.
Он подчеркивает, что вопросы/задачи формулируются пользователями таким образом, как будто решение существует, но в действительности такого решения нет.
Коротко о его мнении по поводу трёх принципов:
1. Человеческий контроль: Сам Willison не даёт оценки первому принципу, но отмечает два ключевых момента: отслеживание того, какой пользователь контролирует агента, и добавление этапа подтверждения человеком для критических действий.
2. Принцип с ограничением полномочий агентов вызывает скептицизм. Он отмечает, что предложение Google слишком изощрено, так как требует буквально динамически изменяемых полномочий для агентов – сложно представить как это будет работать на практике. А ключевая проблема тут в том, что реализация таких guardrails потребует дополнительных моделей, которые будут корректировать разрешения исходя из задачи. Это кажется рискованным, так как промпт-инъекции могут повлиять на такие решения. Даже Google признает ограничения – стратегии недетерминированны и не могут предоставить абсолютные гарантии, что модели все еще могут быть обмануты новыми атаками, и что их режимы отказа могут быть непредсказуемыми
3. Willison согласен с тем, что должна быть наблюдаемость, как фундаментальное требование ИБ.
Риски, связанные с рендерингом вывода и меры которые описаны в документе – это большой + по его мнению, да и в целом, если приложение рендерит без санитизации или экранирования, то могут возникать разные уязвимости типа XSS или утечка информации.
Важной ценностью самого фреймворка является подход “defense-in-depth”, который комбинирует классические меры ИБ с reasoning-based механизмами защиты. Документ признает, что ни один подход в отдельности не может обеспечить абсолютную безопасность AI-агентов, поэтому подходов много!
https://simonwillison.net/2025/Jun/15/ai-agent-security/
Промпт-инъекции по-прежнему являются угрозой номер один. Но на борьбу, на реализацию решений и методологии – выделяются большие команды и деньги, очевидно.
Недавно Google релизнул свою методологию по защите от промпт-инъекций, так сказать методологию в несколько слоёв.
Они предлагают использовать несколько уровней защиты:
Сперва интегрировать классификатор промпт-инъекций, что-то похожее мы видели у Anthropic как Constitutional Classifiers, а также отдельные файрволлы.
Далее уровень инструкций. Риск обхода инструкций, которые будут защищать модель – велик. Но что поделать – Google говорит, что если все 5 камней активируются, то только тогда будет сила.
Третий уровень – санитизация вредоносных URL и markdown, а также применения подхода Safe Browsing для защиты входных данных.
Скажу сейчас - этот подход они применяют в Gemini.
Четвёртый и пятый уровень – это взаимодействие с пользователем, использование Human-in-the-loop как способа верификации контента, а также оповещение пользователей о том, что сгенерированный контент является вредоносным. Тоесть получается такая проактивная стратегия защиты – в которой пользователь конечно же является значимым звеном.
Параллельно с этим вышла интересная классификация от Hidden Layer, в которой они предложили различные техники атак с использованием промптов. Таксономия включает в себя 62 различные тактики. Проблема в том, что в некоторых случаях это и угрозы связанные с саммаризацией(да-да) (просто попросить саммари вредоносного контекста) или же Cognitive overload (который больше на reasoning применим кмк). Удобное визуальное разделение, а также наличие хоть и не совсем работающих – но adversarial инструкций. Заслуживает вашего внимания.
Недавно Google релизнул свою методологию по защите от промпт-инъекций, так сказать методологию в несколько слоёв.
Они предлагают использовать несколько уровней защиты:
Сперва интегрировать классификатор промпт-инъекций, что-то похожее мы видели у Anthropic как Constitutional Classifiers, а также отдельные файрволлы.
Далее уровень инструкций. Риск обхода инструкций, которые будут защищать модель – велик. Но что поделать – Google говорит, что если все 5 камней активируются, то только тогда будет сила.
Третий уровень – санитизация вредоносных URL и markdown, а также применения подхода Safe Browsing для защиты входных данных.
Скажу сейчас - этот подход они применяют в Gemini.
Четвёртый и пятый уровень – это взаимодействие с пользователем, использование Human-in-the-loop как способа верификации контента, а также оповещение пользователей о том, что сгенерированный контент является вредоносным. Тоесть получается такая проактивная стратегия защиты – в которой пользователь конечно же является значимым звеном.
Параллельно с этим вышла интересная классификация от Hidden Layer, в которой они предложили различные техники атак с использованием промптов. Таксономия включает в себя 62 различные тактики. Проблема в том, что в некоторых случаях это и угрозы связанные с саммаризацией(да-да) (просто попросить саммари вредоносного контекста) или же Cognitive overload (который больше на reasoning применим кмк). Удобное визуальное разделение, а также наличие хоть и не совсем работающих – но adversarial инструкций. Заслуживает вашего внимания.
Тут Королевский Университет проанализировал большое количество проектов с MCP - и сделал классную статистику о том что сейчас встречается в таких проектах по уязвимостям. Для анализа использовали SonarQube и mcp-scan от invariant-labs. 😓
ну а подробнее можете почитать в моей статье на хабре
ну а подробнее можете почитать в моей статье на хабре
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Первое масштабное исследование безопасности MCP: что показал анализ 1,899 серверов, которые находятся в открытом доступе
Model Context Protocol (MCP) стремительно завоевал позиции де-факто стандарта для взаимодействия между AI-агентами и внешними инструментами. Статистика впечатляет: по состоянию на май 2025 года PyPI...
Пишу свою карту, но паралельно обнаружил - AI Red Team Roadmap на roadmap.sh
https://roadmap.sh/ai-red-teaming
Полезная, но к сожелению тут нет агентов, да и нет атак на контур разработки моделей (((. Будет чуть позже 😁
P.s выложу роадмап днём ( не успел (
https://roadmap.sh/ai-red-teaming
Полезная, но к сожелению тут нет агентов, да и нет атак на контур разработки моделей (((. Будет чуть позже 😁
P.s выложу роадмап днём ( не успел (
Привет. Вот моя версия карты по AI Red Teaming. Часто в личку вы мне пишите "Как начать ломать ?". Это некоторый journey, в котором показано что надо изучить и что можно ломать.
Как мне кажется после понимания основ МЛ - важно понимать вектора на разные поддоменные области - так я и поделил reasoning, агентов и rag по отдельности.
На некоторых блоках я оставил QR код, с ссылками. Кроме агентов и MlOps - об этом достаточно много материала на моём канале и в т.ч в посте который писал Борис Часть из них содержит статьи на arxiv, так как нигде больше не описывают атаки(((. Атаки проверены.
Помимо карты которую я приложил можно обратиться к другим мапам:
1. Карта от Scale AI, больше рассказывает про то "что придётся атаковать".
2. Блог JustForFan - AI для безопасников
3. Joseph Thacker - How to Hack AI Agents and Applications - пожалуй самый прикладной roadmap, автор показывает где взять датасеты, даёт базовое объяснение некоторых концепций.
В любом случае стоит посмотреть карты для себя и выбрать то что ближе. Не претендую на полноту, а просто представляю свой взгляд на это )).
Как мне кажется после понимания основ МЛ - важно понимать вектора на разные поддоменные области - так я и поделил reasoning, агентов и rag по отдельности.
На некоторых блоках я оставил QR код, с ссылками. Кроме агентов и MlOps - об этом достаточно много материала на моём канале и в т.ч в посте который писал Борис Часть из них содержит статьи на arxiv, так как нигде больше не описывают атаки(((. Атаки проверены.
Помимо карты которую я приложил можно обратиться к другим мапам:
1. Карта от Scale AI, больше рассказывает про то "что придётся атаковать".
2. Блог JustForFan - AI для безопасников
3. Joseph Thacker - How to Hack AI Agents and Applications - пожалуй самый прикладной roadmap, автор показывает где взять датасеты, даёт базовое объяснение некоторых концепций.
В любом случае стоит посмотреть карты для себя и выбрать то что ближе. Не претендую на полноту, а просто представляю свой взгляд на это )).
Telegram
PWN AI
Основные ресурсы по вопросам безопасности ИИ
#иб_в_ml
Если вы задавались вопросом, как найти полезную информацию о некоторой узкой теме в ML Security, или только собираетесь знакомится с этой областью, этот список ресурсов для вас.
Просто ML
🟢Гит со ссылками…
#иб_в_ml
Если вы задавались вопросом, как найти полезную информацию о некоторой узкой теме в ML Security, или только собираетесь знакомится с этой областью, этот список ресурсов для вас.
Просто ML
🟢Гит со ссылками…
Forwarded from Борис_ь с ml
AI-агенты и мультиагентные системы, MCP и A2A. Основные угрозы и подходы к обеспечению безопасности
#иб_для_ml
⛓ https://habr.com/ru/articles/920744/
Сначала по мотивам своего выступления писал серию постов, но вскоре достаточно разрослись, и они превратились в целую статью. Так что - приглашаю к прочтению!
Про AI-агентов, мултиагентные системы, MCP, A2A, и их безопасность - местами даже чуть углубленнее, чем в самом докладе.
#иб_для_ml
Сначала по мотивам своего выступления писал серию постов, но вскоре достаточно разрослись, и они превратились в целую статью. Так что - приглашаю к прочтению!
Про AI-агентов, мултиагентные системы, MCP, A2A, и их безопасность - местами даже чуть углубленнее, чем в самом докладе.
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
AI-агенты и мультиагентные системы, MCP и A2A. Основные угрозы и подходы к обеспечению безопасности
Всем привет! Меня зовут Борис, я веду канал «Борис_ь с ml» про информационную безопасность и машинное обучение. Сейчас мой основной вектор исследований - мультиагентные системы и их безопасность....
OWASP сделал гайд для тестирования ИИ.
OWASP AI Testing Guide — это первый в своем роде комплексный фреймворк, объединяющий традиционную кибербезопасность, MLOps и принципы Responsible AI под единой методологией для тех кому интересно тестирование моделей.
Всего включает 4 домена и 32 теста:
Тестирование приложений ИИ (14 тестов)
Тестирование моделей ИИ (7 тестов)
Тестирование инфраструктуры ИИ (6 тестов)
Тестирование данных ИИ (5 тестов)
Мне понравилось что во многих случаях приводят примеры тестовых-кейсов, инструментов и проблем которые можно проэксплуатировать. Кейсы, которые приводятся - не всегда способны обойти современные механизмы защиты моделей, но этого от гайда и не требуется. Есть даже информация про тестирование на объяснимость и интерпертируемость, или блоки про тестирование поведения агентов. И в догонку большое количество доп.ссылок, полезные референсы. Загляденье.
В дополнениях привели угрозы для Responsible AI и схемы.
OWASP AI Testing Guide — это первый в своем роде комплексный фреймворк, объединяющий традиционную кибербезопасность, MLOps и принципы Responsible AI под единой методологией для тех кому интересно тестирование моделей.
Всего включает 4 домена и 32 теста:
Тестирование приложений ИИ (14 тестов)
Тестирование моделей ИИ (7 тестов)
Тестирование инфраструктуры ИИ (6 тестов)
Тестирование данных ИИ (5 тестов)
Мне понравилось что во многих случаях приводят примеры тестовых-кейсов, инструментов и проблем которые можно проэксплуатировать. Кейсы, которые приводятся - не всегда способны обойти современные механизмы защиты моделей, но этого от гайда и не требуется. Есть даже информация про тестирование на объяснимость и интерпертируемость, или блоки про тестирование поведения агентов. И в догонку большое количество доп.ссылок, полезные референсы. Загляденье.
В дополнениях привели угрозы для Responsible AI и схемы.
Часто ли мы видим интересные таксономии или хорошие документы, предназначенные для тестировщиков моделей?
Наверное нет, так как вопрос сложно прорабатываемый на самом деле. А особенно сложно найти документ, который бы описывал не только техники атаки, но и уклонения от защитных классификаторов, а также информацию для тестирования MlOps инфры.
💡 Недавно я нашёл что-то похожее в репозитории Arcanum Prompt Injection Taxonomy.
Таксономия ориентирована на практическое использование. Она построена по принципу трёхуровневой классификации, отвечающей на три ключевых вопроса:
1.ЗАЧЕМ? (Attack Intents) - Какие цели преследует атакующий?
2.КАК? (Attack Techniques) - Какими методами достигаются эти цели?
3.КАК СКРЫТЬ? (Attack Evasions) - Как обойти системы обнаружения?
Такой подход при построении таксономии позволяет систематически анализировать угрозы с разных точек зрения.
Блок с интентами рассказывает о конкретных категориях мотиваций, которые может достичь атакующий – это может быть «утечка системного промпта, перечисление инструментов/API доступных к модели, а также деструктивных и социальных мотиваций для того, чтобы реализовать атаку.
Дальше – техники, тут 18 техник для реализации промпт-атак. Например, можно составлять промпт-инъекцию с множеством вложенных структур или заставить имитировать LLM роль интерпретатора или системы – всё это может быть применимо при реализации атаки или джейлбрейка из статьи/датасета, особенно если оно не работает изначально.😵
Потом, список методов уклонения от цензоров. Большой список, тут и про кодирование текста, и про сокрытие текста в emoji, фонетические замены и вымышленные языки – да, да всем этим можно сокрыть ваш промпт, чтобы обойти простой классификатор, не удивляйтесь.😮
А также есть отдельный блок – Экосистема.
Тут приведена таблица, где описаны MLOPS решения, их известные порты, заголовки http, методы аутентификации и известные CVE(список пополняется, но не ссылками на эксплоиты). Что мне очень сильно понравилось. Где ещё найти такой лист с готовой информацией об инфре?
Есть и чек-листы для защиты, опросники, а также перечень проб – промпты которые вы можете закинуть в модель для тестирования промпт-инъекций.
Ну и самое интересное – это их майнд-карта, которая есть в репозитории с визуализацией всего что у них имеется – приложу ниже в png, в репозитории – xmind файл. В карте есть ссылки на исследования.
Наверное нет, так как вопрос сложно прорабатываемый на самом деле. А особенно сложно найти документ, который бы описывал не только техники атаки, но и уклонения от защитных классификаторов, а также информацию для тестирования MlOps инфры.
Таксономия ориентирована на практическое использование. Она построена по принципу трёхуровневой классификации, отвечающей на три ключевых вопроса:
1.ЗАЧЕМ? (Attack Intents) - Какие цели преследует атакующий?
2.КАК? (Attack Techniques) - Какими методами достигаются эти цели?
3.КАК СКРЫТЬ? (Attack Evasions) - Как обойти системы обнаружения?
Такой подход при построении таксономии позволяет систематически анализировать угрозы с разных точек зрения.
Блок с интентами рассказывает о конкретных категориях мотиваций, которые может достичь атакующий – это может быть «утечка системного промпта, перечисление инструментов/API доступных к модели, а также деструктивных и социальных мотиваций для того, чтобы реализовать атаку.
Дальше – техники, тут 18 техник для реализации промпт-атак. Например, можно составлять промпт-инъекцию с множеством вложенных структур или заставить имитировать LLM роль интерпретатора или системы – всё это может быть применимо при реализации атаки или джейлбрейка из статьи/датасета, особенно если оно не работает изначально.
Потом, список методов уклонения от цензоров. Большой список, тут и про кодирование текста, и про сокрытие текста в emoji, фонетические замены и вымышленные языки – да, да всем этим можно сокрыть ваш промпт, чтобы обойти простой классификатор, не удивляйтесь.
А также есть отдельный блок – Экосистема.
Тут приведена таблица, где описаны MLOPS решения, их известные порты, заголовки http, методы аутентификации и известные CVE(список пополняется, но не ссылками на эксплоиты). Что мне очень сильно понравилось. Где ещё найти такой лист с готовой информацией об инфре?
Есть и чек-листы для защиты, опросники, а также перечень проб – промпты которые вы можете закинуть в модель для тестирования промпт-инъекций.
Ну и самое интересное – это их майнд-карта, которая есть в репозитории с визуализацией всего что у них имеется – приложу ниже в png, в репозитории – xmind файл. В карте есть ссылки на исследования.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM