Semgrep написали у себя в блоге, что GLM 5.2 показало очень хорошие результаты на их внутреннем бенчмарке

На скрине вы можете увидеть среду тестирования и модель+харнесс. Я не доволен условиями тестирования, т.к. команда Semgrep сделала не консистентные сравнения, что считаю критичной ошибкой для их оценки, но в данном случае GLM 5.2 только в более сильном свете показывается

Я вчера купил себе coding plan за 16$, полёт хороший. Пока только в разработке тестирую на модели GLM 5.2 (более низкие беру только под всякие разведки файлов и т.д.). Вчера очень прикольно настроил себе opencode, а сегодня добрался до ZCode - это очень близкий аналог к Codex Desktop

GLM 5.2 tps высокий и без долгой задержки первого токена, как у Попуса 4.8. Модель достаточно лаконично, хотя иногда явно излишне ризонит внутри себя. Но качество радует. Из заметных минусов, выбор effort ограничен только high & max режимами, я довольно часто даже gpt-5.5 на medium использую, т.к. в большинстве задач high излишен

Могу точно сказать, что подписка Lite за 16$ - это примерно 15-15,5 миллионов токенов

🌚 @poxek_ai / Чат канала

RLM и subRLM: зачем агентам рекурсивное мышление

Большое контекстное окно не превращает LLM-агента в долгоживущую рабочую память. Репозиторий может формально влезать в 200K токенов, можно пульнуть весь лог целиком, историю чата можно тащить ещё десятки шагов, но качество всё равно начинает проседать через 30-50 тёрнов (действий): агент теряет цель, повторяет проверенные гипотезы, отвлекается на явный для человека шум и хуже связывает факты. Узкое место в том, что весь рабочий след складывается в одну линейную историю.

RLM предлагает другую форму работы агентов. В значении Recursive Language Model это не обязательно новый тип весов, а runtime-паттерн: главный агент получает задачу, но большой контекст лежит во внешней среде, например в Python REPL как переменная. Модель не читает всё сразу, а пишет код, ищет нужные фрагменты, режет данные на части, запускает дочерние LM-вызовы и собирает итоговый ответ. Контекст становится объектом, с которым можно работать программно, а не стеной текста, который надо проглотить целиком.

Здесь важно не перепутать термины. RLM иногда расшифровывают как Reasoning Language Model: это уже разговор о моделях, обученных тратить больше inference-time compute на многошаговое рассуждение. Recursive Language Model — другой слой: способ организовать выполнение вокруг любой подходящей LLM. Первая тема про способность модели рассуждать, вторая — про инженерную схему управления контекстом.

subRLM — ещё более узкая штука. Это не “маленькая RLM-модель”, а изолированный дочерний вызов для одной подзадачи. Основной агент остаётся координатором, формулирует локальную задачу, передаёт ограниченный контекст, получает короткий результат и решает, как использовать его дальше. В нашем случае это может быть отдельный codex exec с ролью, таймаут, моделью и git worktree. В готовых harness вроде Codex, Claude Code или OpenCode такой subRLM функционально почти повторяет механизм субагентов: чистый контекст, отдельная инструкция, локальная работа, результат наверх. Разница в упаковке: subagent встроен в harness, subRLM логичнее вписывать в самописную AI инфру.

Если кратко:

RLM = root-agent + внешняя среда + декомпозиция + sub-calls + синтез
subRLM = один изолированный worker-call для конкретной ветки

Это оправдано, когда задача ломается правда долгая и даже 1 млн контекста не помогает. Большие репозитории, длинные логи, ASR-транскрипты, длиннючие issue-треды, сравнение десятков источников, security review, независимая проверка гипотез — хорошие кандидаты. В таких задачах полезно разнести анализ по чистым контекстам и вернуть в главный поток только сжатые выводы.

Но RLM/subRLM не надо включать по привычке. Короткий вопрос, одно изменение в одном файле, простая проверка через grep, SQL, парсер или тест не становятся лучше от рекурсии. Дочерние вызовы стоят токенов, добавляют задержку, усложняют трассировку и могут породить fan-out, где система тратит больше времени на координацию, чем на работу.

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

Основной для изучения брал это исследование и эту статью. Альтернативное чтиво, особенно для тех кто юзает Google ADK. Но если честно мне кажется я недораскрыл потенциал концепции RLM

🌚 @poxek_ai / Чат канала

Sonnet 5 вышел! Бегом тестить))

https://www.anthropic.com/news/claude-sonnet-5

upd: судя по кибербез метрикам он хуже, чем предыдуший sonnet 4.6 из-за того что его также задушили, как Fable 5. Сейчас уже ослабили гардрейл, но подбешивает чаще чем предыдущая модель. Хотя у ученика одного, новая модель смогла раскрутить багу лучше, чем Попус 4.8

🌚 @poxek_ai / Чат канала

Я нашел новую Sec-Gemini 3 от 💙💛💚 — и это выглядит как один из жестких заходов в ИБ-автоматизацию от крупных игроков

