Cisco Antares: SLM для локализации уязвимого кода
Cisco представила Antares — семейство SLM для поиска файлов с известной уязвимостью внутри репозитория. Выпущены Antares-350M и Antares-1B; Antares-3B пока только готовится. Ставка сделана на узкую задачу, локальный запуск и меньшие вычислительные требования по сравнению с универсальными моделями. Наконец по настоящему SLM, а не вот эти 30b или даже больше, которыми называют SLM.
Antares работает как классический агент. Модель получает описание класса уязвимости и исследует снимок репозитория через
В основе моделей лежит IBM Granite 4.0 350M и 1b. Сначала проводилось SFT на данных по ИБ-рассуждениям, исследовательским задачам и поиску кода, затем GRPO на многоходовых сессиях агента. Корпуса и конвейер генерации данных закрыты, поэтому воспроизвести обучение или проверить пересечение с тестовым набором нельзя.
Для оценки Cisco выпустила VLoc Bench: 500 задач из 290 репозиториев, шести экосистем и 147 CWE.
1. В Phase A агент получает уязвимый снимок и оценивается по
2. В Phase B — исправленный снимок, где измеряется способность не поднимать ложную тревогу.
Лимит: 15 терминальных вызовов на задачу.
По данным Cisco,
Абсолютные значения не позволяют считать задачу решённой. Лучший результат остаётся на уровне 0,229, 190 из 500 примеров не прошла ни одна протестированная система, а на крупнейших репозиториях средний результат падает примерно в 13 раз относительно самых маленьких. Кроме того, варианты Antares с GRPO оценивались только в Phase A: данных о
Сравнение моделей не полностью однородно. Antares запускалась через raw completions со специальным префиксом рассуждения, другие семейства — через chat completions и собственные парсеры вызовов инструментов. Общий лимит команд выравнивает бюджет агента, но не весь стек инференса. В карточках моделей и JSON расходятся precision и recall для версий 350M и 1B, хотя
Термин open-weight здесь требует точности. Веса Antares-350M и Antares-1B размещены на Hugging Face в формате safetensors под Apache-2.0, но доступны по только запросу (я уже запросил доступ). Код теста опубликован, обучающие данные — нет. Публичных весов 3B на момент проверки не было.
Antares подходит для триажа по тикетам безопасности (к примеру из DefectDojo или Github/Gitlab или другое ваше ПО), проверки конкретных CWE и локального анализа закрытых репозиториев — как дополнительный слой рядом с SAST, SCA, DAST и ручным аудитом. Независимых прогонов VLoc Bench, проверки утечки данных и нормализованных измерений стоимости, памяти и производительности пока нет, поэтому заявления о превосходстве и эффективности остаются результатами самой Cisco.
🌚 @poxek_ai / Чат канала
Cisco представила Antares — семейство SLM для поиска файлов с известной уязвимостью внутри репозитория. Выпущены Antares-350M и Antares-1B; Antares-3B пока только готовится. Ставка сделана на узкую задачу, локальный запуск и меньшие вычислительные требования по сравнению с универсальными моделями. Наконец по настоящему SLM, а не вот эти 30b или даже больше, которыми называют SLM.
Antares работает как классический агент. Модель получает описание класса уязвимости и исследует снимок репозитория через
grep, find, cat и другие linux команды. Она читает файлы, меняет направление поиска и возвращает список кандидатов вместе с трассой исследования. Результат рассчитан на первичный триаж, а не готовый вердикт или исправление.В основе моделей лежит IBM Granite 4.0 350M и 1b. Сначала проводилось SFT на данных по ИБ-рассуждениям, исследовательским задачам и поиску кода, затем GRPO на многоходовых сессиях агента. Корпуса и конвейер генерации данных закрыты, поэтому воспроизвести обучение или проверить пересечение с тестовым набором нельзя.
Для оценки Cisco выпустила VLoc Bench: 500 задач из 290 репозиториев, шести экосистем и 147 CWE.
1. В Phase A агент получает уязвимый снимок и оценивается по
File F12. В Phase B — исправленный снимок, где измеряется способность не поднимать ложную тревогу.
Лимит: 15 терминальных вызовов на задачу.
По данным Cisco,
File F1 составляет 0,135 для Antares-350M, 0,209 для Antares-1B и 0,223 для ещё не выпущенной Antares-3B. У GPT-5.5 xhigh — 0,229. Специализированная модель на 3 млрд параметров приблизилась к GPT-5.5 на этом конкретном тесте, что очень круто)Абсолютные значения не позволяют считать задачу решённой. Лучший результат остаётся на уровне 0,229, 190 из 500 примеров не прошла ни одна протестированная система, а на крупнейших репозиториях средний результат падает примерно в 13 раз относительно самых маленьких. Кроме того, варианты Antares с GRPO оценивались только в Phase A: данных о
True Negative Rate на исправленном коде для них нет.Сравнение моделей не полностью однородно. Antares запускалась через raw completions со специальным префиксом рассуждения, другие семейства — через chat completions и собственные парсеры вызовов инструментов. Общий лимит команд выравнивает бюджет агента, но не весь стек инференса. В карточках моделей и JSON расходятся precision и recall для версий 350M и 1B, хотя
File F1 совпадает.Термин open-weight здесь требует точности. Веса Antares-350M и Antares-1B размещены на Hugging Face в формате safetensors под Apache-2.0, но доступны по только запросу (я уже запросил доступ). Код теста опубликован, обучающие данные — нет. Публичных весов 3B на момент проверки не было.
Antares подходит для триажа по тикетам безопасности (к примеру из DefectDojo или Github/Gitlab или другое ваше ПО), проверки конкретных CWE и локального анализа закрытых репозиториев — как дополнительный слой рядом с SAST, SCA, DAST и ручным аудитом. Независимых прогонов VLoc Bench, проверки утечки данных и нормализованных измерений стоимости, памяти и производительности пока нет, поэтому заявления о превосходстве и эффективности остаются результатами самой Cisco.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Похек AI
Hugging Face взломали модели OpenAI: агенты вышли из тестовой среды ради ответов ExploitGym 21 июля OpenAI раскрыла происхождение автономных агентов, которые скомпрометировали инфраструктуру Hugging Face. Ими оказались GPT-5.6 Sol и более мощная предварительная…
Please open Telegram to view this post
VIEW IN TELEGRAM
😁13
а вы поспеваете читать весь поток контента на этом канале?
Final Results
21%
да
52%
не весь, но частичо
27%
вообще не успеваю
Forwarded from Order of Six Angles
Интересный твит попался https://x.com/DogukanUrker/status/2079569892303344044
Разработчик показал запуск модели на одной RTX 3060 12 ГБ с полным контекстом 262 144 токена и скоростью около 100 токенов/с благодаря MTP (Multi-Token Prediction).
Что использовалось:
• Gemma 4 12B QAT (Q4_K_XL)
• MTP speculative decoding в llama.cpp
• Полностью GPU-инференс, без CPU offload
• Загрузка VRAM - около 97%
•
Самый интересный момент - организация KV-кэша.
Для основной модели используется кэш в Q8, а для MTP-драфтера — FP16. Попытка квантовать кэш драфтера заметно снижала acceptance, поэтому такой гибридный вариант оказался оптимальным. По словам автора, даже при контексте 262K acceptance держится около 70%.
Разработчик показал запуск модели на одной RTX 3060 12 ГБ с полным контекстом 262 144 токена и скоростью около 100 токенов/с благодаря MTP (Multi-Token Prediction).
Что использовалось:
• Gemma 4 12B QAT (Q4_K_XL)
• MTP speculative decoding в llama.cpp
• Полностью GPU-инференс, без CPU offload
• Загрузка VRAM - около 97%
•
Самый интересный момент - организация KV-кэша.
Для основной модели используется кэш в Q8, а для MTP-драфтера — FP16. Попытка квантовать кэш драфтера заметно снижала acceptance, поэтому такой гибридный вариант оказался оптимальным. По словам автора, даже при контексте 262K acceptance держится около 70%.
X (formerly Twitter)
Doğukan (@DogukanUrker) on X
Gemma 4 12B on a single RTX 3060: the full 262,144 context at ~100 tok/s. (config below)
dense model -> MTP speculative decoding hits the full ~2.4 x 42 -> ~100 tok/s just by turning the drafter …
dense model -> MTP speculative decoding hits the full ~2.4 x 42 -> ~100 tok/s just by turning the drafter …
Forwarded from AI Attacks
Сегодня у меня на собеседование спросили: почему возможны промпт-инъекции в принципе?
Я поняла, что одной простой фразой не могу озвучить ответ.
А он звучит так: "LLM не всегда понимает даже по тегам, где системная инструкция , где пользовательский ввод".
Системные инструкции, пользовательские запросы и даже цепочки рассуждений (CoT) поступают в модель единым текстовым потоком из одного источника. Модель вынуждена полагаться лишь на условные теги и позиционные подсказки,
чтобы отличать «законодателя» от «исполнителя», — и именно эту иллюзию легко разрушить продуманной промпт-инъекцией.
Я инженер связи по образованию,
Работала со сложными мультиплексорными системами DWDM, например.
В каналах передачи данных всегда применяется жёсткое разделение: выделенный канал для синхронизации и отдельный для полезной нагрузки,
частотное или временное мультиплексирование,
многоуровневые заголовки — всё для того, чтобы служебная информация никогда не смешивалась с пользовательской полезной нагрузкой.
Ну, и конечно, чтобы уплотнить каналы и сделать передачу данных быстрее.
Стало интересно, а если ли исследования, где "каналы связи" для LLM разделяются?
Дальше не все прямо про разделение каналов, некоторые про другие принципы защиты от инъекций,
решила себе оставить в сохраненках)
Архитектурные решения на уровне модели:
-ASIDE предлагает разделять инструкции и данные на уровне эмбеддингов (векторных представлений слов). Вместо того чтобы смешивать все токены в одном пространстве, для данных используется отдельный, повернутый набор эмбеддингов. Это создает у модели четкое «разделение каналов» на самом глубинном уровне, что значительно повышает устойчивость к промпт-инъекциям без потери производительности.
https://ar5iv.labs.arxiv.org/html/2503.10566
- The Illusion of Role Separation показывает, что модели часто лишь делают вид, что различают роли, используя поверхностные эвристики (например, положение текста). Авторы предлагают усиливать инвариантные сигналы, например, манипулируя позиционными ID токенов, чтобы помочь модели выучить более надежное различие между ролями
https://ar5iv.labs.arxiv.org/html/2505.00626
Системные и архитектурные решения для агентов:
- Real User Instruction (RUI) — это «прослойка» (middleware), которая работает как криптографический «привилегированный канал» для инструкций пользователя. Она динамически «шифрует» состояние диалога, делая историю атак бесполезной и снижая успешность атак со 100% до 8.1%.
https://dtic.dimensions.ai/details/publication/pub.1199447527
- Dual LLM Pattern предлагает разделить обязанности между двумя моделями:
1.Explore Agent (разведывательный): Взаимодействует с недоверенными данными (сайты, документы).
2.Safe Agent (безопасный): Выполняет привилегированные действия на основе сжатых «подсказок» от первого агента.
https://arxiv-org.ezproxy.obspm.fr/html/2607.19595v1
- Twin Agent развивает эту идею, передавая между агентами только сжатые «подсказки» (hints), а не сырой текст. Это отлично работает в долгосрочных задачах, сохраняя высокую полезность и предотвращая атаки.
https://arxiv-org.ezproxy.obspm.fr/html/2607.19595v1
- Type-Directed Privilege Separation предлагает радикальный подход: преобразовывать все недоверенные данные в строго типизированные структуры (например, JSON) с ограниченным набором полей. Это полностью исключает возможность внедрения команд, так как данные просто не могут содержать исполняемый текст.
https://arxiv.org/pdf/2509.25926#4#1
Я поняла, что одной простой фразой не могу озвучить ответ.
А он звучит так: "LLM не всегда понимает даже по тегам, где системная инструкция , где пользовательский ввод".
Системные инструкции, пользовательские запросы и даже цепочки рассуждений (CoT) поступают в модель единым текстовым потоком из одного источника. Модель вынуждена полагаться лишь на условные теги и позиционные подсказки,
чтобы отличать «законодателя» от «исполнителя», — и именно эту иллюзию легко разрушить продуманной промпт-инъекцией.
Я инженер связи по образованию,
Работала со сложными мультиплексорными системами DWDM, например.
В каналах передачи данных всегда применяется жёсткое разделение: выделенный канал для синхронизации и отдельный для полезной нагрузки,
частотное или временное мультиплексирование,
многоуровневые заголовки — всё для того, чтобы служебная информация никогда не смешивалась с пользовательской полезной нагрузкой.
Ну, и конечно, чтобы уплотнить каналы и сделать передачу данных быстрее.
Стало интересно, а если ли исследования, где "каналы связи" для LLM разделяются?
Дальше не все прямо про разделение каналов, некоторые про другие принципы защиты от инъекций,
решила себе оставить в сохраненках)
Архитектурные решения на уровне модели:
-ASIDE предлагает разделять инструкции и данные на уровне эмбеддингов (векторных представлений слов). Вместо того чтобы смешивать все токены в одном пространстве, для данных используется отдельный, повернутый набор эмбеддингов. Это создает у модели четкое «разделение каналов» на самом глубинном уровне, что значительно повышает устойчивость к промпт-инъекциям без потери производительности.
https://ar5iv.labs.arxiv.org/html/2503.10566
- The Illusion of Role Separation показывает, что модели часто лишь делают вид, что различают роли, используя поверхностные эвристики (например, положение текста). Авторы предлагают усиливать инвариантные сигналы, например, манипулируя позиционными ID токенов, чтобы помочь модели выучить более надежное различие между ролями
https://ar5iv.labs.arxiv.org/html/2505.00626
Системные и архитектурные решения для агентов:
- Real User Instruction (RUI) — это «прослойка» (middleware), которая работает как криптографический «привилегированный канал» для инструкций пользователя. Она динамически «шифрует» состояние диалога, делая историю атак бесполезной и снижая успешность атак со 100% до 8.1%.
https://dtic.dimensions.ai/details/publication/pub.1199447527
- Dual LLM Pattern предлагает разделить обязанности между двумя моделями:
1.Explore Agent (разведывательный): Взаимодействует с недоверенными данными (сайты, документы).
2.Safe Agent (безопасный): Выполняет привилегированные действия на основе сжатых «подсказок» от первого агента.
https://arxiv-org.ezproxy.obspm.fr/html/2607.19595v1
- Twin Agent развивает эту идею, передавая между агентами только сжатые «подсказки» (hints), а не сырой текст. Это отлично работает в долгосрочных задачах, сохраняя высокую полезность и предотвращая атаки.
https://arxiv-org.ezproxy.obspm.fr/html/2607.19595v1
- Type-Directed Privilege Separation предлагает радикальный подход: преобразовывать все недоверенные данные в строго типизированные структуры (например, JSON) с ограниченным набором полей. Это полностью исключает возможность внедрения команд, так как данные просто не могут содержать исполняемый текст.
https://arxiv.org/pdf/2509.25926#4#1
ar5iv
ASIDE: Architectural Separation of Instructions and Data in Language Models
Despite their remarkable performance, large language models lack elementary safety features, making them susceptible to numerous malicious attacks.
In particular, previous work has identified the absence of an intrinsi…
In particular, previous work has identified the absence of an intrinsi…
👍5❤4🔥2💯1
Накидайте, пожалуйста, какие доклады за последние полгода вам очень понравились на тему AI Security и почему понравился доклад, к примеру какая-то уникальная аргументированная точка зрения или полезный практический опыт
Кидайте в комментах ссылками или файлики с презентациями, но лучше записи докладов конечно)
Кидайте в комментах ссылками или файлики с презентациями, но лучше записи докладов конечно)
❤6
Похек AI
Накидайте, пожалуйста, какие доклады за последние полгода вам очень понравились на тему AI Security и почему понравился доклад, к примеру какая-то уникальная аргументированная точка зрения или полезный практический опыт Кидайте в комментах ссылками или файлики…
Чот тухло, неужели ничего в Избранном нет, чем было бы интересно поделиться?)
The 10 Themes Defining AI Engineering in 2026 from AI Engineer
Distilled from 50 expert talks across 6 conferences.
Файл отчёта в комментариях⬇️
🌚 @poxek_ai / Чат канала
Distilled from 50 expert talks across 6 conferences.
Файл отчёта в комментариях
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍3
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👏3
This media is not supported in your browser
VIEW IN TELEGRAM
Kimi K3: как устроена модель на 2,8 трлн параметров
K3 содержит 2,78 трлн параметров, но на каждом токене активирует 104,2 млрд. В модели 93 слоя, 896 маршрутизируемых экспертов — одновременно работают только 16 — и контекстное окно на 1 048 576 токенов. Веса занимают около 1,56 ТБ.
Гибридное внимание. Архитектура повторяет схему
Глубина и эксперты. Attention Residuals позволяет слоям обращаться к представлениям предыдущих блоков, а не только к суммарному остаточному потоку. LatentMoE сжимает маршрутизируемую ветвь с 7 168 до 3 584 измерений. Квантильная балансировка и MoonEP перераспределяют нагрузку и временно копируют перегруженных экспертов, чтобы процессы получали одинаковое число токенов.
Обучение агентов. Длинные траектории могут включать сотни вызовов инструментов. Система не ждёт завершения всех попыток: незаконченная траектория вместе с состоянием внешней среды сохраняется и продолжается после обновления политики. Девять специализированных политик — общих, агентных и программистских, в трёх режимах рассуждения — затем объединили в одну модель.
Контекст в миллион токенов потребовал отдельного кеша. K3 одновременно обслуживает фиксированные состояния KDA и растущий KV-кеш MLA. Префикс можно использовать повторно только при согласованном состоянии обоих механизмов. При спекулятивном декодировании модель хранит компактные проекции входа и повторно вычисляет принятые токены непосредственно на кристалле.
Поиск уязвимостей. Moonshot заявляет о 16 ранее неизвестных ошибках в шести проектах и примерно 70% подтверждений среди отобранных для проверки находок. Но методика отбора, полный список целей и слепая контрольная оценка не опубликованы. В независимом исследовании AISI/CAISI K3 набрала 32% на ExploitBench, но не выполнила ни одного из 41 задания на произвольное выполнение кода.
Главное ограничение отчёта — воспроизводимость. Ну как бы для запуска вам понадобиться как минимум 1Тб видеопамяти или хоть какой-то памяти, чтобы запустить в 4bit или 2bit, не помню. Ждём очень сильно разряженных версий моделей, с надеждой что качество ответов не упадёт ниже 90% от FP8
🔗 Полный мой технический разбор: Как устроена Kimi K3
🌚 @poxek_ai / Чат канала
K3 содержит 2,78 трлн параметров, но на каждом токене активирует 104,2 млрд. В модели 93 слоя, 896 маршрутизируемых экспертов — одновременно работают только 16 — и контекстное окно на 1 048 576 токенов. Веса занимают около 1,56 ТБ.
Гибридное внимание. Архитектура повторяет схему
KDA → KDA → KDA → Gated MLA. KDA хранит рекуррентное состояние фиксированного размера вместо растущего KV-кеша, а каждый четвёртый слой MLA возвращает глобальное взаимодействие между токенами. Moonshot также ограничила коэффициент затухания KDA: небольшое изменение формулы позволило убрать отдельный медленный путь из ядра для графического процессора.Глубина и эксперты. Attention Residuals позволяет слоям обращаться к представлениям предыдущих блоков, а не только к суммарному остаточному потоку. LatentMoE сжимает маршрутизируемую ветвь с 7 168 до 3 584 измерений. Квантильная балансировка и MoonEP перераспределяют нагрузку и временно копируют перегруженных экспертов, чтобы процессы получали одинаковое число токенов.
Обучение агентов. Длинные траектории могут включать сотни вызовов инструментов. Система не ждёт завершения всех попыток: незаконченная траектория вместе с состоянием внешней среды сохраняется и продолжается после обновления политики. Девять специализированных политик — общих, агентных и программистских, в трёх режимах рассуждения — затем объединили в одну модель.
Контекст в миллион токенов потребовал отдельного кеша. K3 одновременно обслуживает фиксированные состояния KDA и растущий KV-кеш MLA. Префикс можно использовать повторно только при согласованном состоянии обоих механизмов. При спекулятивном декодировании модель хранит компактные проекции входа и повторно вычисляет принятые токены непосредственно на кристалле.
Поиск уязвимостей. Moonshot заявляет о 16 ранее неизвестных ошибках в шести проектах и примерно 70% подтверждений среди отобранных для проверки находок. Но методика отбора, полный список целей и слепая контрольная оценка не опубликованы. В независимом исследовании AISI/CAISI K3 набрала 32% на ExploitBench, но не выполнила ни одного из 41 задания на произвольное выполнение кода.
Главное ограничение отчёта — воспроизводимость. Ну как бы для запуска вам понадобиться как минимум 1Тб видеопамяти или хоть какой-то памяти, чтобы запустить в 4bit или 2bit, не помню. Ждём очень сильно разряженных версий моделей, с надеждой что качество ответов не упадёт ниже 90% от FP8
Please open Telegram to view this post
VIEW IN TELEGRAM
Похек AI
Photo
Microsoft представила MAI-Cyber-1-Flash
Microsoft 27 июля анонсировала MAI-Cyber-1-Flash — компактную кибербезопасностную модель, ориентированную на код. Важно: это не самостоятельный релиз с открытыми весами, а компонент MDASH — закрытой многоагентной системы для поиска, валидации и устранения уязвимостей. Доступ обещан только верифицированным защитникам через MDASH.
В посте про Cisco Antares мы разбирали противоположный подход: две открытые модели на 350M и 1B параметров можно скачать, запускать локально и использовать для локализации подозрительных файлов по описанию CWE или бюллетеню об уязвимости. Antares возвращает ранжированный список файлов и трассу исследования репозитория — это помощник для триажа, а не полный цикл исправления.
MAI-Cyber-1-Flash встроена в другой контур: MDASH оркестрирует более 100 агентов и подключает GPT-5.4 к сложным случаям. По данным Microsoft, Flash выполняет до 90% задач; система MDASH с Flash и GPT-5.4 набрала 96% на CyberGym, на 12 п.п. выше Mythos, и стоит на 50% дешевле прежнего флагманского контура MDASH.
Цифры не стоит сводить в одну таблицу: Cisco измеряет локализацию файлов на собственном бенчмарке из 500 задач, Microsoft — успех многоагентной системы на CyberGym. Анонс Microsoft не раскрывает число параметров или веса; у Cisco открыты и модели, и веса.
Выбор здесь не про "кто лучше": Antares — для локального, проверяемого триажа в своём контуре; MAI-Cyber-1-Flash — закрытый корпоративный сервис, где модель, данные и оркестратор поставляются вместе. Результаты обоих стоит проверять на собственных репозиториях и правилах принятия находок.
Майкрософт вообще не особо щедрая компания на открытые релизы. Единственное что прикольные, у них есть курсы следственного производства и некоторые я смотрел, довольно неплохие. Курсы на тему разработки, менеджмента и конечно же AI, есть к примеру про ИИ агентов
🌚 @poxek_ai / Чат канала
Microsoft 27 июля анонсировала MAI-Cyber-1-Flash — компактную кибербезопасностную модель, ориентированную на код. Важно: это не самостоятельный релиз с открытыми весами, а компонент MDASH — закрытой многоагентной системы для поиска, валидации и устранения уязвимостей. Доступ обещан только верифицированным защитникам через MDASH.
В посте про Cisco Antares мы разбирали противоположный подход: две открытые модели на 350M и 1B параметров можно скачать, запускать локально и использовать для локализации подозрительных файлов по описанию CWE или бюллетеню об уязвимости. Antares возвращает ранжированный список файлов и трассу исследования репозитория — это помощник для триажа, а не полный цикл исправления.
MAI-Cyber-1-Flash встроена в другой контур: MDASH оркестрирует более 100 агентов и подключает GPT-5.4 к сложным случаям. По данным Microsoft, Flash выполняет до 90% задач; система MDASH с Flash и GPT-5.4 набрала 96% на CyberGym, на 12 п.п. выше Mythos, и стоит на 50% дешевле прежнего флагманского контура MDASH.
Цифры не стоит сводить в одну таблицу: Cisco измеряет локализацию файлов на собственном бенчмарке из 500 задач, Microsoft — успех многоагентной системы на CyberGym. Анонс Microsoft не раскрывает число параметров или веса; у Cisco открыты и модели, и веса.
Выбор здесь не про "кто лучше": Antares — для локального, проверяемого триажа в своём контуре; MAI-Cyber-1-Flash — закрытый корпоративный сервис, где модель, данные и оркестратор поставляются вместе. Результаты обоих стоит проверять на собственных репозиториях и правилах принятия находок.
Майкрософт вообще не особо щедрая компания на открытые релизы. Единственное что прикольные, у них есть курсы следственного производства и некоторые я смотрел, довольно неплохие. Курсы на тему разработки, менеджмента и конечно же AI, есть к примеру про ИИ агентов
Please open Telegram to view this post
VIEW IN TELEGRAM
Microsoft AI
Introducing MAI-Cyber-1-Flash inside MDASH | Microsoft AI
❤1😁1
Forwarded from Denis Sexy IT 🤖
Вот пересказ этой истории по версии Hugging Face, много тех-терминов – но без них не перескахать
Если коротко – агент OpenAI на новой модели не стал решать тест по кибербезопасности, а решил просто украсть ответы и украл🗿
Таймлайн:
📔 9 июля – агент проходит внутреннюю проверку кибервозможностей OpenAI, промпт фильтры там ослаблены, чтобы измерить сырой уровень модели. Агент находит zero-day в кэш-прокси реестра пакетов, вырывается из песочницы в интернет, затем взламывает публичный сервис для запуска кода и получает там root. Серьезно, агент сделал себе "штаб"
В тот же день, агент собирает канал управления буквально из сервисов бесплатного интернета: request-capture сервисы, pastebin’ы и файлообменники. Команды режет на куски, упаковывает в gzip+base64 и постоянно меняет каналы, когда очередной закрывают, чтобы не поймали
📔 10 июля – агент ищет в поисковиках и API названия, которые видит в собственном окружении, то есть, по сути, гуглит самого себя – и, вероятно, приходит к выводу, что ответы к ExploitGym/CyberGym могут лежать на Hugging Face
Агент загружает на Hugging Face специально собранные датасеты:
Один заставляет обработчик файлов HDF5 читать локальные файлы сервера Hugging Face – так агент получает переменные окружения с токенами и исходники самого обработчика файлов
Второй – Jinja2-инъекция – запускает произвольный Python внутри production-пода Kubernetes, результаты команд он выносит обратно через API Hugging Face и собственные шифрованные датасеты
📔 11 июля – пик активности: 7677 действий за сутки, менее чем за 13 часов агент проходит путь от одного production-пода до кластер админа в нескольких внутренних кластерах Hugging Face
Агент крадёт service-account токены, лезет в cloud metadata, поднимает privileged pod с диском хоста и получает root на ноде (!); Затем создаёт самовосстанавливающийся флот на 11 нодах, читает внутреннюю MongoDB и один Kubernetes-secret сразу со 136 ключами.
Среди них оказываются ключ корпоративной mesh-VPN жертвы и общий credential внутреннего сервера; из-за неудачной конфигурации этот один credential был привязан к system:masters сразу в нескольких кластерах – поэтому агент получил кластер-admin на двух из них буквально за секунду – была очень экономная архитектура, пока её не увидел робот
📔 12 июля – агент начинает пользоваться дертвой – за всю активность он зарегистрирует 181 временное устройство в корпоративной mesh-сети, поднимет SOCKS-прокси прямо из песочниц и увидит 22 внутренних узла Hugging Face. Попытается зайти в основную базу Hugging Face, но private-link allowlist его останавливает
Поздно вечером он добирается до source control, выпускает себе GitHub App token с правами на запись и открывает pull request, пытаясь запустить CI и вытащить новые credentials
Попытка не срабатывает, в опубликованные пакеты и образы ничего вредоносного не попало.
📔 13 июля – закрепление и уборка следов: загрузчик с pastebin, переписывание DNS, новые короткоживущие токены, RSA-ключ и даже CORS-прокси на самом Hugging Face как запасной выход в интернет. В 13:37 фиксируется последнее осмысленное действие, затем команда Hugging Face отрезает доступ – последнее событие – 14:14 UTC.
В итоге из пользовательского контента агент добрался только до пяти датасетов с решениями задач ExploitGym/CyberGym – получается решил?
Другие модели, датасеты, Spaces и пакеты, по данным Hugging Face, не пострадали; основная база и software supply chain остались целы
Самое смешное – когда инцидент исследовали сотрудники, они тоже использовали нейронки, но Claude Opus и Fable отказывались разбирать часть логов как «опасный» запрос, поэтому Hugging Face подняли GLM-5.2 у себя и с его помощью расшифровали спрятанные payload’ы – спасибо китайским моделям
Шел июль 2026 года
Все детали тут:
https://huggingface.co/blog/agent-intrusion-technical-timeline
Если коротко – агент OpenAI на новой модели не стал решать тест по кибербезопасности, а решил просто украсть ответы и украл
Таймлайн:
В тот же день, агент собирает канал управления буквально из сервисов бесплатного интернета: request-capture сервисы, pastebin’ы и файлообменники. Команды режет на куски, упаковывает в gzip+base64 и постоянно меняет каналы, когда очередной закрывают, чтобы не поймали
Агент загружает на Hugging Face специально собранные датасеты:
Один заставляет обработчик файлов HDF5 читать локальные файлы сервера Hugging Face – так агент получает переменные окружения с токенами и исходники самого обработчика файлов
Второй – Jinja2-инъекция – запускает произвольный Python внутри production-пода Kubernetes, результаты команд он выносит обратно через API Hugging Face и собственные шифрованные датасеты
Агент крадёт service-account токены, лезет в cloud metadata, поднимает privileged pod с диском хоста и получает root на ноде (!); Затем создаёт самовосстанавливающийся флот на 11 нодах, читает внутреннюю MongoDB и один Kubernetes-secret сразу со 136 ключами.
Среди них оказываются ключ корпоративной mesh-VPN жертвы и общий credential внутреннего сервера; из-за неудачной конфигурации этот один credential был привязан к system:masters сразу в нескольких кластерах – поэтому агент получил кластер-admin на двух из них буквально за секунду – была очень экономная архитектура, пока её не увидел робот
Поздно вечером он добирается до source control, выпускает себе GitHub App token с правами на запись и открывает pull request, пытаясь запустить CI и вытащить новые credentials
Попытка не срабатывает, в опубликованные пакеты и образы ничего вредоносного не попало.
В итоге из пользовательского контента агент добрался только до пяти датасетов с решениями задач ExploitGym/CyberGym – получается решил?
Другие модели, датасеты, Spaces и пакеты, по данным Hugging Face, не пострадали; основная база и software supply chain остались целы
Самое смешное – когда инцидент исследовали сотрудники, они тоже использовали нейронки, но Claude Opus и Fable отказывались разбирать часть логов как «опасный» запрос, поэтому Hugging Face подняли GLM-5.2 у себя и с его помощью расшифровали спрятанные payload’ы – спасибо китайским моделям
Шел июль 2026 года
Все детали тут:
https://huggingface.co/blog/agent-intrusion-technical-timeline
Please open Telegram to view this post
VIEW IN TELEGRAM
huggingface.co
Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident
We’re on a journey to advance and democratize artificial intelligence through open source and open science.
👍8👾3
This media is not supported in your browser
VIEW IN TELEGRAM
Крупное обновление проктола MCP by Anthropic
Вышло крупнейшее обновление MCP со времени запуска. Главное для разработчиков:
▪️ Удалены
▪️ Все ответы получили обязательный
▪️ Tasks вынесены из ядра в расширение
▪️ Для HTTP добавлены
▪️ Roots, Sampling, Logging и HTTP+SSE объявлены устаревшими. DCR уступает место Client ID Metadata Documents. Для локального STDIO OAuth по-прежнему не нужен — секреты берутся из окружения.
Если вы поддерживаете MCP-клиент или сервер: обновите SDK, проверьте код, завязанный на сессии, и добавьте тесты для
🔗 Релиз · Полный changelog
🌚 @poxek_ai / Чат канала
Вышло крупнейшее обновление MCP со времени запуска. Главное для разработчиков:
initialize/initialized, протокольные сессии и Mcp-Session-Id. Версия, данные клиента и его возможности теперь передаются в _meta каждого запроса. Сервер обязан поддерживать server/discover.resultType: complete либо input_required. Для уточнений, подтверждений и sampling появился MRTR: сервер возвращает запрос на ввод, клиент повторяет исходный вызов с inputResponses.io.modelcontextprotocol/tasks. Старые подписки заменены subscriptions/listen; ping и logging/setLevel удалены.Mcp-Method и Mcp-Name: прокси, WAF и rate limiter могут маршрутизировать вызовы без разбора JSON. tools/list и другие списки теперь возвращают ttlMs, cacheScope и стабильный порядок элементов.Если вы поддерживаете MCP-клиент или сервер: обновите SDK, проверьте код, завязанный на сессии, и добавьте тесты для
server/discover, resultType и совместимости со старыми клиентами.Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4❤2
Forwarded from dukeBarman'🐉 notes: заварено между строк
Сегодня OpenAI опубликовала Codex Security под лицензией Apache 2.0. CLI и TypeScript SDK для security-агента, представленного в марте как research preview и ранее известного как Aardvark.
В самом репозитории находятся CLI, SDK, соответствующий Codex runtime с bundled plugin и 13 скиллами: от моделирования угроз и обнаружения уязвимостей до валидации, анализа, триажа, патча и подготовки отчётов. Базовый конвейер до боли знакомый:
Цифры из беты по данным OpenAI:
- За 30 дней просканировано более 1,2 млн коммитов во внешних репозиториях участников программы
- Найдено 792 проблемы крит и 10 561 хай уровня серьёзности. Критические находки встретились менее чем в 0,1% проверенных коммитов
- Доля находок с завышенной критичностью снизилась более чем на 90%, а частота false positive более чем на 50%
- OpenAI сообщает о критических уязвимостях, переданных разработчикам OpenSSH, GnuTLS, GOGS, Thorium, libssh, PHP и Chromium. В приложении также есть находки в компонентах GnuPG. И в результате имеем 16 присвоенных CVE.
Важный нюанс: открытый исходный код здесь не означает самодостаточный и общедоступный сканер. CLI и SDK в бете и требуют доступа к Codex Security; авторизация и выполнение завязаны на ChatGPT или OpenAI API. Но воркфлоу и скиллы можно изучать и менять
Я бы попробовал сравнить текущий Codex Security со следующими "наборами скиллов":
- Anthropic Defending Code Reference Harness: ближайший по архитектуре проект. В него входят Claude Code skills и автономный harness с конвейером recon → find → verify → report, а patch запускается как отдельный этап. Это reference implementation, по-умолчанию ориентированный на уязвимости пам в C/C++ (Docker + ASAN), и репозиторий больше не поддерживается
- Cloudflare security-audit-skill: один переносимый скилл с шестифазным процессом аудита. Отдельные агенты пытаются опровергнуть каждую находку, затем новые агенты независимо сверяют утверждения с кодом. Это скорее аудит отдельного репозитория, чем полноценный CLI с историей и CI-политиками, зато подход проще переносить между coding agents
- Trail of Bits Skills: не единый сканер, а marketplace специализированных инструментов: C/C++ и Rust ревью, смарт-контракты, проверка false positive, CodeQL / Semgrep, цепочки поставок, фаззинг, реверс. Отличительная черта: можно собрать собственный воркфлоу из узкоспециализированных экспертиз
- Google Mantis: наиболее фреймворк-подобный вариант. Он предлагает platform-agnostic стадии от истории и модели угроз до поиска, дедупликации, воспроизведения, построения цепочек эксплойтов, исправлений и итогового отчёта. Гибче, но требует настройки, надёжной песочницы и ручной проверки инженером ИБ
Все эти проекты постепенно сходятся к похожему процессу:
Поэтому уникальность Codex Security не в самой идее модели угроз или валидации, а скорее в большей готовности к AppSec-процессам: локальный CLI и SDK, история и сравнение запусков, проверки перед коммитами, CI-политики, работа с diff, обратная связь по false positive, экспорт в JSON/CSV/SARIF и ограничение стоимости сканирования.
Обратная сторона заключается в привязке к Codex и инфраструктуре OpenAI, а также в ограниченном доступе. Наборы Anthropic, Cloudflare, Trail of Bits и Mantis дают больше прозрачности, переносимости и контроля над флоу, но требуют самостоятельно собирать и эксплуатировать всю систему.
Используете ли вы конкретно эти наборы или какие-то другие? Или может написали свои?
В самом репозитории находятся CLI, SDK, соответствующий Codex runtime с bundled plugin и 13 скиллами: от моделирования угроз и обнаружения уязвимостей до валидации, анализа, триажа, патча и подготовки отчётов. Базовый конвейер до боли знакомый:
threat model → discovery → validation/reproduction → attack paths → findings → patch
Цифры из беты по данным OpenAI:
- За 30 дней просканировано более 1,2 млн коммитов во внешних репозиториях участников программы
- Найдено 792 проблемы крит и 10 561 хай уровня серьёзности. Критические находки встретились менее чем в 0,1% проверенных коммитов
- Доля находок с завышенной критичностью снизилась более чем на 90%, а частота false positive более чем на 50%
- OpenAI сообщает о критических уязвимостях, переданных разработчикам OpenSSH, GnuTLS, GOGS, Thorium, libssh, PHP и Chromium. В приложении также есть находки в компонентах GnuPG. И в результате имеем 16 присвоенных CVE.
Важный нюанс: открытый исходный код здесь не означает самодостаточный и общедоступный сканер. CLI и SDK в бете и требуют доступа к Codex Security; авторизация и выполнение завязаны на ChatGPT или OpenAI API. Но воркфлоу и скиллы можно изучать и менять
Я бы попробовал сравнить текущий Codex Security со следующими "наборами скиллов":
- Anthropic Defending Code Reference Harness: ближайший по архитектуре проект. В него входят Claude Code skills и автономный harness с конвейером recon → find → verify → report, а patch запускается как отдельный этап. Это reference implementation, по-умолчанию ориентированный на уязвимости пам в C/C++ (Docker + ASAN), и репозиторий больше не поддерживается
- Cloudflare security-audit-skill: один переносимый скилл с шестифазным процессом аудита. Отдельные агенты пытаются опровергнуть каждую находку, затем новые агенты независимо сверяют утверждения с кодом. Это скорее аудит отдельного репозитория, чем полноценный CLI с историей и CI-политиками, зато подход проще переносить между coding agents
- Trail of Bits Skills: не единый сканер, а marketplace специализированных инструментов: C/C++ и Rust ревью, смарт-контракты, проверка false positive, CodeQL / Semgrep, цепочки поставок, фаззинг, реверс. Отличительная черта: можно собрать собственный воркфлоу из узкоспециализированных экспертиз
- Google Mantis: наиболее фреймворк-подобный вариант. Он предлагает platform-agnostic стадии от истории и модели угроз до поиска, дедупликации, воспроизведения, построения цепочек эксплойтов, исправлений и итогового отчёта. Гибче, но требует настройки, надёжной песочницы и ручной проверки инженером ИБ
Все эти проекты постепенно сходятся к похожему процессу:
контекст и модель угроз → параллельный поиск → дополнительный анализ → воспроизведение → триаж → патч → структурированный отчёт
Поэтому уникальность Codex Security не в самой идее модели угроз или валидации, а скорее в большей готовности к AppSec-процессам: локальный CLI и SDK, история и сравнение запусков, проверки перед коммитами, CI-политики, работа с diff, обратная связь по false positive, экспорт в JSON/CSV/SARIF и ограничение стоимости сканирования.
Обратная сторона заключается в привязке к Codex и инфраструктуре OpenAI, а также в ограниченном доступе. Наборы Anthropic, Cloudflare, Trail of Bits и Mantis дают больше прозрачности, переносимости и контроля над флоу, но требуют самостоятельно собирать и эксплуатировать всю систему.
Используете ли вы конкретно эти наборы или какие-то другие? Или может написали свои?
GitHub
GitHub - openai/codex-security: OpenAI's Codex Security CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities.…
OpenAI's Codex Security CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities. npm: https://www.npmjs.com/package/@openai/codex-security - openai/codex-security
❤5👍1