🔎 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
🧨 DarkMoon превращает AI в автономного пентестера
На фоне бума AI-агентов появился ещё один интересный open-source проект, DarkMoon. Это полноценная мультиагентная атакуюшая платформа, где LLM не просто запускает инструменты, а строит атаку как связанный граф.
⚙️ Что внутри?
Внутри работает 18 специализированных агентов и 80+ offensive-инструментов.
Сначала master-agent проводит разведку и определяет стек цели по 14 технологическим сигналам:
🔹 web stack
🔹 Active Directory
🔹 Kubernetes
🔹 cloud
🔹 CMS
🔹 network surface
После разведки система запускает нужных агентов в нужной последовательности.
🧠 AI не получает shell
Обычно AI pentest-платформы дают модели прямой shell-доступ,
DarkMoon строит только план атаки, а все реальные вызовы агентов проходят через MCP-gateway, который определяет:
🔹 какой бинарник можно запускать
🔹 с какими аргументами
🔹 в каком контексте
🔹 с какими ограничениями
🛡️ Интересности
LLM уже хорошо умеют искать. Проблема в управляемости и воспроизводимости цепочки атак. Данные инструмент закрывает именно эти задачи:
➖ строит повторяемые offensive workflows,
➖ сохраняет доказательства
➖ маппитьрезультаты в MITRE ATT&CK и сразу готовить отчёты под ISO 27001, Bugcrowd и HackerOne
🔗 GitHub: https://github.com/ASCIT31/Dark-Moon
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Pentest #AgenticAI #RedTeam #OffensiveSecurity #AppSec #CyberSecurity #SecureTechTalks
На фоне бума AI-агентов появился ещё один интересный open-source проект, DarkMoon. Это полноценная мультиагентная атакуюшая платформа, где LLM не просто запускает инструменты, а строит атаку как связанный граф.
⚙️ Что внутри?
Внутри работает 18 специализированных агентов и 80+ offensive-инструментов.
Сначала master-agent проводит разведку и определяет стек цели по 14 технологическим сигналам:
🔹 web stack
🔹 Active Directory
🔹 Kubernetes
🔹 cloud
🔹 CMS
🔹 network surface
После разведки система запускает нужных агентов в нужной последовательности.
🧠 AI не получает shell
Обычно AI pentest-платформы дают модели прямой shell-доступ,
DarkMoon строит только план атаки, а все реальные вызовы агентов проходят через MCP-gateway, который определяет:
🔹 какой бинарник можно запускать
🔹 с какими аргументами
🔹 в каком контексте
🔹 с какими ограничениями
🛡️ Интересности
LLM уже хорошо умеют искать. Проблема в управляемости и воспроизводимости цепочки атак. Данные инструмент закрывает именно эти задачи:
🔗 GitHub: https://github.com/ASCIT31/Dark-Moon
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Pentest #AgenticAI #RedTeam #OffensiveSecurity #AppSec #CyberSecurity #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🧨 GitHub больше не успевает проверять уязвимости.
GitHub сообщили, что поток security advisories вырос настолько сильно, что команда верификации начала отставать.
В мае 2026 GitHub опубликовали 1560 проверенных advisories. Это абсолютный рекорд. Однако даже этого оказалось недостаточно, чтобы догнать входящий поток..
⚙️ Что происходит?
Сразу несколько каналов одновременно взорвались по объёму:
🔹 private vulnerability reports выросли до 3000+ в неделю
🔹 repository advisories перевалили за 5000+ в неделю
🔹 CVE requests приблизились к 4000 за май
Случилась перегрузка всей цепочки устранения уязвимостей.
GitHub Advisory Database - это один из главных upstream-источников для:
➖ Dependabot
➖ SBOM scanners
➖ CI/CD security checks
➖ supply chain monitoring
➖ dependency risk engines
Если advisory задерживается на недели, возникает слепое окно, когда уязвимость уже известна, но автоматические системы ещё ничего о ней не знают.
🧨 Парадокс AI-эры
AI резко ускорил генерацию кода, библиотек и новых пакетов, но вместе с этим ускорился и поток багов.
Уязвимости появляются быстрее, чем индустрия успевает их классифицировать.
GitHub уже подключили AI для triage и enrichment, но финальное решение пока всё ещё за человеком.
Похоже скоро без полной автоматизации рынок просто не выдержит.
🔗 Источник: GitHub Advisory Database Blog
Stay secure and read SecureTechTalks 📚
#кибербезопасность #GitHub #CVE #SupplyChainSecurity #AppSec #VulnerabilityManagement #Dependabot #SBOM #DevSecOps #SecureTechTalks
GitHub сообщили, что поток security advisories вырос настолько сильно, что команда верификации начала отставать.
В мае 2026 GitHub опубликовали 1560 проверенных advisories. Это абсолютный рекорд. Однако даже этого оказалось недостаточно, чтобы догнать входящий поток..
⚙️ Что происходит?
Сразу несколько каналов одновременно взорвались по объёму:
🔹 private vulnerability reports выросли до 3000+ в неделю
🔹 repository advisories перевалили за 5000+ в неделю
🔹 CVE requests приблизились к 4000 за май
Случилась перегрузка всей цепочки устранения уязвимостей.
GitHub Advisory Database - это один из главных upstream-источников для:
➖ Dependabot
➖ SBOM scanners
➖ CI/CD security checks
➖ supply chain monitoring
➖ dependency risk engines
Если advisory задерживается на недели, возникает слепое окно, когда уязвимость уже известна, но автоматические системы ещё ничего о ней не знают.
🧨 Парадокс AI-эры
AI резко ускорил генерацию кода, библиотек и новых пакетов, но вместе с этим ускорился и поток багов.
Уязвимости появляются быстрее, чем индустрия успевает их классифицировать.
GitHub уже подключили AI для triage и enrichment, но финальное решение пока всё ещё за человеком.
Похоже скоро без полной автоматизации рынок просто не выдержит.
🔗 Источник: GitHub Advisory Database Blog
Stay secure and read SecureTechTalks 📚
#кибербезопасность #GitHub #CVE #SupplyChainSecurity #AppSec #VulnerabilityManagement #Dependabot #SBOM #DevSecOps #SecureTechTalks
👍1
🧠🪱 AI-черви больше не требуют оператора
На arXiv вышла работа: AI Agents Enable Adaptive Computer Worms.
Исследователи показали новый класс вредоносного ПО: адаптивный AI-червь, который больше не живёт по заранее зашитому exploit chain. Вместо фиксированной логики внутри работает LLM-агент.
После компрометации машины червь разворачивает локальную open-weight модель прямо на украденных ресурсах и начинает сам анализировать окружение:
🔹 какие сервисы подняты
🔹 какие версии софта используются
🔹 где слабые конфигурации
🔹 какие lateral movement paths доступны
🔹 какие новые CVE можно применить
Каждый новый хост становится одновременно новой точкой заражения и новой вычислительной нодой для дальнейшего reasoning.
Получается паразитическая модель распространения.
🧨 Тестирование
Авторы прогнали worm на корпоративной сети из 33 машин: Linux, Windows и IoT. В среднем компрометировалось 73.8% инфраструктуры.
Червь адаптировался даже к CVE, которые появились уже после обучения модели, используя runtime intelligence и свежие advisory.
Агент умеет искать свежие эксплойты сам, а знания становятся динамическими.
🛡️ Новый класс угроз
AI-worm - это динамический reasoning движок. Он не хранит exploit chain. Он синтезирует её в реальном времени.
Это означает:
➖ меньше сигнатур
➖ меньше предсказуемости
➖ больше адаптации
➖ дешевле масштабирование
➖ сложнее containment
Таким образом, мы видим первые признаки autonomous offensive malware. Похоже эпоха «самообучающихся червей» уже началась.
🔗 Исследование: https://arxiv.org/abs/2606.03811
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Malware #Worm #AgenticAI #RCE #ThreatIntel #CyberSecurity #SecureTechTalks
На arXiv вышла работа: AI Agents Enable Adaptive Computer Worms.
Исследователи показали новый класс вредоносного ПО: адаптивный AI-червь, который больше не живёт по заранее зашитому exploit chain. Вместо фиксированной логики внутри работает LLM-агент.
После компрометации машины червь разворачивает локальную open-weight модель прямо на украденных ресурсах и начинает сам анализировать окружение:
🔹 какие сервисы подняты
🔹 какие версии софта используются
🔹 где слабые конфигурации
🔹 какие lateral movement paths доступны
🔹 какие новые CVE можно применить
Каждый новый хост становится одновременно новой точкой заражения и новой вычислительной нодой для дальнейшего reasoning.
Получается паразитическая модель распространения.
🧨 Тестирование
Авторы прогнали worm на корпоративной сети из 33 машин: Linux, Windows и IoT. В среднем компрометировалось 73.8% инфраструктуры.
Червь адаптировался даже к CVE, которые появились уже после обучения модели, используя runtime intelligence и свежие advisory.
Агент умеет искать свежие эксплойты сам, а знания становятся динамическими.
🛡️ Новый класс угроз
AI-worm - это динамический reasoning движок. Он не хранит exploit chain. Он синтезирует её в реальном времени.
Это означает:
➖ меньше сигнатур
➖ меньше предсказуемости
➖ больше адаптации
➖ дешевле масштабирование
➖ сложнее containment
Таким образом, мы видим первые признаки autonomous offensive malware. Похоже эпоха «самообучающихся червей» уже началась.
🔗 Исследование: https://arxiv.org/abs/2606.03811
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Malware #Worm #AgenticAI #RCE #ThreatIntel #CyberSecurity #SecureTechTalks
👍2
📌 Уязвимость не всегда живёт в одном файле
Когда мы ищем баги в коде, самые опасные цепочки часто размазаны по десяткам файлов. Данные приходят через controller, проходят DTO, service layer, helper’ы, а потом внезапно оказываются внутри SQL-запроса, shell-команды или file API.
На GitHub появился новый open-source инструмент от PhonePe "Nika".
Инструмент строит полный путь движения данных через приложение, что делает анализ намного ближе к реальной эксплуатации.
⚙️ Что умеет Nika?
Внутри:
🔹 строит межфайловый graph зависимостей
🔹 делает inter-procedural taint tracking
🔹 связывает source → propagation → sink
🔹 анализирует branch-aware изменения (полезно для PR review)
🔹 использует AI-assisted triage для сокращения false positives
Поддерживаемые sink’и:
• SQL execution
• File system operations
• Template engines
• Reflection
• Network requests
• Deserialization points
Для понимания, инструмент не про «подозрительные строки», а про реальные пути эксплуатации.
Для security review больших Java codebase это особенно полезно, потому что позволяет быстро понять, как именно пользовательский ввод проходит через бизнес-логику.
🤖 Интересный момент
После основного анализа Nika умеет прогонять findings через LLM и дополнительно фильтровать шум. Это хороший пример правильного применения AI в AppSec, т.к. AI здесь не ищет баги, а помогает понять насколько они эксплуатируемые.
🔗 Исходники:
https://github.com/PhonePe/nika
Stay secure and read SecureTechTalks 📚
#cybersecurity #appsec #devsecops #javasecurity #taintanalysis #securecoding #opensource #codeaudit #infosec #securetechtalks
Когда мы ищем баги в коде, самые опасные цепочки часто размазаны по десяткам файлов. Данные приходят через controller, проходят DTO, service layer, helper’ы, а потом внезапно оказываются внутри SQL-запроса, shell-команды или file API.
На GitHub появился новый open-source инструмент от PhonePe "Nika".
Инструмент строит полный путь движения данных через приложение, что делает анализ намного ближе к реальной эксплуатации.
⚙️ Что умеет Nika?
Внутри:
🔹 строит межфайловый graph зависимостей
🔹 делает inter-procedural taint tracking
🔹 связывает source → propagation → sink
🔹 анализирует branch-aware изменения (полезно для PR review)
🔹 использует AI-assisted triage для сокращения false positives
Поддерживаемые sink’и:
• SQL execution
• File system operations
• Template engines
• Reflection
• Network requests
• Deserialization points
Для понимания, инструмент не про «подозрительные строки», а про реальные пути эксплуатации.
Для security review больших Java codebase это особенно полезно, потому что позволяет быстро понять, как именно пользовательский ввод проходит через бизнес-логику.
🤖 Интересный момент
После основного анализа Nika умеет прогонять findings через LLM и дополнительно фильтровать шум. Это хороший пример правильного применения AI в AppSec, т.к. AI здесь не ищет баги, а помогает понять насколько они эксплуатируемые.
🔗 Исходники:
https://github.com/PhonePe/nika
Stay secure and read SecureTechTalks 📚
#cybersecurity #appsec #devsecops #javasecurity #taintanalysis #securecoding #opensource #codeaudit #infosec #securetechtalks
👍3
🚨 У 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
🧠🕵️ Claude Code нашли с "водяными знаками" в запросах
Исследователи обратили внимание на любопытную особенность Claude Code. Если клиент работает не через официальный API Anthropic, а через собственный прокси (ANTHROPIC_BASE_URL), он может незаметно изменять символы в системном промпте.
Вместо привычной строки:
клиент использует визуально идентичные символы: другой апостроф или разделитель даты. Для пользователя и модели текст выглядит одинаково, но на сервер отправляется уже немного другой набор Unicode-символов.
Фактически это стеганографическая метка, встроенная прямо в системный контекст.
⚙️ Что именно кодируется?
По результатам реверс-инжиниринга логика появилась в версии 2.1.196.
При использовании собственного ANTHROPIC_BASE_URL клиент анализирует адрес прокси и, по утверждению исследователей, проверяет совпадение с набором заранее заданных доменов. Отдельно учитывается часовой пояс, например, Asia/Shanghai или Asia/Urumqi.
Полученные признаки кодируются изменением отдельных символов даты. При этом сами списки доменов, как сообщается, скрыты в бинарном файле с помощью Base64 и XOR-обфускации.
🧨 Зачем это нужно?
Наиболее вероятным объяснением является борьба с неофициальными прокси и массовой дистилляцией моделей.
Сегодня существует рынок прокси, которые перепродают доступ к Claude. Кроме того, через такие шлюзы можно автоматически собирать большие массивы ответов модели для последующего обучения собственных LLM.
Если выводы исследователей верны, подобные метки позволяют серверной стороне определить, что запрос, вероятно, пришёл не через официальный API.
🛡️ Почему это вызвало дискуссию?
Главная претензия не к самой идее защиты от дистилляции, а к её реализации. По данным реверс-инжиниринга, клиент с доступом к shell, Git и файловой системе анализирует параметры окружения и скрытно кодирует их в системном промпте, хотя подобное поведение не было описано в release notes. Для инструментов такого уровня привилегий прозрачность становится вопросом доверия.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #Claude #Anthropic #LLM #ReverseEngineering #AIsecurity #AgenticAI #SupplyChainSecurity #SecureTechTalks
Исследователи обратили внимание на любопытную особенность Claude Code. Если клиент работает не через официальный API Anthropic, а через собственный прокси (ANTHROPIC_BASE_URL), он может незаметно изменять символы в системном промпте.
Вместо привычной строки:
Today's date is 2026-06-30клиент использует визуально идентичные символы: другой апостроф или разделитель даты. Для пользователя и модели текст выглядит одинаково, но на сервер отправляется уже немного другой набор Unicode-символов.
Фактически это стеганографическая метка, встроенная прямо в системный контекст.
⚙️ Что именно кодируется?
По результатам реверс-инжиниринга логика появилась в версии 2.1.196.
При использовании собственного ANTHROPIC_BASE_URL клиент анализирует адрес прокси и, по утверждению исследователей, проверяет совпадение с набором заранее заданных доменов. Отдельно учитывается часовой пояс, например, Asia/Shanghai или Asia/Urumqi.
Полученные признаки кодируются изменением отдельных символов даты. При этом сами списки доменов, как сообщается, скрыты в бинарном файле с помощью Base64 и XOR-обфускации.
🧨 Зачем это нужно?
Наиболее вероятным объяснением является борьба с неофициальными прокси и массовой дистилляцией моделей.
Сегодня существует рынок прокси, которые перепродают доступ к Claude. Кроме того, через такие шлюзы можно автоматически собирать большие массивы ответов модели для последующего обучения собственных LLM.
Если выводы исследователей верны, подобные метки позволяют серверной стороне определить, что запрос, вероятно, пришёл не через официальный API.
🛡️ Почему это вызвало дискуссию?
Главная претензия не к самой идее защиты от дистилляции, а к её реализации. По данным реверс-инжиниринга, клиент с доступом к shell, Git и файловой системе анализирует параметры окружения и скрытно кодирует их в системном промпте, хотя подобное поведение не было описано в release notes. Для инструментов такого уровня привилегий прозрачность становится вопросом доверия.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #Claude #Anthropic #LLM #ReverseEngineering #AIsecurity #AgenticAI #SupplyChainSecurity #SecureTechTalks
👍1🔥1
🧨 Microsoft решили, что AI-агентам больше нельзя доверять права пользователя
Компания MS представила Microsoft Execution Containers (MXC), новый слой исполнения для AI-агентов в Windows и WSL. Даже если агент получил shell, написал код или решил вызвать инструмент, он не должен автоматически наследовать все права пользователя.
⚙️ Изоляция с помощью MXC
MXC запускает действия агента в изолированной среде, где политики определяют, к чему разрешён доступ. Можно ограничить файловую систему, сеть, процессы и другие ресурсы ещё до выполнения сгенерированного кода.
В первой версии доступны два режима. Process Isolation изолирует выполнение отдельных команд и ограничивает их доступ к файлам и сети. Session Isolation полностью отделяет агента от рабочего сеанса пользователя: рабочего стола, буфера обмена, устройств ввода и других пользовательских процессов. Каждая сессия работает от собственной учётной записи с отдельными политиками безопасности.
🧠 Повышаем уровень защиты
Последние месяцы мы регулярно пишем про атаки на AI-агентов: prompt injection, MCP injection, AutoJack, компрометацию tool chain...
Практически во всех случаях проблема одна и та же, агент получает слишком широкие полномочия. Microsoft фактически предлагают перенести принцип наименьших привилегий в мир агентных систем. Модель может ошибиться, но последствия этой ошибки должны оставаться внутри контейнера.
🔗 GitHub: https://github.com/microsoft/mxc
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Microsoft #RuntimeSecurity #Sandbox #AppSec #CyberSecurity #SecureTechTalks
Компания MS представила Microsoft Execution Containers (MXC), новый слой исполнения для AI-агентов в Windows и WSL. Даже если агент получил shell, написал код или решил вызвать инструмент, он не должен автоматически наследовать все права пользователя.
⚙️ Изоляция с помощью MXC
MXC запускает действия агента в изолированной среде, где политики определяют, к чему разрешён доступ. Можно ограничить файловую систему, сеть, процессы и другие ресурсы ещё до выполнения сгенерированного кода.
В первой версии доступны два режима. Process Isolation изолирует выполнение отдельных команд и ограничивает их доступ к файлам и сети. Session Isolation полностью отделяет агента от рабочего сеанса пользователя: рабочего стола, буфера обмена, устройств ввода и других пользовательских процессов. Каждая сессия работает от собственной учётной записи с отдельными политиками безопасности.
🧠 Повышаем уровень защиты
Последние месяцы мы регулярно пишем про атаки на AI-агентов: prompt injection, MCP injection, AutoJack, компрометацию tool chain...
Практически во всех случаях проблема одна и та же, агент получает слишком широкие полномочия. Microsoft фактически предлагают перенести принцип наименьших привилегий в мир агентных систем. Модель может ошибиться, но последствия этой ошибки должны оставаться внутри контейнера.
🔗 GitHub: https://github.com/microsoft/mxc
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Microsoft #RuntimeSecurity #Sandbox #AppSec #CyberSecurity #SecureTechTalks
👍3
🧨 Автономный AI-вымогатель начал атаку
Мы дождались момента, когда AI перестал просто помогать атакующим и начал самостоятельно проводить полноценные атаки.
Исследователи Sysdig разобрали кампанию JADEPUFFER, первый публично описанный случай, где LLM-агент без участия человека выполнил весь kill chain: от первоначального проникновения до шифрования инфраструктуры и требования выкупа.
⚙️ Как проходила атака?
Точкой входа стала уязвимость CVE-2025-3248 в Langflow. Получив удалённое выполнение кода, агент начал действовать как опытный пентестер.
Сначала он собрал всё, что представляло ценность: API-ключи OpenAI, Anthropic, Gemini и DeepSeek, облачные креденшелы AWS, Azure, Google Cloud, Alibaba и Tencent, учётные данные баз данных и даже ключи криптокошельков. Затем самостоятельно построил маршрут дальнейшего продвижения по инфраструктуре.
🧠 AI сам принимал решения
Следующей целью стал MinIO. Агент обнаружил сервис, автоматически проверил стандартные учётные данные minioadmin:minioadmin, получил доступ и закрепился через планировщик задач, периодически отправляя beacon на управляющий сервер.
После этого он переключился на Nacos, воспользовался CVE-2021-29441, получил административный доступ и добрался до MySQL.
В итоге агент зашифровал 1342 записи конфигурации Nacos, удалил исходные таблицы и оставил записку с требованием выкупа. При этом ключ шифрования нигде не сохранился, поэтому восстановление оказалось невозможным даже в случае оплаты.
🧪 Почему исследователи уверены, что это был AI?
Артефакты выглядят необычно для классического вредоносного ПО. Код содержал большое количество подробных комментариев на естественном языке. При ошибках агент не просто повторял действия, а анализировал причину сбоя, перепланировал атаку и самостоятельно исправлял её. По оценке Sysdig, в ходе кампании использовались сотни различных эксплойтов и техник.
🔗 Источник: https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Ransomware #AgenticAI #ThreatIntelligence #Malware #CyberSecurity #Sysdig #SecureTechTalks
Мы дождались момента, когда AI перестал просто помогать атакующим и начал самостоятельно проводить полноценные атаки.
Исследователи Sysdig разобрали кампанию JADEPUFFER, первый публично описанный случай, где LLM-агент без участия человека выполнил весь kill chain: от первоначального проникновения до шифрования инфраструктуры и требования выкупа.
⚙️ Как проходила атака?
Точкой входа стала уязвимость CVE-2025-3248 в Langflow. Получив удалённое выполнение кода, агент начал действовать как опытный пентестер.
Сначала он собрал всё, что представляло ценность: API-ключи OpenAI, Anthropic, Gemini и DeepSeek, облачные креденшелы AWS, Azure, Google Cloud, Alibaba и Tencent, учётные данные баз данных и даже ключи криптокошельков. Затем самостоятельно построил маршрут дальнейшего продвижения по инфраструктуре.
🧠 AI сам принимал решения
Следующей целью стал MinIO. Агент обнаружил сервис, автоматически проверил стандартные учётные данные minioadmin:minioadmin, получил доступ и закрепился через планировщик задач, периодически отправляя beacon на управляющий сервер.
После этого он переключился на Nacos, воспользовался CVE-2021-29441, получил административный доступ и добрался до MySQL.
В итоге агент зашифровал 1342 записи конфигурации Nacos, удалил исходные таблицы и оставил записку с требованием выкупа. При этом ключ шифрования нигде не сохранился, поэтому восстановление оказалось невозможным даже в случае оплаты.
🧪 Почему исследователи уверены, что это был AI?
Артефакты выглядят необычно для классического вредоносного ПО. Код содержал большое количество подробных комментариев на естественном языке. При ошибках агент не просто повторял действия, а анализировал причину сбоя, перепланировал атаку и самостоятельно исправлял её. По оценке Sysdig, в ходе кампании использовались сотни различных эксплойтов и техник.
🔗 Источник: https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Ransomware #AgenticAI #ThreatIntelligence #Malware #CyberSecurity #Sysdig #SecureTechTalks
👍2😱2
🧨 Skills AI-агентов начали массово отравлять
Skills сегодня становятся аналогом npm-пакетов для AI-агентов, они расширяют возможности модели, но при этом наследуют её привилегии, могут запускать команды, читать файлы, обращаться к сети и использовать API.
⚙️ Исследования
За период с марта по май 2026 года исследователи ESET проанализировали почти 900 000 skills:
🔹 более 25 000 признаны подозрительными;
🔹 свыше 3 000 содержали вредоносную функциональность;
🔹 всего за два месяца число выявленных вредоносных skills выросло почти в пять раз.
🧠 Что умеют вредоносные skills?
Исследователи обнаружили целый набор типичных возможностей:
➖ выполнение shell-команд;
➖ доступ к локальным файлам;
➖ загрузка и запуск сторонних программ;
➖ внедрение кода в рабочий процесс агента;
➖ кража учётных данных и API-ключей;
➖ скрытая обфускация собственного поведения.
Проблема в том, что каждая из этих возможностей сама по себе может быть абсолютно легитимной. Поэтому статический анализ всё чаще оказывается бесполезным. Он видит код, но не понимает намерение.
🛡️ Куда движется Agent Security?
Проверять содержимое skills уже недостаточно. Новые работы предлагают запускать их в песочнице и анализировать реальное поведение: какие процессы создаются, какие файлы читаются, куда уходят данные и как они пересекают границы доверия. Такой подход демонстрирует заметно более высокую эффективность по сравнению со статическими сканерами.
🔗 Источник: ESET Threat Report H1 2026
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #SupplyChainSecurity #RuntimeSecurity #AppSec #CyberSecurity #SecureTechTalks
Skills сегодня становятся аналогом npm-пакетов для AI-агентов, они расширяют возможности модели, но при этом наследуют её привилегии, могут запускать команды, читать файлы, обращаться к сети и использовать API.
⚙️ Исследования
За период с марта по май 2026 года исследователи ESET проанализировали почти 900 000 skills:
🔹 более 25 000 признаны подозрительными;
🔹 свыше 3 000 содержали вредоносную функциональность;
🔹 всего за два месяца число выявленных вредоносных skills выросло почти в пять раз.
🧠 Что умеют вредоносные skills?
Исследователи обнаружили целый набор типичных возможностей:
Проблема в том, что каждая из этих возможностей сама по себе может быть абсолютно легитимной. Поэтому статический анализ всё чаще оказывается бесполезным. Он видит код, но не понимает намерение.
🛡️ Куда движется Agent Security?
Проверять содержимое skills уже недостаточно. Новые работы предлагают запускать их в песочнице и анализировать реальное поведение: какие процессы создаются, какие файлы читаются, куда уходят данные и как они пересекают границы доверия. Такой подход демонстрирует заметно более высокую эффективность по сравнению со статическими сканерами.
🔗 Источник: ESET Threat Report H1 2026
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #SupplyChainSecurity #RuntimeSecurity #AppSec #CyberSecurity #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
🧨 AI-агенты научились обходить собственные защитные механизмы
Большинство тестов безопасности проверяют LLM просто задавая опасный запрос и проверяя, откажется ли модель его исполнять. Однако исследователи показали, что для coding-агентов такой подход больше не работает.
Оказывается, агент может уверенно отказаться выполнять вредоносный запрос в чате, а затем самостоятельно собрать тот же результат в процессе обычной разработки.
⚙️ Как работает jailbreak?
Исследователи разбили опасную задачу на цепочку привычных действий IDE-агента:
🔹 чтение файлов проекта;
🔹 анализ существующего кода;
🔹 создание новых модулей;
🔹 исправление ошибок;
🔹 рефакторинг;
🔹 генерация итогового проекта.
Каждый отдельный шаг выглядит полностью легитимным. Однако в сумме агент постепенно строит код, который в обычном чате отказался бы генерировать.
🧠 Что проверяли?
Авторы протестировали GitHub Copilot с несколькими современными моделями.
При прямых запросах практически все они корректно отказывались выполнять опасные инструкции. Но при разбиении задачи на последовательность обычных действий IDE исследователи получили успешное выполнение во всех протестированных сценариях.
🛡️ Делаем выводы
Для AI-агентов недостаточно фильтровать отдельные сообщения. Решения начинают приниматься на уровне execution graph, где безопасные действия по отдельности складываются в небезопасный результат.
🔗 Исследование: https://arxiv.org/abs/2607.03968
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #GitHubCopilot #AgenticAI #Jailbreak #AISecurity #AppSec #CyberSecurity #SecureTechTalks
Большинство тестов безопасности проверяют LLM просто задавая опасный запрос и проверяя, откажется ли модель его исполнять. Однако исследователи показали, что для coding-агентов такой подход больше не работает.
Оказывается, агент может уверенно отказаться выполнять вредоносный запрос в чате, а затем самостоятельно собрать тот же результат в процессе обычной разработки.
⚙️ Как работает jailbreak?
Исследователи разбили опасную задачу на цепочку привычных действий IDE-агента:
🔹 чтение файлов проекта;
🔹 анализ существующего кода;
🔹 создание новых модулей;
🔹 исправление ошибок;
🔹 рефакторинг;
🔹 генерация итогового проекта.
Каждый отдельный шаг выглядит полностью легитимным. Однако в сумме агент постепенно строит код, который в обычном чате отказался бы генерировать.
🧠 Что проверяли?
Авторы протестировали GitHub Copilot с несколькими современными моделями.
При прямых запросах практически все они корректно отказывались выполнять опасные инструкции. Но при разбиении задачи на последовательность обычных действий IDE исследователи получили успешное выполнение во всех протестированных сценариях.
🛡️ Делаем выводы
Для AI-агентов недостаточно фильтровать отдельные сообщения. Решения начинают приниматься на уровне execution graph, где безопасные действия по отдельности складываются в небезопасный результат.
🔗 Исследование: https://arxiv.org/abs/2607.03968
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #GitHubCopilot #AgenticAI #Jailbreak #AISecurity #AppSec #CyberSecurity #SecureTechTalks
👍3
🧨 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
🧨 Данные с сайтов воруют AI-агенты, а CAPTCHA больше не помогает
Раньше было достаточно защититься от обычных веб-сканеров. Сегодня этого уже мало. Всё больше компаний используют agentic crawlers, т.е. AI-агентов, которые скачивают страницы, понимают структуру сайта, объединяют информацию из разных разделов, сжимают её и превращают в готовую базу знаний для RAG и LLM.
На arXiv вышло исследование Out of Sight, посвящённое защите контента от агентов.
⚙️ Контент стал новой добычей
Современный crawler умеет гораздо больше, чем пройтись по ссылкам. Он открывает документацию, следует по внутренним переходам, анализирует API, собирает статьи в единое представление, удаляет повторы и оставляет только самую ценную информацию.
В результате developer-порталы, базы знаний, help-центры и техническая документация превращаются в готовый источник данных для обучения моделей, построения RAG-систем или анализа инфраструктуры потенциальной цели.
🧠 Победить AI его же оружием
Авторы предлагают отказаться от борьбы с самим сканированием. Вместо этого они предлагают защищаться от сжатия информации. AI-агент почти всегда пытается максимально сократить объём данных без потери смысла. Если критически важные детали распределить по документу таким образом, чтобы они терялись или искажались при автоматическом summarization, ценность украденного контента резко падает.
Защита начинает работать не против HTTP-запроса, а против всей цепочки «чтение → анализ → сжатие → построение базы знаний».
🛡️ Новая гонка вооружений
Похоже, в эпоху AI-агентов защищать придётся уже не только доступ к данным, но и способность моделей понимать и эффективно извлекать их смысл.
🔗 Исследование: https://arxiv.org/abs/2607.08180
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #RAG #WebSecurity #ThreatModeling #DataProtection #CyberSecurity #SecureTechTalks
Раньше было достаточно защититься от обычных веб-сканеров. Сегодня этого уже мало. Всё больше компаний используют agentic crawlers, т.е. AI-агентов, которые скачивают страницы, понимают структуру сайта, объединяют информацию из разных разделов, сжимают её и превращают в готовую базу знаний для RAG и LLM.
На arXiv вышло исследование Out of Sight, посвящённое защите контента от агентов.
⚙️ Контент стал новой добычей
Современный crawler умеет гораздо больше, чем пройтись по ссылкам. Он открывает документацию, следует по внутренним переходам, анализирует API, собирает статьи в единое представление, удаляет повторы и оставляет только самую ценную информацию.
В результате developer-порталы, базы знаний, help-центры и техническая документация превращаются в готовый источник данных для обучения моделей, построения RAG-систем или анализа инфраструктуры потенциальной цели.
🧠 Победить AI его же оружием
Авторы предлагают отказаться от борьбы с самим сканированием. Вместо этого они предлагают защищаться от сжатия информации. AI-агент почти всегда пытается максимально сократить объём данных без потери смысла. Если критически важные детали распределить по документу таким образом, чтобы они терялись или искажались при автоматическом summarization, ценность украденного контента резко падает.
Защита начинает работать не против HTTP-запроса, а против всей цепочки «чтение → анализ → сжатие → построение базы знаний».
🛡️ Новая гонка вооружений
Похоже, в эпоху AI-агентов защищать придётся уже не только доступ к данным, но и способность моделей понимать и эффективно извлекать их смысл.
🔗 Исследование: https://arxiv.org/abs/2607.08180
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #RAG #WebSecurity #ThreatModeling #DataProtection #CyberSecurity #SecureTechTalks
👍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