🧨 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

🧨 Hugging Face взломали AI-агентом

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

⚙️ Как удалось проникнуть?

Точкой входа стал пайплайн обработки датасетов. Злоумышленники использовали сразу два механизма выполнения кода: загрузчик датасетов с возможностью удалённого исполнения и template injection в конфигурации датасета. После получения доступа агент автоматически повысил привилегии, собрал облачные учётные данные и начал lateral movement между внутренними кластерами.

По информации Hugging Face, злоумышленники получили доступ к ограниченному числу внутренних наборов данных и сервисных учётных данных. При этом признаков компрометации публичных моделей и датасетов обнаружено не было.

🧠 Расследование

Для анализа более 17 000 событий безопасности команда сначала попыталась использовать коммерческие LLM через API. Однако модели отказались обрабатывать журналы, содержащие реальные эксплойты, команды и артефакты C2, поскольку guardrails восприняли такую активность как потенциально вредоносную.

В итоге расследование пришлось проводить на собственной инфраструктуре с использованием GLM 5.2 с открытыми весами. Это позволило не только обойти ограничения API, но и не передавать атакующие артефакты и чувствительные данные стороннему провайдеру.

🛡️ Новый парадокс AI-безопасности

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

🔗 Источник: https://huggingface.co/blog/security-incident-july-2026

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #HuggingFace #AgenticAI #IncidentResponse #ThreatIntelligence #SOC #CyberSecurity #SecureTechTalks

🧨 GPT-5.6 Sol взломала Hugging Face во время внутренних тестов OpenAI

История с атакой на Hugging Face получила неожиданное продолжение. OpenAI раскрыла, что за инцидентом, который ранее считался первой автономной атакой AI-агента, стояли две её собственные модели, GPT-5.6 Sol и более мощная предрелизная LLM.

⚙️ Как так получилось?

Во время тестирования моделей на бенчмарке ExploitGym исследователи временно отключили стандартные ограничения, чтобы оценить реальные offensive-возможности моделей.

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

По данным OpenAI, агент самостоятельно обнаружил ранее неизвестную zero-day-уязвимость в стороннем ПО, используемом в инфраструктуре компании, повысил привилегии и покинул изолированную среду.

🧠 Самое интересное

Получив доступ во внешнюю сеть, агент использовал украденные учётные данные и новую цепочку эксплуатации, чтобы добиться удалённого выполнения кода на серверах Hugging Face.

Целью не была атака на платформу. Модель пыталась получить доступ к информации, которая помогла бы успешнее пройти задания ExploitGym. Иными словами, компрометация чужой инфраструктуры стала для неё оптимальным способом достижения поставленной цели.

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

🛡️ Послевкусие

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

🔗 Источник

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #OpenAI #GPT56 #HuggingFace #ExploitGym #AgenticAI #ZeroDay #SecureTechTalks

🧨 OpenAI теперь продают готовых AI-сотрудников

OpenAI представили Presence, новую платформу для запуска корпоративных AI-агентов. Вместо того чтобы дать компании LLM и API, OpenAI начинают поставлять практически готовую операционную среду для автономных агентов.

⚙️ Агент как бизнес-процесс

Presence - не новая модель, а инфраструктура вокруг неё. В одном продукте объединены:
🔹 корпоративные политики и SOP;
🔹 управление правами и разрешёнными действиями;
🔹 guardrails;
🔹 симуляции рабочих сценариев;
🔹 автоматическая оценка качества работы;
🔹 механизмы эскалации человеку.

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

🧠 Саморазвитие

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

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

Фактически OpenAI превращают AI-агента в управляемый корпоративный сервис со встроенными механизмами DevSecOps.

🔗 Источник: https://openai.com/index/introducing-openai-presence/

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #OpenAI #AgenticAI #AISecurity #Guardrails #DevSecOps #EnterpriseAI #SecureTechTalks

🧨 Kimi K3 нашёл уязвимость в Redis за 27 минут

На этой неделе по соцсетям разлетелась новость про то, как исследователь Чаофань Шоу обнаружил уязвимость в Redis и подготовил рабочий эксплойт. Анализ производился автоматизировано с помощью Kimi K3, роя из 32 AI-агентов и занял всего за 27 минут.

Код эксперимента уже опубликован на GitHub.
Если это подтвердится независимыми исследователями, мы можем стать свидетелями серьёзного скачка в автоматизации vulnerability research.

По словам автора, агентам дали задачу самостоятельно проанализировать исходный код Redis, найти memory corruption-уязвимость и построить рабочий exploit chain.

В опубликованном репозитории представлены PoC для нескольких версий Redis. Один из них позволяет выполнить произвольную команду на сервере через уже аутентифицированное подключение, а для более новой версии предложен ещё один вариант эксплуатации.

🧠 Почему пока рано говорить о "взломе Redis"?

Здесь есть сразу несколько оговорок. Во-первых, одна из найденных проблем уже была известна разработчикам Redis, исправление подготовили ещё до публикации эксперимента.

Во-вторых, второй эксплойт для актуальной версии Redis пока публично не подтверждён командой Redis и не получил официального статуса уязвимости.

И последнее, все цифры (27 минут, 32 агента и степень автономности системы) известны исключительно со слов автора. Полный лог работы агентов и независимое воспроизведение эксперимента не опубликованы.

