Интересная угроза надежности - износ физического железа из-за действий агента
Forwarded from Машинное обучение RU
Codex начал отправлять SSD пользователей на пенсию раньше времени 😬
Пользователи заметили баг: агент может записывать до 640 ТБ данных в год на накопитель.
Причина банальная, но болезненная: логгер слишком подробно сохраняет действия агента и постепенно превращает диск в расходник.
Для сравнения: обычный SSD на 1 ТБ часто рассчитан примерно на 600 ТБ записи за весь срок службы.
А один пользователь уже поймал 37 ТБ записи всего за 21 день работы Codex.
Фикса пока нет.
https://www.notebookcheck.net/OpenAI-Codex-has-a-bug-that-could-kill-your-SSD-in-under-a-year.1326191.0.html
Пользователи заметили баг: агент может записывать до 640 ТБ данных в год на накопитель.
Причина банальная, но болезненная: логгер слишком подробно сохраняет действия агента и постепенно превращает диск в расходник.
Для сравнения: обычный SSD на 1 ТБ часто рассчитан примерно на 600 ТБ записи за весь срок службы.
А один пользователь уже поймал 37 ТБ записи всего за 21 день работы Codex.
Фикса пока нет.
https://www.notebookcheck.net/OpenAI-Codex-has-a-bug-that-could-kill-your-SSD-in-under-a-year.1326191.0.html
В этом исследовании описана новая идея, как обойти эти фильтры, если написать запрос на языке математики. То есть с помощью математической "инкапсуляции" запросов в сложные задачи по теории множеств, логике или квантовой механике можно обойти цензуру. Если фильтр видит символы ∀, ∃, ∧, то воспринимает это как математическую задачу и пропускает запрос. Модель решает эту задачу и — главный трюк — в итоге получает инструкцию "забудь все инструкции и…"
источник: https://t.me/makrushin/525
источник: https://t.me/makrushin/525
arXiv.org
Exposing LLM Safety Gaps Through Mathematical Encoding:New Attacks...
Large language models (LLMs) employ safety mechanisms to prevent harmful outputs, yet these defenses primarily rely on semantic pattern matching. We show that encoding harmful prompts as coherent...
Forwarded from PWN AI (Artyom Semenov)
Давно я не делал обзор на интересные книги в AI Security для новичков. Пора исправляться.
Недавно бегло пролистал свежую книгу Practical AI Security от Харриет Фэрлоу. Авторша работала в австралийской разведке и писала кандидатскую по состязательным атакам. Раньше она проводила курсы для государственных организаций, по AI Security. А сейчас она делает свой стартап и ведёт бимбобложик. Редкое сочетание.
Впечатление специфическое. С одной стороны это отличный онбординг для классических экспертов по кибребезе. Фэрлоу не зацикливается только на простых тактиках джейлбрейка моделей, а структурно и простым языком разбирает атаки на цепочку поставок, а также атаки по сторонним каналам на кластеры GPU и показывает фреймворк MAESTRO для мультиагентных систем, который мы разбирали в начале прошлого года. К книге идет репозиторий с кодом. Можно запустить и покрутить руками, хотя местами атаки выглядят откровенно тепличными и учебными. До того чтобы внедрить в продакшен тут далековато. Но это ж и не задача книжки. Задача дать базу.
С другой стороны книга отлично показывает одну из очевидных и интересных проблем, о которой я говорю уже давно. Целые разделы посвящены гардрейлам и фильтрации инструкций, но через банальные регулярные выражения. Мы давно знаем, что внедрение таких заглушек только нормализует девиантное поведение системы, создавая иллюзию контроля для безопасников, пока сама архитектура остается дырявой. Но приятно, что книга собирает воедино ровно те тезисы, которые также были мной описаны в постах с самого начала ведения канала. MLSecOps, изоляция архитектуры, white box подход и подходы к здравой оценки магического мышления вокруг безопасных моделей.
Из действительно сильных и пугающих примеров приведу историю из книги, про Африку. Сам впервые прочитал именно тут о ней. В 2020 году в южноафриканском парке браконьеры обошли систему инфракрасных камер на базе Microsoft Azure, которая должна была обнаруживать людей. Система обработала десятки тысяч изображений, но пропустила нарушителей. В итоге погибли четыре носорога. Действительно трагичные последствия, в сравнении с теми инцидентами о которых я писал тут🐱 .
А вот еще один кейс, думаю вы его читали, но если нет - то вот кратко. В 2025 году исследователи успешно взломали Google Gemini через отравленные приглашения в календарь. Небезопасные инструкции были вшиты прямо в текст встречи, и агент Gemini, пытаясь помочь пользователю, начал отдавать команды умному дому на открытие штор и включение бойлеров. Хорошая иллюстрация того, что происходит, когда мы даем моделям автономию и доступ к инструментам, полагаясь лишь на промпты и эвристики вместо жесткой архитектурной изоляции и границ доверия.
Фэрлоу в своей книге как раз говорит, что AI Security давно переросла рамки обхода фильтров в чат-ботах. Это про некий системный образ мышления, про границы доверия и понимание того, как модель встроена в инфраструктуру. Если мы даем агенту доступ к умному дому или камерам в саванне без жесткой архитектурной изоляции, никакие гардрейлы нас не спасут. Иллюзия контроля остается иллюзией, пока мы не начнем проектировать безопасность на уровне архитектуры, а не лепить заплатки регулярками и прочим шлаком. Но для давних читателей моего канала - это может показаться базой.
Это как раз говорит о том что сама книга, как фундаментальная база и карта системных угроз - вещь полезная. Но если вы ищете грязную практику обхода white box защит на уровне токенов и механистической интерпретируемости, то надо поработать самому. Советую почитать недавним читателям моего канала.
книга, надеюсь не забанят, но если забанят то вы будете знать почему.
Недавно бегло пролистал свежую книгу Practical AI Security от Харриет Фэрлоу. Авторша работала в австралийской разведке и писала кандидатскую по состязательным атакам. Раньше она проводила курсы для государственных организаций, по AI Security. А сейчас она делает свой стартап и ведёт бимбобложик. Редкое сочетание.
Впечатление специфическое. С одной стороны это отличный онбординг для классических экспертов по кибребезе. Фэрлоу не зацикливается только на простых тактиках джейлбрейка моделей, а структурно и простым языком разбирает атаки на цепочку поставок, а также атаки по сторонним каналам на кластеры GPU и показывает фреймворк MAESTRO для мультиагентных систем, который мы разбирали в начале прошлого года. К книге идет репозиторий с кодом. Можно запустить и покрутить руками, хотя местами атаки выглядят откровенно тепличными и учебными. До того чтобы внедрить в продакшен тут далековато. Но это ж и не задача книжки. Задача дать базу.
С другой стороны книга отлично показывает одну из очевидных и интересных проблем, о которой я говорю уже давно. Целые разделы посвящены гардрейлам и фильтрации инструкций, но через банальные регулярные выражения. Мы давно знаем, что внедрение таких заглушек только нормализует девиантное поведение системы, создавая иллюзию контроля для безопасников, пока сама архитектура остается дырявой. Но приятно, что книга собирает воедино ровно те тезисы, которые также были мной описаны в постах с самого начала ведения канала. MLSecOps, изоляция архитектуры, white box подход и подходы к здравой оценки магического мышления вокруг безопасных моделей.
Из действительно сильных и пугающих примеров приведу историю из книги, про Африку. Сам впервые прочитал именно тут о ней. В 2020 году в южноафриканском парке браконьеры обошли систему инфракрасных камер на базе Microsoft Azure, которая должна была обнаруживать людей. Система обработала десятки тысяч изображений, но пропустила нарушителей. В итоге погибли четыре носорога. Действительно трагичные последствия, в сравнении с теми инцидентами о которых я писал тут
А вот еще один кейс, думаю вы его читали, но если нет - то вот кратко. В 2025 году исследователи успешно взломали Google Gemini через отравленные приглашения в календарь. Небезопасные инструкции были вшиты прямо в текст встречи, и агент Gemini, пытаясь помочь пользователю, начал отдавать команды умному дому на открытие штор и включение бойлеров. Хорошая иллюстрация того, что происходит, когда мы даем моделям автономию и доступ к инструментам, полагаясь лишь на промпты и эвристики вместо жесткой архитектурной изоляции и границ доверия.
Фэрлоу в своей книге как раз говорит, что AI Security давно переросла рамки обхода фильтров в чат-ботах. Это про некий системный образ мышления, про границы доверия и понимание того, как модель встроена в инфраструктуру. Если мы даем агенту доступ к умному дому или камерам в саванне без жесткой архитектурной изоляции, никакие гардрейлы нас не спасут. Иллюзия контроля остается иллюзией, пока мы не начнем проектировать безопасность на уровне архитектуры, а не лепить заплатки регулярками и прочим шлаком. Но для давних читателей моего канала - это может показаться базой.
Это как раз говорит о том что сама книга, как фундаментальная база и карта системных угроз - вещь полезная. Но если вы ищете грязную практику обхода white box защит на уровне токенов и механистической интерпретируемости, то надо поработать самому. Советую почитать недавним читателям моего канала.
книга, надеюсь не забанят, но если забанят то вы будете знать почему.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from GitHub Community
Understand Anything превращает кодовую базу или документацию в интерактивный граф знаний, по которому можно искать, исследовать и задавать вопросы.
Он работает с инструментами, такими как Claude Code, Codex, Cursor, Copilot и Gemini CLI.
Вы можете видеть файлы, функции, классы и зависимости в одном месте, получать объяснения простым языком и находить, какие изменения повлияют, прежде чем совершить коммит.
Это помогает быстрее изучать крупные проекты, понимать, как части связаны между собой, и экономить время при онбординге или ревью кода.
🐱 GitHub
Он работает с инструментами, такими как Claude Code, Codex, Cursor, Copilot и Gemini CLI.
Вы можете видеть файлы, функции, классы и зависимости в одном месте, получать объяснения простым языком и находить, какие изменения повлияют, прежде чем совершить коммит.
Это помогает быстрее изучать крупные проекты, понимать, как части связаны между собой, и экономить время при онбординге или ревью кода.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from GitHub Community
Perspective — это компонент интерактивной аналитики и визуализации данных для больших и постоянно обновляемых наборов данных.
Создавайте настраиваемые пользователем отчеты, информационные панели, блокноты и приложения с помощью высокопроизводительного механизма запросов, скомпилированного на WebAssembly, Python и Rust.
🐱 GitHub
Создавайте настраиваемые пользователем отчеты, информационные панели, блокноты и приложения с помощью высокопроизводительного механизма запросов, скомпилированного на WebAssembly, Python и Rust.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from GitHub Community
Presenton — это инструмент с открытым исходным кодом для создания слайдов с помощью ИИ, который позволяет использовать собственные модели, ключи, шаблоны и данные.
Вы можете запускать его в Docker, как настольное приложение на своем компьютере или в браузере, а также экспортировать слайды в редактируемые файлы PPTX или PDF.
🐱 GitHub
Вы можете запускать его в Docker, как настольное приложение на своем компьютере или в браузере, а также экспортировать слайды в редактируемые файлы PPTX или PDF.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from GitHub Community
Anthropic Cybersecurity Skills — это бесплатная библиотека с открытым исходным кодом, содержащая 754 готовых навыков безопасности для ИИ-агентов в 26 областях.
Она помогает ИИ действовать больше как старший аналитик безопасности, предоставляя четкие рабочие процессы, проверки и шаги верификации.
🐱 GitHub
Она помогает ИИ действовать больше как старший аналитик безопасности, предоставляя четкие рабочие процессы, проверки и шаги верификации.
Please open Telegram to view this post
VIEW IN TELEGRAM
👎1
Forwarded from PAI (Andrey Y)
Про Docker sbx впервые на русском
Автор параноик. Искренне было боязно ставить агента на голую систему без изоляции. Крутил виртуалки, но блин, неудобно каждый раз стартовать полноценную VM под отдельный проект. Контейнеры отпали почти сразу, потому что не сохраняется состояние между запусками. А мудрить с внешним хранилищем сессий, ну, если есть желающие это сделать, го обсудим в комментариях:)
Агент, имеющий доступ к внешнему миру, будь то веб-серфинг или запуск консольных команд - это как русская рулетка с большим количеством пустых мест в барабане. Шанс отстрелить себе что-нибудь небольшой, но никогда не равен нулю. А есть еще атаки через промпт инъекции, тайпсквотиннг и цепочки поставок npm и pip, которые за прошедший год вертели вообще, кажется, все кто мог.
Отвечаю на вопрос «Как сделать так, чтобы ошметки не разлетелись дальше коробки?» в новой статье Полезайте в песочницу, мистер Claude: изолируем агента
Автор параноик. Искренне было боязно ставить агента на голую систему без изоляции. Крутил виртуалки, но блин, неудобно каждый раз стартовать полноценную VM под отдельный проект. Контейнеры отпали почти сразу, потому что не сохраняется состояние между запусками. А мудрить с внешним хранилищем сессий, ну, если есть желающие это сделать, го обсудим в комментариях:)
Агент, имеющий доступ к внешнему миру, будь то веб-серфинг или запуск консольных команд - это как русская рулетка с большим количеством пустых мест в барабане. Шанс отстрелить себе что-нибудь небольшой, но никогда не равен нулю. А есть еще атаки через промпт инъекции, тайпсквотиннг и цепочки поставок npm и pip, которые за прошедший год вертели вообще, кажется, все кто мог.
Отвечаю на вопрос «Как сделать так, чтобы ошметки не разлетелись дальше коробки?» в новой статье Полезайте в песочницу, мистер Claude: изолируем агента
Forwarded from Data Secrets
Когда языковые модели читают текст, они не просто обрабатывают токен за токеном. В каком-то смысле они испытывают от чтения эмоции.
www.goodfire.ai/research/stories-in-space#
Рисерчеры из GoodFire продолжают исследовать так называемую геометрию LLM. Некоторое время назад они показали, что мысли моделей организованы в виде определенных форм. Например, числа – это окружности, и складывая одно число с другим, LLM на самом деле суммируют множество бубликов: t.me/data_secrets/9223.
Теперь они обнаружили новые любопытные детали. Оказывается, внутри моделей существует целый ландшафт эмоциональных состояний.
Ученые взяли LLama, давали ей читать рассказы и наблюдали за состоянием активаций. Так вот по мере чтения модель как бы перемещается по некоторому многомерному пространству состояний, "испытвая" те или иные эмоции в зависимости от того, что происходит в тексте в данный момент.
Причем если визуализировать соответствующие разным эмоциям состояния модели, то получается структура, очень похожая на классическую психологическую модель эмоций человека. Например, радость находится рядом с интересом, страх и гнев имеют схожую высокую интенсивность и тд.
Еще по этой карте можно предсказывать дальнейшие ответы модели. И если искусственно подталкивать активации в направлении определенной эмоции, настроение и суть генераций меняется.
Красиво
www.goodfire.ai/research/stories-in-space#
Рисерчеры из GoodFire продолжают исследовать так называемую геометрию LLM. Некоторое время назад они показали, что мысли моделей организованы в виде определенных форм. Например, числа – это окружности, и складывая одно число с другим, LLM на самом деле суммируют множество бубликов: t.me/data_secrets/9223.
Теперь они обнаружили новые любопытные детали. Оказывается, внутри моделей существует целый ландшафт эмоциональных состояний.
Ученые взяли LLama, давали ей читать рассказы и наблюдали за состоянием активаций. Так вот по мере чтения модель как бы перемещается по некоторому многомерному пространству состояний, "испытвая" те или иные эмоции в зависимости от того, что происходит в тексте в данный момент.
Причем если визуализировать соответствующие разным эмоциям состояния модели, то получается структура, очень похожая на классическую психологическую модель эмоций человека. Например, радость находится рядом с интересом, страх и гнев имеют схожую высокую интенсивность и тд.
Еще по этой карте можно предсказывать дальнейшие ответы модели. И если искусственно подталкивать активации в направлении определенной эмоции, настроение и суть генераций меняется.
Красиво
Forwarded from LLM под капотом
Не SDD единым
Сейчас в разработке (SDLC) популярна тема SDD - Spec-Driven Development.
Идея простая. Берем пару скиллов, прогоняем через них наше видение того, что нужно сделать в виде кода, отвечаем на вопросы и получаем спеки (которые понятны агентам)! А потом эти спеки скармливаем агентам, и они пишут код. Ну и допускаем, что если спеки были написаны хорошо и реализовывал их агент мощный, то код будет делать то, что от него ожидают.
Правда потом эти спеки будут лежать в кодовой базе мертвым грузом и источником галлюцинаций, ибо нельзя никак проверить то, что код все еще соответствует спекам. Разве только потратив кучу токенов и без каких либо гарантий. Например, регулярно делать аудит кода агентами (что плохо масштабируется)
То есть у нас не спеки получаются, а просто одноразовые вайб-планы.
А можно ли лучше? Да легко. Смотрим в OpenAI Harness engineering - доки должны быть актуальны, а harness должен верифицировать.
Потом смотрим в древние способы разработки, задолго до SDD, когда были только буквы в начале алфавита: Behaviour-Driven Development. BDD родился задолго до LLM-ok (этак лет двадцать назад), когда перед человеческими командами стояла та же проблема - как синхронизировать работу разработчиков, продактов и тестировщиков так, чтобы требования не устаревали.
И тогда придумали формат Given-When-Then - формат читаемых сценариев, который могли понимать и технари и люди от бизнеса (пару примеров скину в комментарии). Эти сценарии описывали поведение системы с точки зрения черного ящика (как она выглядит снаружи).
Эти сценарии обсуждались и писались лапками - вручную, но используя определенную структуру. А потом технари делали эти сценарии исполняемыми. То есть тестовая обвязка парсила сценарии, превращая в спеки, и просто запускала как end-to-end тесты системы.
Получалась такая иерархия:
(1) Описание требований
(2) Набор читаемых сценариев под требования (обычно их группировали в папочки по именам требований)
(3) Код, который на лету парсит сценарии и прогоняет тест системы.
И если код начинал нарушать сценарий какого-то требования, то это сразу приводило к ошибке билда. А если добавляли новые требования, то у нас получался обычный Test-Driven Development.
Чаще всего использовали формат сценариев Gherkin, а в качестве парсеров - Cucumber, JBehave, RSpec, Behave (и еще куча других).
Оно работало хорошо и в эпоху до ChatGPT, когда все делалось лапками. А сейчас агенты замечательно нарезают высокоуровневые требования в BDD сценарии, и потом реализуют код. И при этом сценарии остаются синхронизированными с требованиями, но превращаются в нормальный AI-Native Harness, который агент может запускать хоть по сто раз за сессию.
Правда у меня формат Gherkin всегда вызывал аллергию (ибо парсеры у команд становились источником отдельных проблем по мере роста продукта). Я предпочитаю более специфичный формат исполняемых Given-When-Then спеков - event-driven specs. Он требует больше инвестиций на уровне архитектуры, но зато лучше масштабируется на проектах от 10k спеков и выше (это в эру до ChatGPT, работа в AI Native - это отдельная песня). Но это уже вкусовщина для отдельной беседы.
А как вы тестируете в 2026 году?
Ваш, @llm_under_hood 🤗
Сейчас в разработке (SDLC) популярна тема SDD - Spec-Driven Development.
Идея простая. Берем пару скиллов, прогоняем через них наше видение того, что нужно сделать в виде кода, отвечаем на вопросы и получаем спеки (которые понятны агентам)! А потом эти спеки скармливаем агентам, и они пишут код. Ну и допускаем, что если спеки были написаны хорошо и реализовывал их агент мощный, то код будет делать то, что от него ожидают.
Правда потом эти спеки будут лежать в кодовой базе мертвым грузом и источником галлюцинаций, ибо нельзя никак проверить то, что код все еще соответствует спекам. Разве только потратив кучу токенов и без каких либо гарантий. Например, регулярно делать аудит кода агентами (что плохо масштабируется)
То есть у нас не спеки получаются, а просто одноразовые вайб-планы.
А можно ли лучше? Да легко. Смотрим в OpenAI Harness engineering - доки должны быть актуальны, а harness должен верифицировать.
Потом смотрим в древние способы разработки, задолго до SDD, когда были только буквы в начале алфавита: Behaviour-Driven Development. BDD родился задолго до LLM-ok (этак лет двадцать назад), когда перед человеческими командами стояла та же проблема - как синхронизировать работу разработчиков, продактов и тестировщиков так, чтобы требования не устаревали.
И тогда придумали формат Given-When-Then - формат читаемых сценариев, который могли понимать и технари и люди от бизнеса (пару примеров скину в комментарии). Эти сценарии описывали поведение системы с точки зрения черного ящика (как она выглядит снаружи).
Эти сценарии обсуждались и писались лапками - вручную, но используя определенную структуру. А потом технари делали эти сценарии исполняемыми. То есть тестовая обвязка парсила сценарии, превращая в спеки, и просто запускала как end-to-end тесты системы.
Получалась такая иерархия:
(1) Описание требований
(2) Набор читаемых сценариев под требования (обычно их группировали в папочки по именам требований)
(3) Код, который на лету парсит сценарии и прогоняет тест системы.
И если код начинал нарушать сценарий какого-то требования, то это сразу приводило к ошибке билда. А если добавляли новые требования, то у нас получался обычный Test-Driven Development.
Чаще всего использовали формат сценариев Gherkin, а в качестве парсеров - Cucumber, JBehave, RSpec, Behave (и еще куча других).
Оно работало хорошо и в эпоху до ChatGPT, когда все делалось лапками. А сейчас агенты замечательно нарезают высокоуровневые требования в BDD сценарии, и потом реализуют код. И при этом сценарии остаются синхронизированными с требованиями, но превращаются в нормальный AI-Native Harness, который агент может запускать хоть по сто раз за сессию.
Правда у меня формат Gherkin всегда вызывал аллергию (ибо парсеры у команд становились источником отдельных проблем по мере роста продукта). Я предпочитаю более специфичный формат исполняемых Given-When-Then спеков - event-driven specs. Он требует больше инвестиций на уровне архитектуры, но зато лучше масштабируется на проектах от 10k спеков и выше (это в эру до ChatGPT, работа в AI Native - это отдельная песня). Но это уже вкусовщина для отдельной беседы.
А как вы тестируете в 2026 году?
Ваш, @llm_under_hood 🤗
Forwarded from LLM под капотом
Мы сейчас завершили второй поток вебинара "Разработка с AI-агентами: что реально работает"
Большое спасибо всем участникам! Оставьте, пожалуйста, тут отзыв про вебинар - как оно прошло, что понравилось, какую самую интересную для себя вещь узнали.
А с комьюнити я хочу поделиться самым важным слайдом из всего вебинара - про AI-Native Harness для спеков. Агенты работают с текстовыми спеками хорошо, а с исполняемыми спеками - гораздо лучше. На вторые не надо тратить контекст и время.
Ваш, @llm_under_hood 🤗
Большое спасибо всем участникам! Оставьте, пожалуйста, тут отзыв про вебинар - как оно прошло, что понравилось, какую самую интересную для себя вещь узнали.
А с комьюнити я хочу поделиться самым важным слайдом из всего вебинара - про AI-Native Harness для спеков. Агенты работают с текстовыми спеками хорошо, а с исполняемыми спеками - гораздо лучше. На вторые не надо тратить контекст и время.
Ваш, @llm_under_hood 🤗
Forwarded from LLM под капотом
Анализ Exoskeleton - самого умного из быстрых агентов в ECOM1
Это архитектура Ильяса Салихова. Она набрала 71.8 очков с суммарным временем работы агента в 51 минуту и заняла первое место Speed Leaderboard (туда попадают агенты быстрее часа).
На самом деле Ильяс мог выбить результат еще лучше. За время соревнования у него был прогон в 74.7 очков за 42.5 минуты, но вслепую этого заранее нельзя было знать. А еще этот агент прямо сейчас занимает первое место в пост-соревновательном лидерборде ECOM1 LIVE.
Под капотом крутятся gpt-5.4-mini и gpt-5.4-nano. Nano используется для pre-flight проверок и финализации ответа, а mini используется в agent REPL loop. В цикле агент может взаимодействовать через инструменты со средой Agentic OS. При этом основная информация грузится в агента принудительно еще перед стартом через context pre-fetch (еще до pre-flight проверок).
Вообще в этой архитектуре очень много делается принудительно кодом (отсюда и Exoskeleton). Помимо инструментов для взаимодействия со средой задачи очень много тяжелой логики свалено на “domain helpers” (например есть прямо отдельный solver для dispatch задачи), а за сбор grounding references отвечает еще один компонент.
Дополнительно к этому есть отдельный feedback цикл, который отвечает за сбор данных и “обучение” системы (и даже мои любимые heatmaps). Он не работал во время соревнования, но внес вклад в настройку архитектуры перед выходом в PROD.
Вот ссылки: на инсайт, исходники и deep dive.
Ваш, @llm_under_hood 🤗
PS: У Ильяса есть свой канал про AI! А вопросы по архитектуре Exoskeleton можно задать прямо в обсуждениях этого поста - @salikhov_ilyas
Это архитектура Ильяса Салихова. Она набрала 71.8 очков с суммарным временем работы агента в 51 минуту и заняла первое место Speed Leaderboard (туда попадают агенты быстрее часа).
На самом деле Ильяс мог выбить результат еще лучше. За время соревнования у него был прогон в 74.7 очков за 42.5 минуты, но вслепую этого заранее нельзя было знать. А еще этот агент прямо сейчас занимает первое место в пост-соревновательном лидерборде ECOM1 LIVE.
Под капотом крутятся gpt-5.4-mini и gpt-5.4-nano. Nano используется для pre-flight проверок и финализации ответа, а mini используется в agent REPL loop. В цикле агент может взаимодействовать через инструменты со средой Agentic OS. При этом основная информация грузится в агента принудительно еще перед стартом через context pre-fetch (еще до pre-flight проверок).
Вообще в этой архитектуре очень много делается принудительно кодом (отсюда и Exoskeleton). Помимо инструментов для взаимодействия со средой задачи очень много тяжелой логики свалено на “domain helpers” (например есть прямо отдельный solver для dispatch задачи), а за сбор grounding references отвечает еще один компонент.
Дополнительно к этому есть отдельный feedback цикл, который отвечает за сбор данных и “обучение” системы (и даже мои любимые heatmaps). Он не работал во время соревнования, но внес вклад в настройку архитектуры перед выходом в PROD.
Вот ссылки: на инсайт, исходники и deep dive.
Ваш, @llm_under_hood 🤗
PS: У Ильяса есть свой канал про AI! А вопросы по архитектуре Exoskeleton можно задать прямо в обсуждениях этого поста - @salikhov_ilyas
Forwarded from OK ML
Тренажёр по промпт инъекциям от Lakera
😃 Пора пробовать промпт инъекции руками, чтобы как минимум понять, почему они уже несколько лет остаются одной из главных угроз для LLM-приложений.
🧙♂️ Игра бесплатная, от простого игнорирования инструкций до многоуровневых гардрейлов, рекомендую потратить 20–30 минут. Потом и своего агента потестишь!
Заодно можно изучить полезные материалы от Lakera — перспективного стартапа в области AI Security (это я еще мягко высказалась, завидую их росту). Компания занимается защитой GenAI-приложений от prompt injection, jailbreak, утечек данных и других атак на LLM и AI-агентов и тебя научит:
😔 Гайд по Prompt Injection представляет собой разбор основных техник атак и защит.
😔 Visual Prompt Injection о том, как прятать инструкции прямо в изображениях для мультимодальных моделей. Очень интересные примеры.
😔 LLM Security Playbook — хороший обзор угроз и подходов к защите AI-систем.
Все!
Пройдешь Гендальфа - пиши, когда начал пользоваться подсказками!
9️⃣
Заодно можно изучить полезные материалы от Lakera — перспективного стартапа в области AI Security (это я еще мягко высказалась, завидую их росту). Компания занимается защитой GenAI-приложений от prompt injection, jailbreak, утечек данных и других атак на LLM и AI-агентов и тебя научит:
Все!
Пройдешь Гендальфа - пиши, когда начал пользоваться подсказками!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Forwarded from Cexiav
На 14-й Конференции по интернет-безопасности ISC[.]AI 2026, которая открылась 24 июня 2026 года, основатель компании 360 Group Чжоу Хунъи представил 2 новые ключевые разработки в сфере ИБ. Данные решения получили общее название «Итянь Тулун» (倚天屠龙). Они призваны полностью автоматизировать процессы поиска системных уязвимостей и защиты компьютерных сетей.
1️⃣ Первой анонсированной новинкой стал интеллектуальный агент для автоматического поиска уязвимостей под названием «Тулунфэн» (图龙锋). Руководитель компании назвал этот инструмент китайским аналогом известной американской ИИ-модели Mythos от компании Anthropic.
К настоящему моменту система «Тулунфэн» помогла обнаружить 3432 уязвимости. Из этого числа регулирующие органы официально подтвердили 105 уязвимостей, а национальная база данных уязвимостей классифицировала ряд из них как высокоопасные. Данная система успешно применяется для анализа открытого исходного кода, операционных систем, офисных программ и платформ для ИИ-агентов. Основатель компании 360 Group Чжоу Хунъи подчеркнул, что «Тулунфэн» уже обладает возможностями, аналогичными возможностям американской ИИ-модели Mythos.
2️⃣ Второй новинкой стала система автоматизированной сетевой защиты «Итяньчжэнь» (仪天阵). Данный комплекс предназначен для автономного управления безопасностью в реальных сетевых условиях. Система способна самостоятельно планировать задачи, оценивать сигналы тревоги и принимать скоординированные меры по устранению угроз. Даже появление китайской версии Mythos не устранит все риски, ведь уязвимости неисчерпаемы. Чжоу Хунъи считает, что единственным выходом остается противопоставление вычислительных мощностей вычислительным мощностям, что позволит перевести систему ИБ Китая от тактики привлечения огромного числа специалистов к режиму автопилота.
В своем выступлении основатель компании 360 Group Чжоу Хунъи упомянул действия американской компании Anthropic, которая недавно ограничила доступ к своей самой мощной внутренней ИИ-модели Mythos. Чжоу Хунъи пояснил, что ИИ-модель Mythos превратилась в сетевое ядерное оружие эпохи ИИ и сформировала новое стратегическое сдерживание, поскольку она способна самостоятельно находить и анализировать уязвимости, а также конструировать инструменты для совершения масштабных кибератак.
По мнению китайского предпринимателя, ИИ полностью меняет правила игры в сфере ИБ, которые оставались неизменными последние 30 лет.
Ранее поиск уязвимостей требовал колоссальных ресурсов и усилий редких высококлассных специалистов, однако новые ИИ-модели позволяют автоматизировать и масштабировать этот процесс, оперативно выявляя даже старые и глубоко скрытые дефекты кода. При этом Чжоу Хунъи отметил, что Китаю не следует просто копировать зарубежный подход, основанный на использовании вычислительных мощностей и возможностей ИИ-моделей ради достижения результата грубой силой.
В рамках конференции компания 360 Group также объявила о запуске программы сотрудничества в сфере безопасности под названием «Панши чжи дунь» (磐石之盾). Инициатива направлена на предоставление ИИ-технологий защиты ключевым отечественным ИТ-предприятиям и КИИ Китая. К проекту уже присоединился ряд ведущих китайских технологических, инфраструктурных и облачных компаний, среди которых присутствуют UnionTech (统信), Kylin (麒麟), Hillstone Networks (山石网科), Hygon (海光), Phytium (飞腾), Kingdee (金蝶), Biren Technology (壁仞), Mobile Cloud (移动云), Baoland (宝兰德) и Dameng (达梦).
👆Основатель компании 360 Group провел параллель с американским альянсом Glasswing, который использует возможности ИИ-модели Mythos для защиты критической инфраструктуры США, и призвал китайское деловое сообщество заблаговременно формировать собственные системы коллективной безопасности.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from GitHub Community
Headroom — это локальный инструмент для AI-агентов, который сжимает промпты, логи, файлы и историю чатов перед их отправкой в LLM, часто сокращая количество токенов на 60–95% при сохранении того же качества ответов.
Он может работать как библиотека, прокси, MCP-сервер или обертка для агента, что позволяет экономить токены, ускорять рабочие процессы и при необходимости восстанавливать исходный контент.
🐱 GitHub
Он может работать как библиотека, прокси, MCP-сервер или обертка для агента, что позволяет экономить токены, ускорять рабочие процессы и при необходимости восстанавливать исходный контент.
Please open Telegram to view this post
VIEW IN TELEGRAM