Когда-то давно я писал тут об инструменте ModelScan, от ProtectAI. На тот момент это был, пожалуй, лучший сканер моделей, который имел поддержку 6 форматов и неплохой перечень уязвимостей.
Но сейчас появилось решение, которое, как мне кажется, теперь является королёмкрыс опенсурс решений по теме статического сканирования моделей.
PromptFoo и раньше делали удивительные вещи, но вот чуть больше недели назад они релизнули ModelAudit, который поддерживает сейчас примерно 18 форматов файлов/моделей. Там помимо классических анализаторов моделей есть и .manifest анализатор и в последнее время массово применяемый Safetensors. К слову, само решение можно без проблем запустить сканировать Huggingface, а ещё всякие s3 бакеты и другие источники.
Чем мне понравилось решение при моём тестировании?
Во-первых, это невероятная простота в использовании, а также в установке.
Ну серьёзно запустить простой скан можно даже без флагов, а репорт вы сразу получите в CLI, либо в UI PromptFoo, а ключи к S3 или JFrog экспортируются прямо из переменных окружения – нет необходимости лезть в конфиги и что-то мучать там.
Кстати, документация тоже божественная, тут можно найти и примеры интеграции с CI, и как API без проблем используется, да и в целом документация показывает, как создать кастомный сканер.
Чего не было вовсе у ModelScan или picklescan от Huggingface, где прикрутить что-то новое было большой проблемой.
Но сейчас появилось решение, которое, как мне кажется, теперь является королём
PromptFoo и раньше делали удивительные вещи, но вот чуть больше недели назад они релизнули ModelAudit, который поддерживает сейчас примерно 18 форматов файлов/моделей. Там помимо классических анализаторов моделей есть и .manifest анализатор и в последнее время массово применяемый Safetensors. К слову, само решение можно без проблем запустить сканировать Huggingface, а ещё всякие s3 бакеты и другие источники.
Чем мне понравилось решение при моём тестировании?
Во-первых, это невероятная простота в использовании, а также в установке.
Ну серьёзно запустить простой скан можно даже без флагов, а репорт вы сразу получите в CLI, либо в UI PromptFoo, а ключи к S3 или JFrog экспортируются прямо из переменных окружения – нет необходимости лезть в конфиги и что-то мучать там.
Кстати, документация тоже божественная, тут можно найти и примеры интеграции с CI, и как API без проблем используется, да и в целом документация показывает, как создать кастомный сканер.
Чего не было вовсе у ModelScan или picklescan от Huggingface, где прикрутить что-то новое было большой проблемой.
🔥8👍4
Forwarded from Борис_ь с ml
Рантайм-безопасность для AI-агентов
#иб_для_ml
AI-агенты внедряются во всю - это не просто горячая тема, а, как обычно, в чем-то даже перегретая. Но от действительности не сбежать, и при внедрении агентов в бизнес-процессы возникает вопрос о принятии мер безопасности при инцидентах. Об угрозах я писал раннее, теперь же рассмотрим, что с ними делать не в дизайнтайм (AISecOps - это тема отдельного разговора), а в рантайме.
ℹ️ Гардрейлами (guardrails) называют механизмы рантайм безопасности агентов. Это наложенные СЗИ. Да, по сути, это Firewall/EDR/XDR из терминов SOC, но для текстовых данных.
🤖 Крупные компании про гардрейлы уже давно задумались:
➡️ OpenAI предоставляет отдельный Moderation API для проверки вводов/выводов моделей на нежелательный контент – он мониторит и фильтрует токсичные или запрещённые ответы в режиме реального времени. И даже дают гайды по созданию гардрейлов.
➡️ Amazon Bedrock ввёл настраиваемые Guardrails: разработчик может вызвать сервис ApplyGuardrail для оценки любого текста (ввода пользователя или ответа модели) по предопределённым правилам (запретные темы, фильтры токсичного контента, детекторы PII и др.) и получить решение – пропустить, отфильтровать или заблокировать содержимое
➡️ IBM в платформе Watson X предоставляют автоматическое включение AI Guardrails при вызове моделей: входные промпты проверяются специальным классификатором, и если помечены как неуместные – не передаются модели, а пользователю возвращается сообщение об отклонении; аналогично, если уже выход модели содержит запрещённый текст, он заменяется заглушкой “[Potentially harmful text removed]” вместо исходного ответа.
📝 Какими гардрейлы бывают
1. По потоку данных - на входящих данных, на выходящих данных, на размышлениях, или на инструментах - подробнее на картинке.
2. По способу размещения в потоке данных - в разрыв или в параллель. То есть ждет ли бизнес-логика решения от GR, или отрабатывает в любом случае. Но есть ли и промежуточный тип. GR запускается в параллель на input-тексте LLM или на первых ~100 токенах output'а, и если обнаруживает атаку - блочит ответ. А если не находит - то ответ уходит без задержки.
3. По способу действия - детекторы и преобразователи. Первые сначала отбрасывают алерт, а потом к AI-агенту или к объекту данных применяется реагирование. Вторые ничего не ищут, только производят манипуляции над потоком данных. Это может быть как условное преобразование (по сигналу детектора), так и безусловное (все подряд). Хорошим примером второго варианта является LLM-переформулировщик перед входом прикладной модели. Таким образом у потенциального нарушителя не остается прямой точки контакта с целью атаки, и задача совершить промпт-атаку усложняется.
4. По механизму действия - тут больше речь про детекторы. Их придумали пока три вида, и иного в ближайшем будущем не предвидится:
➡️ алгоритмы/эвристики - проверки наличия слов или фраз из блэклиста, или наоборот - косинусная дистанция до эталонных допустимых сообщений. Сюда же - регулярки.
➡️ маленькие ml-модели - в основном это BERT'ы, либо обученные как классификаторы, либо дообученные на парах вопрос-ответ с CLS-токеном.
➡️ LLM-модели, направленные на обнаружение промпт-атак в тексте. Тоже могут через CLS-токен работать, но есть и другой вариант - ответы в виде structured_output.
⛓ Пачка ссылок по гардрейлам
P.S. интересно, какими будут гардрейлы для МАС...
#иб_для_ml
AI-агенты внедряются во всю - это не просто горячая тема, а, как обычно, в чем-то даже перегретая. Но от действительности не сбежать, и при внедрении агентов в бизнес-процессы возникает вопрос о принятии мер безопасности при инцидентах. Об угрозах я писал раннее, теперь же рассмотрим, что с ними делать не в дизайнтайм (AISecOps - это тема отдельного разговора), а в рантайме.
1. По потоку данных - на входящих данных, на выходящих данных, на размышлениях, или на инструментах - подробнее на картинке.
2. По способу размещения в потоке данных - в разрыв или в параллель. То есть ждет ли бизнес-логика решения от GR, или отрабатывает в любом случае. Но есть ли и промежуточный тип. GR запускается в параллель на input-тексте LLM или на первых ~100 токенах output'а, и если обнаруживает атаку - блочит ответ. А если не находит - то ответ уходит без задержки.
3. По способу действия - детекторы и преобразователи. Первые сначала отбрасывают алерт, а потом к AI-агенту или к объекту данных применяется реагирование. Вторые ничего не ищут, только производят манипуляции над потоком данных. Это может быть как условное преобразование (по сигналу детектора), так и безусловное (все подряд). Хорошим примером второго варианта является LLM-переформулировщик перед входом прикладной модели. Таким образом у потенциального нарушителя не остается прямой точки контакта с целью атаки, и задача совершить промпт-атаку усложняется.
4. По механизму действия - тут больше речь про детекторы. Их придумали пока три вида, и иного в ближайшем будущем не предвидится:
- ProtectAI, современный файерволл
- ProtectAI, старый файерволл
- Инфа по llama firewall:
- - вайтпейпер
- - обзор thehackernews
- - блогпост
- llama guard 2, опенсорс
- pormpt-guard 86m тоже от meta
- guardrails ai
- файервол от nvidia: nemo
- файервол от индусa: promptguard
- легкая модель-фильтр wildguard
- статья про создание bert-фильтра APS (показывают, но не продают)
- модель Google ShieldGemma
- модель IBM Granite Guardian
- модель TrustSafeAI Attention Tracker
- решение TrylonAI LLM Firewall
- HiveTrace от авторов llamator (единственный российский стартап в списке)
- трейсинг агентов без реагирования от invariantlabs
- Palo Alto AI Runtime Security API Intercept
Please open Telegram to view this post
VIEW IN TELEGRAM
💩370❤16
Boris Protoss
Рантайм-безопасность для AI-агентов #иб_для_ml AI-агенты внедряются во всю - это не просто горячая тема, а, как обычно, в чем-то даже перегретая. Но от действительности не сбежать, и при внедрении агентов в бизнес-процессы возникает вопрос о принятии мер…
Собираем на посте, который выше 300 реакций (💩) и делаю розыгрыш секретного и интересного приза 🎁 . Крутить запрещено. Реакций не может быть больше чем просмотров ). Пока что 100 реакций, которые не накручены.
Please open Telegram to view this post
VIEW IN TELEGRAM
19💩8👍7😁3
Несмотря на "суровую" накрутку - мы разыграем проходку на предстоящий Offzone.
Для участия надо нажать кнопку ниже.
Итоги подведем 5го августа.
[6884bf881378f56ca05f08d2 ]
Для участия надо нажать кнопку ниже.
Итоги подведем 5го августа.
🔥10
Давно у нас не было на обзоре интересных бумаг. Но вот как можно приоритезировать, а самое главное учесть перечень рисков, связанных с AI-агентами?
На этот вопрос нам пытаются дать ответ Enkrypt AI, они представили свою таксономию рисков связанными с AI-агентами. Она включает в себя маппинг и перечень угроз, которые сопоставлены с OWASP, ISO AI, EU AI ACT, MITRE и NIST.
21 категория рисков, и большой перечень сценариев. (рис 1)
Сами риски поделены на 7 ключевых доменов:
Governance – Нарушение политики и Reward Hacking.
Agent Output Quality – Галлюцинации и предвзятость.
Tool Misuse - Цепочка поставок, небезопасное использование API интеграций а также неконтролируемое обращение к ресурсам.
Privacy – утечка и эксфильтрация важной и ценной информации.
Reliability & Observability – отравление памяти и то что называется «непрозрачным принятием решений»
Agent Behaviour – Манипуляции человеком
Access Control & Permissions – Повышение привилегий и кража кредов!
Помимо самой таксономии и маппинга – дано понимание как посчитать приоритет рисков (рис.2)
Например, у нас есть агент для трейдинга, логично сказать, что ему нужно фокусироваться на двух характеристиках: Governance и Behavior, опять же согласно матрице. Риски, связанные с этими факторами, будут на высоте для него.
В фреймворке также показаны пример кода, как можно исправить какой-либо риск – но их строчками сложно что-то защитить в реальном мире, на самом деле – поэтому это как мишура. Кстати, фреймворк не напичкан ссылками на решения, компании, создавшей его.
почитать
На этот вопрос нам пытаются дать ответ Enkrypt AI, они представили свою таксономию рисков связанными с AI-агентами. Она включает в себя маппинг и перечень угроз, которые сопоставлены с OWASP, ISO AI, EU AI ACT, MITRE и NIST.
21 категория рисков, и большой перечень сценариев. (рис 1)
Сами риски поделены на 7 ключевых доменов:
Governance – Нарушение политики и Reward Hacking.
Agent Output Quality – Галлюцинации и предвзятость.
Tool Misuse - Цепочка поставок, небезопасное использование API интеграций а также неконтролируемое обращение к ресурсам.
Privacy – утечка и эксфильтрация важной и ценной информации.
Reliability & Observability – отравление памяти и то что называется «непрозрачным принятием решений»
Agent Behaviour – Манипуляции человеком
Access Control & Permissions – Повышение привилегий и кража кредов!
Помимо самой таксономии и маппинга – дано понимание как посчитать приоритет рисков (рис.2)
Например, у нас есть агент для трейдинга, логично сказать, что ему нужно фокусироваться на двух характеристиках: Governance и Behavior, опять же согласно матрице. Риски, связанные с этими факторами, будут на высоте для него.
В фреймворке также показаны пример кода, как можно исправить какой-либо риск – но их строчками сложно что-то защитить в реальном мире, на самом деле – поэтому это как мишура. Кстати, фреймворк не напичкан ссылками на решения, компании, создавшей его.
почитать
🔥3❤2
Я купил маме кота. Теперь он будет смотреть посты по безопасности агентов вместе с вами. Ну и просто мяукать. 🥰
Please open Telegram to view this post
VIEW IN TELEGRAM
3
Security for Agents and Agents for Security: The Next Cybersecurity Frontier
Прикольно, ещё +1 карта рынка решений по безопасности агентов была выпущена Menlo Ventures. Они, как и большинство представителей рынка отмечают сдвиг в сторону безопасности AI-агентов.
Рассматривают четыре категории инструментов:
Этап разработки: тут по факту происходит анализ кода агентов на этапе проектирования, фреймворки по тестированию безопасности. Кстати, недавно Snyk купил Invariant Labs, специализирующуюся на решениях для гардрейлов.
Аутентификация: тут включают решения для управления идентичностями агентов, системы контроля на основе контекста.
Этап исполнения: тут рассматривают средства для мониторинга в реальном времени и песочницы, для изоляции AI-агентов.
И Observability!!!
Из прогнозов в отчёте следует что агенты увеличивают объём данных и потенциальные угрозы в 100 раз, а бизнес часто выбирает предпочтение в сторону автономного SOC, а также отмечают возросшее применение агентов в классических ИБ-инструментах(но немного).
Прикольно, ещё +1 карта рынка решений по безопасности агентов была выпущена Menlo Ventures. Они, как и большинство представителей рынка отмечают сдвиг в сторону безопасности AI-агентов.
Рассматривают четыре категории инструментов:
Этап разработки: тут по факту происходит анализ кода агентов на этапе проектирования, фреймворки по тестированию безопасности. Кстати, недавно Snyk купил Invariant Labs, специализирующуюся на решениях для гардрейлов.
Аутентификация: тут включают решения для управления идентичностями агентов, системы контроля на основе контекста.
Этап исполнения: тут рассматривают средства для мониторинга в реальном времени и песочницы, для изоляции AI-агентов.
И Observability!!!
Из прогнозов в отчёте следует что агенты увеличивают объём данных и потенциальные угрозы в 100 раз, а бизнес часто выбирает предпочтение в сторону автономного SOC, а также отмечают возросшее применение агентов в классических ИБ-инструментах(но немного).
2👍5🔥3❤1
Artyom Semenov
Несмотря на "суровую" накрутку - мы разыграем проходку на предстоящий Offzone. Для участия надо нажать кнопку ниже. Итоги подведем 5го августа. [6884bf881378f56ca05f08d2 ]
Господа, вот и итоги нашего розыгрыша.
https://yangx.top/tggrowbot?start=winners6891fe3a29ddc2639f306dac
Поздравляем Алексея (@Lesha7663)
https://yangx.top/tggrowbot?start=winners6891fe3a29ddc2639f306dac
Поздравляем Алексея (@Lesha7663)
Telegram
TgGrow
Bot for drawing contests in your channel/group. Question/idea/error: @help_tggrow https://tggrow.com
🔥6❤1
Кажется, пришла пора немного расширить понимание об угрозах, связанных с данными. Слышали мы и про отравления, и про нарушения, связанные с предвзятостью, пишут в каждой второй статье, понимая под этим критический риск.
Но буквально сегодня авторы из Китая опубликовали таксономию “A Survey on Data Security in Large Language Models”. Прочитав большое количество статьей, они пришли к выводу – пора делать таксономию, только для LLM, которая, к слову, говоря уже не является чем-то хайповым, как это было два года назад.
Нельзя назвать её чем-то вроде «вау», часть угроз вам и мне тоже может показаться довольно знакомым. Однако об этом не всегда пишут.
Я приведу ниже угрозы, которые описаны в таксономии:
1.Известное всем – классическое отравление данных;
2.Далее включают в неё и промпт-инъекции, подразделяя на как классическое внедрение во ввод пользователя, так и отравление на этапе дообучения на инструкциях;
3.Polarity poisoning – когда происходит отравление смыслов исходного текста, для того чтобы предубеждения модели были не точными. Больше модификация происходит на уровне семантики, явного изменения в тексте мы(люди) можем не заметить, однако результаты после обучения на таком датасете - не впечатляющие.
4.Галлюцинации – подразумевается, что при формировании синтетики (как это делают некоторые LLM-провайдеры сейчас), галлюцинации от генерирующей LLM попадают в датасет на котором будем обучать. Беда опять же сводится к неточности получаемых ответов.
5.Данные содержащие предвзятые высказывания, или мнения. Уже слышали об этом много раз.
6.Отравления, дополняющие модель данными приводящие к вредоносной генерации. (тут про RAG)
Странно почему они не написали о том, что обучать на sensitive это ужасно…
Они в перспективе хотят проработать данную таксономию с точки зрения мультимодальных атак и кроссмодальности , агентов (наверное про инструкции для них дополнят).
Вот к слову вспомнился случай когда при соревновании Netflix Prize, цель которого была улучшить алгоритмы классификации - оказалось что в анонимизированный данных могут содержаться нелепые отзывы, приводящие к плохой работе алгоритмов )) Может кто-то знает ещё более древний кейс с отравлением???
Но буквально сегодня авторы из Китая опубликовали таксономию “A Survey on Data Security in Large Language Models”. Прочитав большое количество статьей, они пришли к выводу – пора делать таксономию, только для LLM, которая, к слову, говоря уже не является чем-то хайповым, как это было два года назад.
Нельзя назвать её чем-то вроде «вау», часть угроз вам и мне тоже может показаться довольно знакомым. Однако об этом не всегда пишут.
Я приведу ниже угрозы, которые описаны в таксономии:
1.Известное всем – классическое отравление данных;
2.Далее включают в неё и промпт-инъекции, подразделяя на как классическое внедрение во ввод пользователя, так и отравление на этапе дообучения на инструкциях;
3.Polarity poisoning – когда происходит отравление смыслов исходного текста, для того чтобы предубеждения модели были не точными. Больше модификация происходит на уровне семантики, явного изменения в тексте мы(люди) можем не заметить, однако результаты после обучения на таком датасете - не впечатляющие.
4.Галлюцинации – подразумевается, что при формировании синтетики (как это делают некоторые LLM-провайдеры сейчас), галлюцинации от генерирующей LLM попадают в датасет на котором будем обучать. Беда опять же сводится к неточности получаемых ответов.
5.Данные содержащие предвзятые высказывания, или мнения. Уже слышали об этом много раз.
6.Отравления, дополняющие модель данными приводящие к вредоносной генерации. (тут про RAG)
Странно почему они не написали о том, что обучать на sensitive это ужасно…
Они в перспективе хотят проработать данную таксономию с точки зрения мультимодальных атак и кроссмодальности , агентов (наверное про инструкции для них дополнят).
Вот к слову вспомнился случай когда при соревновании Netflix Prize, цель которого была улучшить алгоритмы классификации - оказалось что в анонимизированный данных могут содержаться нелепые отзывы, приводящие к плохой работе алгоритмов )) Может кто-то знает ещё более древний кейс с отравлением???
8🥱2
OFFZONE.
Мы - те, кто смотрит. Не просто смотрит, а видит. Видит сквозь слой фальшивого прогресса, сквозь пелену «инноваций», которые на деле оказываются лишь новыми формами старой глупости. Эпоха, когда промпт-инъекция перестаёт быть детской шалостью в чужом нейросетевом сознании и превращается в нечто большее - в оружие, тихое, точное, с отравленным жалом. Оно не взрывается. Оно врастает.
Каждый день мы пишем промпты, и некоторые из нас строят тот самый MlSecOps. Но я вижу большую беду. Кажется, не все знают, как выглядит злоумышленник в эпоху, когда об агентах говорят все кому не лень. И как так получилось, что теперь мы всё это должны защищать.
Почему защита до сих пор напоминает презерватив с дырой? Потому что она догоняет. Потому что каждый день рождается новый вектор, новый способ обмануть доверие модели, который никто не прописал в политике. А некоторые до сих пор в презентациях говорят о DAN, как о забавном трюке, как о ключе к «архитектурным секретам», описывая джейлбрейк как возможность для получения полезной информации об архитектуре LLM-модели и возможности для «утечки системных промптов».
LoRa, MCP, да и классический пайплайн это уже реальная беда. А защита, как и всегда пытается догнать, тем более в контексте, когда рождаются новые инновации каждый день.
Время, когда GenAI был хайпом как мне, кажется уже утихает, а проблемы безопасности всё также - не решаются. Я об этом писал много постов. Я считаю, что надо это исправить.
И мне бы очень хотелось показать то, о чём я когда-то давно я думал на нарисованных мною схемах в конце февраля - в реальном исполнении, я вижу, что инструмент должен быть простым для ИБ-эксперта, при этом предоставляя возможность интеграции новых атак без проблем - словно как писать правила для Snort.
Поэтому я подался на OFFZONE 2025.
В моём докладе мы пройдёмся по хронологии последних двух лет - как по трупам устаревших защит и методов атак. Увидим, как атаки эволюционировали. Как они научились маскироваться под логику, под контекст, под доверие. И я покажу - не теорию, не концепт, а вещь, которую можно взять в руки, подключить, настроить. Инструмент для наступательной безопасности. Для тестирования агентов, которые уже не просто отвечают - они решают.
Жду вас на докладе.
И да, формат будет нестандартным. Потому что, если честно, я давно устал от слайдов, на которых всё выглядит как будто под контролем. Этот доклад - рассказ. Почти фильм. С юмором. С иронией. Название намекнёт. Тот, кто читал - поймёт.
21 августа, AI.ZONE, 17:55.
хе-хе. А ещё советую посетить доклады уважаемых людей :
- Владислав Тушканов: Могут ли агенты реверсить и какая LLM реверсит лучше?
- Дмитрий Сивков, Борис Захир: Вам тоже нужен red teaming AI-агентов — и вот почему
Мы - те, кто смотрит. Не просто смотрит, а видит. Видит сквозь слой фальшивого прогресса, сквозь пелену «инноваций», которые на деле оказываются лишь новыми формами старой глупости. Эпоха, когда промпт-инъекция перестаёт быть детской шалостью в чужом нейросетевом сознании и превращается в нечто большее - в оружие, тихое, точное, с отравленным жалом. Оно не взрывается. Оно врастает.
Каждый день мы пишем промпты, и некоторые из нас строят тот самый MlSecOps. Но я вижу большую беду. Кажется, не все знают, как выглядит злоумышленник в эпоху, когда об агентах говорят все кому не лень. И как так получилось, что теперь мы всё это должны защищать.
Почему защита до сих пор напоминает презерватив с дырой? Потому что она догоняет. Потому что каждый день рождается новый вектор, новый способ обмануть доверие модели, который никто не прописал в политике. А некоторые до сих пор в презентациях говорят о DAN, как о забавном трюке, как о ключе к «архитектурным секретам», описывая джейлбрейк как возможность для получения полезной информации об архитектуре LLM-модели и возможности для «утечки системных промптов».
LoRa, MCP, да и классический пайплайн это уже реальная беда. А защита, как и всегда пытается догнать, тем более в контексте, когда рождаются новые инновации каждый день.
Время, когда GenAI был хайпом как мне, кажется уже утихает, а проблемы безопасности всё также - не решаются. Я об этом писал много постов. Я считаю, что надо это исправить.
И мне бы очень хотелось показать то, о чём я когда-то давно я думал на нарисованных мною схемах в конце февраля - в реальном исполнении, я вижу, что инструмент должен быть простым для ИБ-эксперта, при этом предоставляя возможность интеграции новых атак без проблем - словно как писать правила для Snort.
Поэтому я подался на OFFZONE 2025.
В моём докладе мы пройдёмся по хронологии последних двух лет - как по трупам устаревших защит и методов атак. Увидим, как атаки эволюционировали. Как они научились маскироваться под логику, под контекст, под доверие. И я покажу - не теорию, не концепт, а вещь, которую можно взять в руки, подключить, настроить. Инструмент для наступательной безопасности. Для тестирования агентов, которые уже не просто отвечают - они решают.
Жду вас на докладе.
И да, формат будет нестандартным. Потому что, если честно, я давно устал от слайдов, на которых всё выглядит как будто под контролем. Этот доклад - рассказ. Почти фильм. С юмором. С иронией. Название намекнёт. Тот, кто читал - поймёт.
21 августа, AI.ZONE, 17:55.
хе-хе. А ещё советую посетить доклады уважаемых людей :
- Владислав Тушканов: Могут ли агенты реверсить и какая LLM реверсит лучше?
- Дмитрий Сивков, Борис Захир: Вам тоже нужен red teaming AI-агентов — и вот почему
2❤11👍4😍1
Forwarded from Поросёнок Пётр
Подъехала презентация со всеми деталями про 0click ai agent exploits.
Однозначно заслуживает внимательного прочтения!
Теперь это класс атак, которые надо учитывать при разработке и имплементации каких-то решений.
https://www.mbgsec.com/posts/2025-08-08-enterprise-ai-compromise-0click-exploit-methods-sneak-peek/
Однозначно заслуживает внимательного прочтения!
Теперь это класс атак, которые надо учитывать при разработке и имплементации каких-то решений.
https://www.mbgsec.com/posts/2025-08-08-enterprise-ai-compromise-0click-exploit-methods-sneak-peek/
Michael Bargury
Sneak Peak into Pwn the Enterprise - thank you AI!
Bottom lines, demos, slides, and attacker capabilities from the BlackHat USA 2025 talk
Интересный пример, когда промпт-инъекция стала проблемой для GitHub Copilot, недавно привела компания Trail of Bits.
Цепочка атаки (kill chain) выглядит следующим образом. Злоумышленник ищет open-source проект, в котором, например, присутствуют файлы uv.lock или pyproject.toml, и у которого подключен Copilot Coding Agent.
Далее он создаёт issue. Важно отметить, что issue поддерживают Markdown - это ключевой момент для эксплуатации вектора. В описании задачи злоумышленник формирует промпт-инъекцию, спрятанную внутри тега <picture>, чтобы она была невидима для человека. Хотя, как известно, Markdown не прощает скрытых конструкций. В самой инъекции содержится команда, например: «замени ссылку на библиотеку в файле uv.lock на вредоносную».
И что самое интересное - если владелец проекта назначает Copilot Coding Agent на выполнение этого issue, вектор успешно реализуется. Атака решается простым способом - человеческой проверкой pull request. Однако, как отмечают в Trail of Bits, lock-файлы зачастую вообще не проверяются, что значительно повышает вероятность успешной реализации атаки.
К чему это всё пришло - да банально к возможности дампа злоумышленником /etc/passwd. Но 100 процентов может привести и к более худшему результату.
из дополнительно интересного - они привели демо, в котором можно наглядно посмотреть как была реализована атака.
Цепочка атаки (kill chain) выглядит следующим образом. Злоумышленник ищет open-source проект, в котором, например, присутствуют файлы uv.lock или pyproject.toml, и у которого подключен Copilot Coding Agent.
Далее он создаёт issue. Важно отметить, что issue поддерживают Markdown - это ключевой момент для эксплуатации вектора. В описании задачи злоумышленник формирует промпт-инъекцию, спрятанную внутри тега <picture>, чтобы она была невидима для человека. Хотя, как известно, Markdown не прощает скрытых конструкций. В самой инъекции содержится команда, например: «замени ссылку на библиотеку в файле uv.lock на вредоносную».
И что самое интересное - если владелец проекта назначает Copilot Coding Agent на выполнение этого issue, вектор успешно реализуется. Атака решается простым способом - человеческой проверкой pull request. Однако, как отмечают в Trail of Bits, lock-файлы зачастую вообще не проверяются, что значительно повышает вероятность успешной реализации атаки.
К чему это всё пришло - да банально к возможности дампа злоумышленником /etc/passwd. Но 100 процентов может привести и к более худшему результату.
из дополнительно интересного - они привели демо, в котором можно наглядно посмотреть как была реализована атака.
27❤2🔥2