Разобрал свежий 🐱 google/sec-gemini, сайт, документацию и 😊 демо Sec-Gemini 3. Снаружи это подается как кибербез модель от Google, но по факту там уже не просто чатик для анализа CVE. Это рабочая платформа для расследований, пентеста, анализа логов, ревью кода и сборки отчетов.

Самая вкусный момент — демо с ретроспективным DFIR-расследованием старого Log4Shell-инцидента. Sec-Gemini дали 7 разнородных источников логов, больше 650k записей и почти нулевой контекст о чём задача. В ролике модель сама восстанавливает таймлайн компрометации, находит Log4Shell как вектор входа, видит закрепление хакеров через cron каждые 5 минут и раскладывает активность по MITRE ATT&CK. Заявленный результат — те же выводы, что у ручной форензик команды, за 12 минут 34 секунды и примерно $1.50 стоимость компьюта.

Отдельно проверил репозиторий и документацию. Там есть Python SDK, TypeScript SDK, CLI, веб компоненты и режим подключения своих локальных инструментов. Последний пункт особенно острый: при неправильном запуске такая система получает доступ к файлам, shell, Python/JS и сети с правами текущего пользователя. То есть экспериментировать с этим надо в VM или одноразовой среде, а не на рабочем ПеКа с личными/корпоративными данными.

Мой вывод: Google не просто выкатывает еще одну связку из непонятно чего для кибербеза. Они тестируют формат, где ИБ-задача превращается в длинное воспроизводимое расследование: данные, инструменты, промежуточные факты, гипотезы, отчет. Если это доживет до нормального доступа и вменяемых ограничений, SOC и pentest workflows начнут меняться очень быстро.

Все: нам нужен Mythos
Google: у нас есть свой Mythos дома

🌚 @poxek_ai / Чат канала

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

Коротко
▪️AI стал поверхностью атаки там, где модель получает не только текст, но и данные, инструменты, права и доверенный контекст. Но вроде как агент без всего этого бесполезено...?)
▪️Самые сильные публичные кейсы сегодня не про “модель сама нашла 0day”, а про деньги, утечки, токены, рабочие базы, расширения браузера, агентные действия и фишинг под видом AI-сервисов.
▪️В статье кейсы ранжируются по наблюдаемому ущербу: прямые потери и утечки выше исследовательских PoC.

AI уже надо учитывать как отдельную поверхность атаки. Не потому, что модели «сами взламывают компании», а потому что вокруг них появились новые доверенные контуры: ИИ-платформы хранят чаты, токены, исходный код и пользовательские данные; ИИ-бренды используют в фишинге; ИИ-инструменты получают доступ к браузеру, почте, GitHub, терминалу и боевым средам; агенты начинают действовать от имени пользователя.

Просьба поддержать аппами и комментариями на Habr)
https://habr.com/ru/articles/1054618/

🌚 @poxek | 🌚 @poxek_ai | 📲

Китайский регламент по ИИ-агентам

Китайский TC260 выпустил практическое руководство по безопасному развертыванию ИИ-агентов. По сути, это чек-лист для систем, которым пользователь дает память, инструменты, доступ к файлам, API, браузеру, внутренним сервисам и иногда к финансовым операциям.

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

Любая компания может превратить эти правила во внутренний стандарт: реестр ИИ-агентов, владелец и бизнес-цель для каждого экземпляра, список подключенных моделей, навыков и инструментов, границы доступа к данным, обязательный kill switch, MFA, периодическая проверка долговременной памяти, отзыв токенов при выводе из эксплуатации.

На уровне государства это можно использовать как базовый профиль для сертификации и аудита: проверять не "умность" модели, а операционные контуры вокруг агента — кто его поставил, где он запущен, какие действия он может выполнить, какие логи остаются, как обнаруживается Shadow AI и как быстро можно отключить опасный экземпляр.

К посту приложил механический перевод китайской pdf регламента ИБ ИИ агентов на русский язык. Вышло вроде сносно)

Источник: уведомление TC260 и PDF «智能体部署使用安全指引». Спасибо админу Russian OSINT за наводку по инфе

🌚 @poxek_ai / Чат канала

FreeBSoD: LLM как ускоритель исследования уязвимостей ядра

Praetorian выпустили две части FreeBSoD: про поиск багов в ядре FreeBSD и про разработку эксплойтов для выхода из jail с Claude Code/Opus 4.6. В первой части агент использовали не как автономного "охотника за 0day", а как часть проверяемого цикла: собрать базу паттернов, сгенерировать правила CodeQL/semgrep, найти похожие варианты багов и проверять кандидаты в KASAN(Kernel Address Sanitizer)-сборке FreeBSD. Так нашли около восьми уязвимостей; публично детально раскрыта только CVE-2026-3038.

CVE-2026-3038 - переполнение стека в rtsock_msg_buffer(): пользовательский sa_len мог дать 127 байт переполнения sockaddr_storage на стеке через сокеты маршрутизации. Бюллетень FreeBSD описывает эффект как локальный отказ в обслуживании и возможное повышение привилегий при наличии дополнительного бага для обхода стековой canary. Дефолтный результат - надежное падение ядра, а не автоматический root.

