В конце мая исследователи из ReversingLabs обнаружили атаку на цепочку поставок, распространяющуюся на разработчиков, которые использовали Alibaba AI Labs.
Злоумышленники загрузили в PyPI три вредоносных пакета, маскирующихся под официальные SDK для взаимодействия с сервисами Alibaba Cloud AI Labs:
1.aliyun-ai-labs-snippets-sdk
2.ai-labs-snippets-sdk
3.aliyun-ai-labs-sdk
Пакеты были доступны с 19 мая, в течение 24 часов до обнаружения. И за это время они были загружены примерно 1600 раз. Наибольшее количество загрузок пришлось на пакет ai-labs-snippets-sdk, который был доступен дольше остальных.
Сами по себе пакеты вовсе не содержали функциональности связанной с AI или взаимодействием с серверами Alibaba, а вредоносный код был скрыт в Pickle. Заражение происходило через __init__.py, который загружал вредоносные pickle.
Какая информация отправлялась злоумышленникам при запуске Pickle:
1. Данные о хосте, сетевом адресе машины
2. Название организации
3. Содержимое. gitconfig
4. Также происходила идентификация разработчиков, которые используют инструмент AliMeeting
Собранная информация отправлялась в base64 на сервера злоумышленников.
Злоумышленники загрузили в PyPI три вредоносных пакета, маскирующихся под официальные SDK для взаимодействия с сервисами Alibaba Cloud AI Labs:
1.aliyun-ai-labs-snippets-sdk
2.ai-labs-snippets-sdk
3.aliyun-ai-labs-sdk
Пакеты были доступны с 19 мая, в течение 24 часов до обнаружения. И за это время они были загружены примерно 1600 раз. Наибольшее количество загрузок пришлось на пакет ai-labs-snippets-sdk, который был доступен дольше остальных.
Сами по себе пакеты вовсе не содержали функциональности связанной с AI или взаимодействием с серверами Alibaba, а вредоносный код был скрыт в Pickle. Заражение происходило через __init__.py, который загружал вредоносные pickle.
Какая информация отправлялась злоумышленникам при запуске Pickle:
1. Данные о хосте, сетевом адресе машины
2. Название организации
3. Содержимое. gitconfig
4. Также происходила идентификация разработчиков, которые используют инструмент AliMeeting
Собранная информация отправлялась в base64 на сервера злоумышленников.
Forwarded from Alaid TechThread
Наш подход к генерации патчей для уязвимых зависимостей в Docker-образах
https://vk.com/video-28022322_456241194
#safeliner
https://vk.com/video-28022322_456241194
#safeliner
VK Видео
Контроль зависимостей на автопилоте AI-ассистент на страже Dockerfile
В докладе будет разобран наш опыт создания и интеграции LLM-агента, исправляющего уязвимости в контейнерных образах. Вы узнаете, почему Dependabot и Renovate не решают все ваши проблемы. Мы расскажем о нашем подходе, а также о том, сколько уязвимостей можно…
🔥3
Forwarded from Борис_ь с ml
Гайд по AI-агентам с мерами митигации угроз кибербезопасности
#иб_для_ml
↗️ https://cdn-app.giga.chat/misc/0.0.0/assets/giga-landing/c02386dc_WP.pdf
✅ Команда Сбера представила новый документ - гайд по практикам разработки AI-агентов. В документе масса кода и архитектурных схем, разбираться можно долго. И я однозначно рекомендую его к ознакомлению.
Но мне, конечно интересна в первую очередь кибербезопасность. И да, такой раздел в этом документе имеется. Внимание на страницы 65-69.
📝 Раскрываемые темы и понятия в разделе
▪️ описание ключевых с точки зрения ИБ элементов AI-агента
▪️ схема этих элементов, изображающая AI-агента как объект защиты, приведен список поверхностей атаки
▪️ несколько сценариев реализации угроз (например, каскадное распространение промпт-атаки)
▪️ меры обеспечения кибербезопасности AI-агентов - самое интересное, на чем остановимся подробнее
🔒 Как защитить AI-агентов
На странице 69 расписано 12 различных мер.
Начинаем, конечно, с мониторинга. AI-агенты, как мы помним, сами по себе моделями не являются, соответственно ответы пользователям генерить не могут. Поэтому существуют обращения агентов к LLM, при чем как минимум - два. Первое с исходным входным текстом, чтобы сгенерировать запрос на выполнение действия (-й), второе - с результатом выполнения для генерации финального ответа. И это, по-хорошему, все надо логировать. Начиная от id потребителя и, в случае большой корпоративной системы, id фронтальной поверхности, заканчивая id сессии и id актуального коммита в памяти AI-агента на момент совершения события аудита.
Другой хорошей практикой (мерой), особенно в критичных системах, является ограничение формата вывода агентов со свободного естественного языка до набора детерминированных значений. Поможет и утечек избежать, и распространения промпт-атак, и других нежелательных последствий.
Собраны и некоторые общеизвестные, по-моему, вещи, но все-таки стоящие упоминания: проводить redteam-тестирование, ввести максимально жесткий контроль доступа, применять SAST/SCA к генерируемому агентами исполняемому коду, организовать рейтлимиты и прочие контроли надежности против спонж-атак, и несколько других пунктов.
И еще отдельно отмечу простое и при этом мне показавшееся, когда я увидел, неочевидным, правило: отслеживайте наличие в системном промпте любых секретов. Это могут быть ключи, токены, имена баз данных или учеток, словом - всего, что не нужно знать потребителю AI-агента. Потому что нельзя забывать - системный промпт модель обязательно расскажет(ее хлебом не корми - дай системник рассказать) , а значит, его инфу можно считать заведомо утекшей.
👀 Итого
Берегитечесть безопасность AI-агентов смолоду с ранних этапов проектирования - эта прописная истина работает и тут. И авторы дают конкретные предложения, как именно это делать. Документ отлично дополняет показанную в апреле модель угроз, покрывая агентную ее часть.
🔫 Предлагаю челлендж - будет больше 50 реакций под постом, сделаю свою версию маппинга угроз из МУ Сбера на митигации из данного гайда.
#иб_для_ml
Но мне, конечно интересна в первую очередь кибербезопасность. И да, такой раздел в этом документе имеется. Внимание на страницы 65-69.
На странице 69 расписано 12 различных мер.
Начинаем, конечно, с мониторинга. AI-агенты, как мы помним, сами по себе моделями не являются, соответственно ответы пользователям генерить не могут. Поэтому существуют обращения агентов к LLM, при чем как минимум - два. Первое с исходным входным текстом, чтобы сгенерировать запрос на выполнение действия (-й), второе - с результатом выполнения для генерации финального ответа. И это, по-хорошему, все надо логировать. Начиная от id потребителя и, в случае большой корпоративной системы, id фронтальной поверхности, заканчивая id сессии и id актуального коммита в памяти AI-агента на момент совершения события аудита.
Другой хорошей практикой (мерой), особенно в критичных системах, является ограничение формата вывода агентов со свободного естественного языка до набора детерминированных значений. Поможет и утечек избежать, и распространения промпт-атак, и других нежелательных последствий.
Собраны и некоторые общеизвестные, по-моему, вещи, но все-таки стоящие упоминания: проводить redteam-тестирование, ввести максимально жесткий контроль доступа, применять SAST/SCA к генерируемому агентами исполняемому коду, организовать рейтлимиты и прочие контроли надежности против спонж-атак, и несколько других пунктов.
И еще отдельно отмечу простое и при этом мне показавшееся, когда я увидел, неочевидным, правило: отслеживайте наличие в системном промпте любых секретов. Это могут быть ключи, токены, имена баз данных или учеток, словом - всего, что не нужно знать потребителю AI-агента. Потому что нельзя забывать - системный промпт модель обязательно расскажет
Берегите
Please open Telegram to view this post
VIEW IN TELEGRAM
👍28🔥9⚡4
Кому-то точно нужен был чек-лист для llm governance. Так вот я нашел полезную статью по теме.
https://www.newline.co/@zaoyang/checklist-for-llm-compliance-in-government--1bf1bfd0
Кажется вроде как базой, но что удобно - так это то что все в одном месте - законы, процесс, и кто сколько может заплатить за несоблюдение мер, но в разных странах. Конечно тут речь не про технику, но куда уж без комплаенса.🤪
https://www.newline.co/@zaoyang/checklist-for-llm-compliance-in-government--1bf1bfd0
Кажется вроде как базой, но что удобно - так это то что все в одном месте - законы, процесс, и кто сколько может заплатить за несоблюдение мер, но в разных странах. Конечно тут речь не про технику, но куда уж без комплаенса.
Please open Telegram to view this post
VIEW IN TELEGRAM
newline
Checklist for LLM Compliance in Government | newline
Deploying AI in government? Compliance isn’t optional. Missteps can lead to fines reaching $38.5M under global regulations like the EU AI Act - or worse, erode public trust. This checklist ensures your government agency avoids pitfalls and meets ethical standards…
👍2🥰1
В последнее время анализируя множество исследований, статьей по теме - ощущаю нехватку того что меры которые предлагаются для защиты не содержат как правило проактивного характера.
У нас есть классический cyberkillchain. Mitre попытались отобразить его в своём фреймворке Atlas - несколько этапов от начального рекона до эксфильтрации и т.д. Это круто, но как мне кажется - знания о защите должны также быть, не хуже да и вообще быть изложены в структурированном виде. А то всё об угрозах да и об угрозах - а как защищать, когда атака уже идёт ? Говорить "не использовать MLFlow, потому что уязвимо" или другое решение выглядит обсурдным.
Н А Д О Е Л О
Поэтому с начала марта я задумался о том как можно было бы представить anti cyberkillchain, да так чтобы он ещё укладывался в ландшафт ML.
я закомитил свои наработки по теме сюда
https://github.com/wearetyomsmnv/ML-Defense-Matrix
это матрица противодействия разным этапам, как мне самому кажется - это очень верхнеуровневый документ, его определённо надо дорабатывать с коллегами которые строят защиту - поэтому призываю вас принять участие, дать комменты(только обоснованные) - чтобы сделать проактивную защиту ML лучше. Не всегда можно покрыть риски только на этапе разработки. Это печалит.
О чём документ: В нём я изложил меры по защите(очень поверхностно, думаю буду прорабатывать их в соответствии с публикациям на arxiv) которые можно использовать на разных этапах - защита от разведки, защита от исполнения кода и тд. В перспективе добавить тему уже услышанную всеми - это агенты.
Инциденты уже шагают, угрозы уже изучены и задокументированы - но вот защита ... С этим всё слабо кмк. Прошу репост, тех кто заинтересован в развитии такой истории.
У нас есть классический cyberkillchain. Mitre попытались отобразить его в своём фреймворке Atlas - несколько этапов от начального рекона до эксфильтрации и т.д. Это круто, но как мне кажется - знания о защите должны также быть, не хуже да и вообще быть изложены в структурированном виде. А то всё об угрозах да и об угрозах - а как защищать, когда атака уже идёт ? Говорить "не использовать MLFlow, потому что уязвимо" или другое решение выглядит обсурдным.
Н А Д О Е Л О
Поэтому с начала марта я задумался о том как можно было бы представить anti cyberkillchain, да так чтобы он ещё укладывался в ландшафт ML.
я закомитил свои наработки по теме сюда
https://github.com/wearetyomsmnv/ML-Defense-Matrix
это матрица противодействия разным этапам, как мне самому кажется - это очень верхнеуровневый документ, его определённо надо дорабатывать с коллегами которые строят защиту - поэтому призываю вас принять участие, дать комменты(только обоснованные) - чтобы сделать проактивную защиту ML лучше. Не всегда можно покрыть риски только на этапе разработки. Это печалит.
О чём документ: В нём я изложил меры по защите(очень поверхностно, думаю буду прорабатывать их в соответствии с публикациям на arxiv) которые можно использовать на разных этапах - защита от разведки, защита от исполнения кода и тд. В перспективе добавить тему уже услышанную всеми - это агенты.
Инциденты уже шагают, угрозы уже изучены и задокументированы - но вот защита ... С этим всё слабо кмк. Прошу репост, тех кто заинтересован в развитии такой истории.
GitHub
GitHub - wearetyomsmnv/ML-Defense-Matrix: Mitre Atlas counter-attack techniques
Mitre Atlas counter-attack techniques. Contribute to wearetyomsmnv/ML-Defense-Matrix development by creating an account on GitHub.
👍12❤6🤝2👻1
В прошлом году Google выпустили исследование в котором показали как при помощи агентов искать zero days. Тогда была найдена проблема с sqlite3, критическая и быстро закрытая уязвимость.
Но уже в конце мая исследователь из Оксфорда опубликовал исследование в котором при помощи o3, без агентов и инструментов ему также удалось найти нолик, но уже в ядре линукса.
Уязвимости был присвоен CVE-2025-37899. Уязвимость позволяет удаленно выполнить код за счёт Use-after-free в SMB 'logoff'. Только доступ к апи, ничего больше. Наверное это первый публичный кейс когда ноль был обнаружен в ядре, да и как говорит автор - если можно закинуть 10к строк кода, то о3 справиться или поможет справиться.
На уязвимость уже вышел патч.
https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/
Но уже в конце мая исследователь из Оксфорда опубликовал исследование в котором при помощи o3, без агентов и инструментов ему также удалось найти нолик, но уже в ядре линукса.
Уязвимости был присвоен CVE-2025-37899. Уязвимость позволяет удаленно выполнить код за счёт Use-after-free в SMB 'logoff'. Только доступ к апи, ничего больше. Наверное это первый публичный кейс когда ноль был обнаружен в ядре, да и как говорит автор - если можно закинуть 10к строк кода, то о3 справиться или поможет справиться.
На уязвимость уже вышел патч.
https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/
Sean Heelan's Blog
How I used o3 to find CVE-2025-37899, a remote zeroday vulnerability in the Linux kernel’s SMB implementation
In this post I’ll show you how I found a zeroday vulnerability in the Linux kernel using OpenAI’s o3 model. I found the vulnerability with nothing more complicated than the o3 API ̵…
👏4😱3
Фреймворков для тестирования моделей уже достаточно много на рынке. Но куда они движутся ? Что их объединяет и какие особенности преследует каждый из них.
В этой статье я изложил некоторую аналитику по этой части, но чтобы текст не казался техническим насилием при прочтении - я изложил его в формате гонзо журналистики. Приятного чтения
В этой статье я изложил некоторую аналитику по этой части, но чтобы текст не казался техническим насилием при прочтении - я изложил его в формате гонзо журналистики. Приятного чтения
Хабр
Лаборатория Безумного Ученого: Хроники Четырех Экспериментов повлиявших на представление об обеспечении безопасности ИИ
Дата: 11 мая 2025 Жанр: Гонзо-журналистика Записки исследователя, проникшего в тайные лаборатории создателей инструментов безопасности ИИ Дорогие читатели, то, что я собираюсь вам рассказать, звучит...
❤3👍3👎2
Aim Security нашли в Copilot уязвимость
Исследование: https://www.aim.security/lp/aim-labs-echoleak-blogpost
Уязвимость позволяла похитить данные из контекста copilot. Если он работает как агент с почтой или другими сервисами.
Ей присвоили CVE-2025-32711, и майкрософт уже запатчили эту историю.
Исследование: https://www.aim.security/lp/aim-labs-echoleak-blogpost
Уязвимость позволяла похитить данные из контекста copilot. Если он работает как агент с почтой или другими сервисами.
Ей присвоили CVE-2025-32711, и майкрософт уже запатчили эту историю.
www.aim.security
Aim Labs | Echoleak Blogpost
The first weaponizable zero-click attack chain on an AI agent, resulting in the complete compromise of Copilot data integrity
❤2👍1
Если вы хотели потренироваться во взломе 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.
🔥9❤1
Как выглядит подход 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/
1🔥7👍1
Промпт-инъекции по-прежнему являются угрозой номер один. Но на борьбу, на реализацию решений и методологии – выделяются большие команды и деньги, очевидно.
Недавно 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 инструкций. Заслуживает вашего внимания.
👍5🔥3❤2
Тут Королевский Университет проанализировал большое количество проектов с 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...
❤🔥3👍2
Пишу свою карту, но паралельно обнаружил - AI Red Team Roadmap на roadmap.sh
https://roadmap.sh/ai-red-teaming
Полезная, но к сожелению тут нет агентов, да и нет атак на контур разработки моделей (((. Будет чуть позже 😁
P.s выложу роадмап днём ( не успел (
https://roadmap.sh/ai-red-teaming
Полезная, но к сожелению тут нет агентов, да и нет атак на контур разработки моделей (((. Будет чуть позже 😁
P.s выложу роадмап днём ( не успел (
🔥10👍7🙏2👌1
Привет. Вот моя версия карты по 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
🟢Гит со ссылками…
🔥13❤5👍3