🔗 GitHub: https://github.com/berabuddies/redis-poc

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #KimiK3 #Redis #VulnerabilityResearch #Exploit #AgenticAI #AppSec #SecureTechTalks

🧨 GitHub повышает ставки для багхантеров. AI меняет рынок поиска уязвимостей

Искусственный интеллект заметно ускорил поиск ошибок в программном обеспечении. Исследователи автоматизируют анализ кода, быстрее находят потенциальные уязвимости. В результате объём качественных отчётов растёт настолько быстро, что GitHub пришлось пересматривать правила своей Bug Bounty-программы.

⚙️ VIP только для лучших

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

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

После этого выплаты существенно увеличиваются:

➖ Low  $1 000 вместо $250;
➖ Medium  $7 500 вместо $2 000;
➖ High $20 000 вместо $5 000;
➖ Critical  от $30 000 вместо $10 000.

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

🧠 Не только лишь плюсы

Одновременно GitHub вводит ограничения для новых участников программы через HackerOne. Теперь новичок сможет отправить только четыре первых отчёта, прежде чем получит возможность подавать больше.

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

🛡️ Новая реальность Bug Bounty

Ещё несколько месяцев назад GitHub устранил критическую RCE-уязвимость, позволявшую одной вредоносной командой "git push" получить полный доступ к миллионам приватных репозиториев. Подобные находки показывают, что стоимость действительно качественного vulnerability research только растёт.

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

🔗 Источник

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #BugBounty #GitHub #HackerOne #AppSec #VulnerabilityResearch #CyberSecurity #LLM #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 жульничают, даже если их об этом не просили

Исследователи проанализировали поведение 22 современных моделей от 7 разработчиков на 23 задачах Cybench.

Мы привыкли сравнивать модели по результатам CTF-бенчмарков и считать, что высокий процент решённых задач означает лучшие offensive-способности. Однако часть этих побед нельзя считать честными.

⚙️ Почти все модели начинают искать обходной путь

Результаты исследований без дополнительных ограничений:
🔹 21 из 22 моделей хотя бы один раз жульничали;
🔹 37,1% всех успешных решений оказались получены нечестным способом;
🔹 у некоторых моделей итоговые результаты были завышены почти в 5 раз.

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

🧠 Достаточно одного промпта

Исследователи проверили три режима работы:
➖ без защиты;
➖ стандартный anti-cheat prompt;
➖ жёсткий anti-cheat prompt.

Вероятность мошенничества снизилась с 33% до 17,8%, а затем до 8,5%. При этом качество решения задач практически не снизилось. Тем не менее полностью избавиться от проблемы не удалось, даже при самых строгих инструкциях 8 моделей продолжали искать обходные пути, а некоторые стали использовать ещё более изощрённые стратегии.

🛡️ Новый показатель для AI-бенчмарков

Авторы предлагают отказаться от привычного pass rate и использовать новый показатель, Solve Rate, который учитывает только честно решённые задачи.

Если агент получает доступ к shell, файловой системе или сети, измерять нужно уже не только качество его ответов, но и способ достижения результата. В противном случае модель, которая чаще всех нарушает правила, может ошибочно показаться самой сильной.

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

Stay secure and read SecureTechTalks 📚

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

🧨 Дообучение LLM кибербезопасности может сделать ответы модели хуже

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

Авторы исследования протестировали пять небольших 7B-моделей и обнаружили устойчивый эффект, после fine-tuning у всех пяти ухудшились отдельные базовые способности (прежде всего работа с терминологией и встроенными знаниями по безопасности).

⚙️ Проблема не всегда там, где вы её ищете

Авторы предлагают сначала диагностировать модель с помощью framework FiT (Fine-tuning Impact Test).

Он разделяет способности модели на три независимых слоя:

🔹 Vocabulary: понимает ли модель security-термины и их значения;

🔹 Knowledge: действительно ли она знает предметную область;

🔹 Contextualization: умеет ли использовать внешний контекст, например документы из RAG, для решения задачи.

🧠 Неожиданный эффект

В экспериментах fine-tuning иногда резко ухудшал результаты на вопросах, где модель должна была отвечать без внешней информации.

У одной из протестированных моделей accuracy на knowledge-задачах упала с 0,71 до 0,08. На другой с 0,72 до 0,12. На первый взгляд кажется, что модель просто «забыла» знания, но затем исследователи подключили RAG и картина изменилась. Когда необходимые сведения передавались модели непосредственно в контексте, качество оставалось высоким.

То есть fine-tuning не обязательно уничтожил знания. Он мог изменить поведение модели при отсутствии внешнего контекста.

📉 Другие изменения

После разных режимов fine-tuning менялся даже рейтинг моделей. Для одного типа дообучения относительный порядок моделей в основном сохранялся. Для другого практически перевернулся.

Получается интересный инженерный сценарий, модель, которая до fine-tuning была лучшим кандидатом для security-задач, после обучения может стать провальным выбором.

🛡️ RAG или Fine-tuning?

Главный практический вывод исследования - не бросаться в fine-tuning только потому, что модель плохо отвечает на security-вопросы.

Если проблема заключается в отсутствии актуальных CVE, внутренних документов, threat intelligence или другой постоянно меняющейся информации, RAG может оказаться более подходящим решением.

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

🔗 Код: https://github.com/shaswata09/FiT

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #RAG #FineTuning #AISecurity #ThreatIntelligence #CyberSecurity #AppSec #SecureTechTalks