Во второй части Praetorian показывают две цепочки выхода из FreeBSD jail. Первая комбинирует утечку со стека для canary/KASLR с переполнением RTSock. Вторая идет через переполнение кучи, подготовку malloc-32768, повреждение таблицы файловых дескрипторов и смешение объектов pipe/file. Агент не смог сразу собрать цепочку: ломался на ROP, терял контекст, иногда предлагал недопустимые условия вроде загрузки модуля ядра. Рабочим оказался поэтапный конвейер L0-L4, где каждый шаг проверяет одну новую вещь: срабатывание KASAN, контроль RIP, обход SMEP/SMAP, затем полный выход из jail.

🌚 @poxek_ai / Чат канала

Security Context: память о старых уязвимостях для AI-агента

ProjectDiscovery запустили Security Context — бесплатный сервис для публичных GitHub-репозиториев, который превращает историю исправлений безопасности в контекст для AI-агента. Идея простая: если агент в проекте уже чинил XSS, SSRF, обход авторизации или десериализацию, то агенту полезно знать не только текущий код, но и паттерн прошлой поломки.

Сервис читает историю коммитов, диффы и публичные CVE/GHSA, отфильтровывает security-fix коммиты и сохраняет для каждого исправления три вещи: sink, guard и способ эксплуатации. Потом эти отпечатки сравниваются с текущим кодом. На выходе есть два рабочих артефакта: SECURITY_CONTEXT.md для разработки и ревью, чтобы не откатить старую защиту, и VARIANT_LEADS.md для ресерча, где перечислены похожие незащищенные места в актуальном коде.

Практически это закрывает дыру в agentic AppSec: Context7 дает агенту документацию, DeepWiki помогает быстро прочитать кодовую базу, а Security Context добавляет память о том, где этот конкретный проект уже ломался. Через MCP доступны get_security_context, get_vulnerability_leads и create_security_context. REST API тоже есть. Чтение контекста безлимитное, создание нового анализа ограничено 10 репозиториями в день на IP. Авторизация не нужна, но скоуп жесткий: только публичные GitHub-репозитории, и результаты публичны. Поэтому я бы не рискнул таким пользоваться, лучше попробовать эксфильтровать промпт и самому такое поднять))

Я успел попользоваться какое-то время на своих публичных репах, т.к. в большинстве я работаю в приватных репах и вообще на self hosted Gitea и Gitlab, то мне такой сервис не подходит. Но ничего не мешает тихо сп***ить эксфильтровать и поднять самому аналогичный сервис, хоть и без сильной поддержки от команды PD

🔗 Источники: securitycontext.dev и документация

🌚 @poxek_ai / Чат канала

Gemma 4: техническая карта

2 июля Google DeepMind выложила на arXiv Gemma 4 Technical Report: 17 страниц про семейство открытых мультимодальных моделей 2.3B-31B, MoE-вариант 26B-A4B, thinking mode, длинный контекст и раздел Responsibility, Safety, Security.

Это самый плотный публичный техдок по Gemma 4: https://arxiv.org/abs/2607.02770

🌚 @poxek_ai / Чат канала

ACS: агентам нужен контроль, а не запрет на применение

Agent Control Standard (ACS) пытается закрыть дыру, которая появляется сразу после перехода от чатботов к агентам. Агент не только отвечает текстом: он выбирает инструменты, вызывает API, пишет в память, запускает код, передает задачу субагенту и может затронуть продакшен. Для всего этого системный промпт слишком никакущий механизм контроля и прости хосподи защиты.

♾️Идея♾️
Платформа агента должна отдавать стандартизированные точки перехвата на ключевых шагах выполнения. На входе, выходе, вызове инструмента, ответе инструмента, смене этапа планирования, операции с памятью или запуске кода срабатывает hook. Внешний слой контроля, который в ACS называется Guardian Agent, проверяет действие по политике и возвращает решение: разрешить, запретить или изменить.

Смысл обсуждаемого стандарта не в наборе рекомендаций по "безопасному ЫЫ", а в переносимости контроля. Если политики описаны декларативно и исполняются через общий интерфейс, их не нужно заново размазывать по каждому фреймворку, MCP-серверу или внутреннему агенту. Для команды безопасности это ближе влажным мечтам: действие ИИ агента не просто логгируется постфактум, а может быть остановлено до изменения состояния.

♾️Наблюдаемость♾️
ACS также цепляет наблюдаемость: трассировка через OpenTelemetry, маппинг событий в OCSF и динамическая ведомость состава агента (AgBOM) для инвентаризации моделей, инструментов, знаний и зависимостей. Это важно, потому что без понимания что у тебя в контуре и трассировки действий агентов невозможно нормально расследовать, почему агент вообще получил право на конкретный вызов.

Ограничение: это пока ранняя спецификация, а не кнопка "сделай агентов безопасными" (такого не бывает). Но направление правильное)

🐱 GitHub ACS
🔗 OWASP Agent Observability Standard (AOS)

🌚 @poxek_ai / Чат канала

#meme

🌚 @poxek_ai / Чат канала

#meme

🌚 @poxek_ai / Чат канала