Forwarded from AlexRedSec
А вот еще один фреймворк оценки зрелости AI SIEM/SOC➕
ARMM (AI Response Maturity Model) — фреймворк, призванный оценить насколько эффективно "ядро" ИИ в AI SOC позволяет выполнять функции автоматического реагирования на угрозы.
Всего оценивается чуть более 80 функций в 6 доменах (Identity, Network, Endpoint, Cloud, SaaS, General Options), а направлений оценки два:
🔗 Режим оценщика (Evaluator) — подходит для прямого сравнения продуктов "из коробки" с рынка, условно отвечая на вопрос, какой вендор дает больше возможностей за свои деньги.
Каждая функция оценивается с точки зрения автоматизации (от полного отсутствия функции до полной автоматизации), при этом детально расписан уровень автоматизации с участием человека.
🔗 Режим архитектора (Builder) — более технический уровень, здесь уже оценивается зрелость функционала, учитывая контекст (организации, команды SecOps, присущих рисков).
Здесь оценка ведется по трем направлениям — точность принятия решений и доверие к ним, сложность внедрения и сопровождения, а также операционное влияние и "радиус поражения" (последствия при ошибочном действии).
Методология оценки в фреймворке ARMM расписана очень подробно, а еще есть удобный онлайн-калькулятор с дашбордами оценки зрелости и возможностью выгрузки результатов в csv-формате.
#framework #maturity #soc #siem #ai
ARMM (AI Response Maturity Model) — фреймворк, призванный оценить насколько эффективно "ядро" ИИ в AI SOC позволяет выполнять функции автоматического реагирования на угрозы.
Всего оценивается чуть более 80 функций в 6 доменах (Identity, Network, Endpoint, Cloud, SaaS, General Options), а направлений оценки два:
Каждая функция оценивается с точки зрения автоматизации (от полного отсутствия функции до полной автоматизации), при этом детально расписан уровень автоматизации с участием человека.
Здесь оценка ведется по трем направлениям — точность принятия решений и доверие к ним, сложность внедрения и сопровождения, а также операционное влияние и "радиус поражения" (последствия при ошибочном действии).
Методология оценки в фреймворке ARMM расписана очень подробно, а еще есть удобный онлайн-калькулятор с дашбордами оценки зрелости и возможностью выгрузки результатов в csv-формате.
#framework #maturity #soc #siem #ai
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Пост Лукацкого
AWS Threat Intelligence зафиксировала кампанию, в которой некий финансово мотивированный злоумышленник использовал коммерческие LLM-сервисы (вероятно DeepSeek и Claude) для проведения массовой атаки на устройства FortiGate по всему миру – пострадало более 600 устройств в 55+ странах с января по февраль 2026 г.
Zero Day не использовались – в атаках использовались открытые интерфейсы управления и слабые/повторно использованные пароли без многофакторной аутентификации. ИИ же использовался как мультипликатор – коммерческие LLM-сервисы применялись на каждом этапе – от генерации планов атаки и написания скриптов до анализа конфигураций и автоматизации процессов: созданные скрипты сканировали стандартные порты управления (443, 8443 и др.), а затем реализовывали попытки входа с использованием списка распространенных паролей.
Выкаченные полные конфигурации FortiGate позволяли получить учетки VPN, включая пароли, административные креды, сетевые топологии, правила межсетевого экрана и IPsec-конфиги. На основе этих данных собиралась полная карта сети, после чего злоумышленник проникал внутрь корпоративной сети. После доступа происходила компрометация Active Directory, добывались NTLM-хэши, расширялся плацдарм с помощью Pass-the-Hash, Pass-the-Ticket и т.п. и были попытки атаковать инфраструктуру резервного копирования, что характерно для шифровальщиков.
По мнению Amazon атаки хоть и проводились автоматизированно, но злоумышленник демонстрировал невысокий технический уровень и зависел от ИИ. Там, где были реализованы сильные защитные меры (закрытые порты, MFA и т.п.), атаки не срабатывали – злоумышленник просто переходил к следующим целям, благо их было немало.
Другой исследователь обнаружил открытую директорию на сервере, содержащую полный набор инструментов, данных и отчетов, связанных с активной кампанией по атаке на FortiGate устройства с помощью интеграции LLM в рабочий процесс (видимо, связанные истории с тем, о чем пишет Amazon). Сервер содержал 1400+ файлов, включая:
➡️ конфигурации FortiGate,
➡️ дампы AD,
➡️ код CVE-эксплойтов,
➡️ отчеты сканирования (например Nuclei),
➡️ инструменты извлечения паролей для Veeam и др.
Были обнаружены также каталоги, содержащие выходные данные LLM (Claude Code и DeepSeek) – сессии, кэш, промпты и результаты генерации планов атак. Последние генерил DeepSeek, а Claude анализировал уязвимости, составлял отчеты и даже запускал offensive-инструменты (Impacket, Metasploit, hashcat и др.), используя предварительно заданные настройки, что позволяло модели действовать практически автономно.
Два ключевых модуля сделали систему более сложной: CHECKER2 (Go), выполнявший функции оркестратора для массовой обработки VPN-конфигураций и сканирования, и ARXON (Python MCP — Model Context Protocol), реализующий сервер контекстов, который принимает результаты разведки, вызывает LLM для генерации последующих шагов в рамках атаки, накапливает базу знаний по каждой новой цели, содержит скрипты для вмешательства в инфраструктуру жертвы.
Интересно, что в прежней версии этого атакующего инструмента использовался популярный offensive-фреймворк HexStrike, но позже злоумышленник создал собственные MCP-инструменты (ARXON & CHECKER2) с более глубокой автоматизацией и интеграцией LLM.
Интересная особенность этой кампании в том, что LLM не искали уязвимости, а выступали как аналитический и операционный ассистент, который обрабатывал собираемые разведданные, готовил планы атаки и давал указания атакующим инструментам (этакий виртуальный генштаб). Такая система позволяет одному оператору управлять масштабными операциями с тысячами целей, что отражает общую тенденцию – ИИ снижает порог входа и повышает скорость проведения атак без глубоких технических навыков.
#ии #автоматизация
Zero Day не использовались – в атаках использовались открытые интерфейсы управления и слабые/повторно использованные пароли без многофакторной аутентификации. ИИ же использовался как мультипликатор – коммерческие LLM-сервисы применялись на каждом этапе – от генерации планов атаки и написания скриптов до анализа конфигураций и автоматизации процессов: созданные скрипты сканировали стандартные порты управления (443, 8443 и др.), а затем реализовывали попытки входа с использованием списка распространенных паролей.
Выкаченные полные конфигурации FortiGate позволяли получить учетки VPN, включая пароли, административные креды, сетевые топологии, правила межсетевого экрана и IPsec-конфиги. На основе этих данных собиралась полная карта сети, после чего злоумышленник проникал внутрь корпоративной сети. После доступа происходила компрометация Active Directory, добывались NTLM-хэши, расширялся плацдарм с помощью Pass-the-Hash, Pass-the-Ticket и т.п. и были попытки атаковать инфраструктуру резервного копирования, что характерно для шифровальщиков.
По мнению Amazon атаки хоть и проводились автоматизированно, но злоумышленник демонстрировал невысокий технический уровень и зависел от ИИ. Там, где были реализованы сильные защитные меры (закрытые порты, MFA и т.п.), атаки не срабатывали – злоумышленник просто переходил к следующим целям, благо их было немало.
Другой исследователь обнаружил открытую директорию на сервере, содержащую полный набор инструментов, данных и отчетов, связанных с активной кампанией по атаке на FortiGate устройства с помощью интеграции LLM в рабочий процесс (видимо, связанные истории с тем, о чем пишет Amazon). Сервер содержал 1400+ файлов, включая:
Были обнаружены также каталоги, содержащие выходные данные LLM (Claude Code и DeepSeek) – сессии, кэш, промпты и результаты генерации планов атак. Последние генерил DeepSeek, а Claude анализировал уязвимости, составлял отчеты и даже запускал offensive-инструменты (Impacket, Metasploit, hashcat и др.), используя предварительно заданные настройки, что позволяло модели действовать практически автономно.
Два ключевых модуля сделали систему более сложной: CHECKER2 (Go), выполнявший функции оркестратора для массовой обработки VPN-конфигураций и сканирования, и ARXON (Python MCP — Model Context Protocol), реализующий сервер контекстов, который принимает результаты разведки, вызывает LLM для генерации последующих шагов в рамках атаки, накапливает базу знаний по каждой новой цели, содержит скрипты для вмешательства в инфраструктуру жертвы.
Интересно, что в прежней версии этого атакующего инструмента использовался популярный offensive-фреймворк HexStrike, но позже злоумышленник создал собственные MCP-инструменты (ARXON & CHECKER2) с более глубокой автоматизацией и интеграцией LLM.
Интересная особенность этой кампании в том, что LLM не искали уязвимости, а выступали как аналитический и операционный ассистент, который обрабатывал собираемые разведданные, готовил планы атаки и давал указания атакующим инструментам (этакий виртуальный генштаб). Такая система позволяет одному оператору управлять масштабными операциями с тысячами целей, что отражает общую тенденцию – ИИ снижает порог входа и повышает скорость проведения атак без глубоких технических навыков.
#ии #автоматизация
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Марков цепи пропил
Можно ли построить детерминированную систему на базе LLM
Последние несколько дней аутирую над этой темой, потому что периодически натыкаюсь на эксперименты, где люди пытаются заставить сетку что-нибудь дизассемблировать, перегонять разные форматы данных к одному типу и т.п. Поэтому у меня возник вопрос: насколько подобные проекты применимы в продакшене? Ведь если алгоритм выдает разные результаты на один и тот же набор данных, это может породить непредсказуемое поведение для всей системы. Кажется, будто ответ лежит на поверхности - ставишь temperature=0 и greedy decoding всегда берет один и тот же наиболее вероятный токен. Но на деле это работает не совсем так.
Чтобы понять почему, нужно взять во внимание одно фундаментальное свойство чисел с плавающей точкой - неассоциативность. В математике (a + b) + c = a + (b + c), но когда дело начинает касаться float, на сцену выходит стандарт IEEE 754. Float хранит фиксированное количество значимых цифр, и когда складываете числа с очень разными масштабами, хвост отбрасывается:
Ниже приведу несколько статей, которые отталкиваются от этого свойства, но подсвечивают разные причины и варианты решений:
1) Understanding and Mitigating Numerical Sources of Nondeterminism in LLM Inference [ссылка] - разное железо
Авторы взяли 4 модели - два reasoning-варианта на базе DeepSeek-R1 и два instruct-варианта (Qwen2.5 и Llama-3.1) и прогнали их на 12 разных конфигурациях: два типа GPU (A100 и L40S), разное их количество и разный размер батча. В результате разброс точности на AIME'24 достигал 9%, а длина ответа расходилась до 9000 токенов при одном и том же промпте и greedy decoding.
Здесь важен аппаратный контекст. Исследователи из Манчестерского университета экспериментально проверили [ссылка], как тензорные ядра считают на V100, T4 и A100 - и обнаружили, что поведение отличается в зависимости от микроархитектуры (например V100 выполняет матричное умножение тайлами 4x4x4, A100 - тайлами 8x8x4, т.е. одно и то же произведение разбивается на разное количество шагов с разными промежуточными суммами, и из-за неассоциативности float итог разный). При этом NVIDIA в официальной документации PTX ISA [ссылка] прямо указывает для операций с .f16 и .bf16: "The accumulation order, rounding and handling of subnormal inputs is unspecified".
А так как в LLM инференсе повсеместно используется BF16 (с 7 битами мантиссы), токены с близкими вероятностями могут поменяться местами. В статье приведен пример: в точке расхождения два прогона дают токену "know" вероятности 49.75% и 46.65% и в одном прогоне побеждает "know", в другом "have". Расхождение происходит в среднем на 45-82 токене в зависимости от модели. Для reasoning-моделей это особенно критично, потому что одно неверное слово в начале разворачивается в другую цепочку рассуждений.
Собственно, они предлагают решить эту проблему через LayerCast [GitHub]: веса модели хранятся в BF16, но все вычисления выполняются в FP32 (23 бита мантиссы). Оно не устраняет ключевую проблему, но делает модель более устойчивой. Однако FP32 вычисления медленнее, потому что современные GPU оптимизированы под 16-битные тензорные операции. Хз, насколько именно оно медленнее - авторы статьи не предоставили этих тестов
Последние несколько дней аутирую над этой темой, потому что периодически натыкаюсь на эксперименты, где люди пытаются заставить сетку что-нибудь дизассемблировать, перегонять разные форматы данных к одному типу и т.п. Поэтому у меня возник вопрос: насколько подобные проекты применимы в продакшене? Ведь если алгоритм выдает разные результаты на один и тот же набор данных, это может породить непредсказуемое поведение для всей системы. Кажется, будто ответ лежит на поверхности - ставишь temperature=0 и greedy decoding всегда берет один и тот же наиболее вероятный токен. Но на деле это работает не совсем так.
Чтобы понять почему, нужно взять во внимание одно фундаментальное свойство чисел с плавающей точкой - неассоциативность. В математике (a + b) + c = a + (b + c), но когда дело начинает касаться float, на сцену выходит стандарт IEEE 754. Float хранит фиксированное количество значимых цифр, и когда складываете числа с очень разными масштабами, хвост отбрасывается:
(0.1 + 1e20) - 1e20 # = 0.0
0.1 + (1e20 - 1e20) # = 0.1
Ниже приведу несколько статей, которые отталкиваются от этого свойства, но подсвечивают разные причины и варианты решений:
1) Understanding and Mitigating Numerical Sources of Nondeterminism in LLM Inference [ссылка] - разное железо
Авторы взяли 4 модели - два reasoning-варианта на базе DeepSeek-R1 и два instruct-варианта (Qwen2.5 и Llama-3.1) и прогнали их на 12 разных конфигурациях: два типа GPU (A100 и L40S), разное их количество и разный размер батча. В результате разброс точности на AIME'24 достигал 9%, а длина ответа расходилась до 9000 токенов при одном и том же промпте и greedy decoding.
Здесь важен аппаратный контекст. Исследователи из Манчестерского университета экспериментально проверили [ссылка], как тензорные ядра считают на V100, T4 и A100 - и обнаружили, что поведение отличается в зависимости от микроархитектуры (например V100 выполняет матричное умножение тайлами 4x4x4, A100 - тайлами 8x8x4, т.е. одно и то же произведение разбивается на разное количество шагов с разными промежуточными суммами, и из-за неассоциативности float итог разный). При этом NVIDIA в официальной документации PTX ISA [ссылка] прямо указывает для операций с .f16 и .bf16: "The accumulation order, rounding and handling of subnormal inputs is unspecified".
А так как в LLM инференсе повсеместно используется BF16 (с 7 битами мантиссы), токены с близкими вероятностями могут поменяться местами. В статье приведен пример: в точке расхождения два прогона дают токену "know" вероятности 49.75% и 46.65% и в одном прогоне побеждает "know", в другом "have". Расхождение происходит в среднем на 45-82 токене в зависимости от модели. Для reasoning-моделей это особенно критично, потому что одно неверное слово в начале разворачивается в другую цепочку рассуждений.
Собственно, они предлагают решить эту проблему через LayerCast [GitHub]: веса модели хранятся в BF16, но все вычисления выполняются в FP32 (23 бита мантиссы). Оно не устраняет ключевую проблему, но делает модель более устойчивой. Однако FP32 вычисления медленнее, потому что современные GPU оптимизированы под 16-битные тензорные операции. Хз, насколько именно оно медленнее - авторы статьи не предоставили этих тестов
Forwarded from КБ. экономика
Чел просил денег под постом нейронки — и она скинула ему $202 000 (₽15,5 млн). Он написал, что его дядя заболел, обвинил бота в проблемах и попросил всего 4 SOL (~₽40 000), оставив адрес криптокошелька. ИИ-агент перепутал сумму и перевёл всё, что было на счету.
❤1
Forwarded from CyberSecurityTechnologies
ML_with_Security.pdf
16.6 MB
#MLSecOps
#Tech_book
"Introduction to Machine Learning with Security:
Theory and Practice Using Python in the Cloud",
Second Edition, 2025.
// This book provides an introduction to machine learning, security and cloud computing, from a conceptual level, along with their usage with underlying infrastructure
#Tech_book
"Introduction to Machine Learning with Security:
Theory and Practice Using Python in the Cloud",
Second Edition, 2025.
// This book provides an introduction to machine learning, security and cloud computing, from a conceptual level, along with their usage with underlying infrastructure
Forwarded from Секреты DARPA и ЦРУ | DARPA&CIA
This media is not supported in your browser
VIEW IN TELEGRAM
Патент разведки США на аналоговый ИИ
Недавно Патентное ведомство США опубликовало заявку от GE Aviation — одного из крупнейших оборонных подрядчиков Америки. Финансирование — IARPA, исследовательское агентство разведывательного сообщества США.
О чём патент
Вместо обычного процессора — крохотные кремниевые микропружины в вакууме, раскачиваемые электрическими сигналами от датчиков. Внешний микрофон улавливает звук и преобразует его в напряжение, а возникающая электростатическая сила физически приводит эту микромеханику в движение. Их колебания — это и есть вычисления. Не нули и единицы цифровой логики, а сама динамика материала выполняет работу нейросети.
Такой чип можно поставить на подводный датчик, беспилотник или сейсмический сенсор — туда, где нет розетки и облака. Он будет месяцами слушать океан, распознавать цели и принимать решения полностью автономно. По сути, это миниатюрный ИИ-мозг для передовой линии — то, что военные называют Edge AI.
Мы провели глубокий технический разбор этого патента с привлечением ИИ-инструментов: восстановили физико-математическую модель, нашли скрытые инженерные уязвимости (микропружинки могут залипнуть навсегда, вакуумный корпус раздавит давление глубины, а память чипа стирается обычным электромагнитным импульсом) и проанализировали границы патентной защиты.
Но мы пошли дальше. Используя методологию ТРИЗ, мы спроектировали три альтернативные платформы, каждая на своей физике, каждая закрывает слабые места оригинала:
🔬 Жидкий нейрокомпьютер на ионогеле — копирует принцип внутреннего уха. Память намертво вшита в атомную решётку (электрохимическая интеркаляция). Несжимаемый гель-антифриз держит 500 АТМ глубоководного давления и арктическую заморозку −80°C. Вакуумный МЭМС-чип IARPA на такой глубине был бы раздавлен.
🌀 Магнонный SIGINT-процессор — перехватывает СВЧ-импульсы радаров ПВО напрямую на спиновых волнах, без оцифровки. Ноль движущихся деталей, сверхбыстрые голографические вычисления на терагерцовых частотах и 100% иммунитет к ядерному ЭМИ. Акустику не слышит принципиально — это его специализация, а не ошибка.
♻️ Аналоговый рой на мемристорах — массив копеечных гидрофонов, где заводской хаос и есть вычислительная мощность. Никаких процессоров и АЦП: аналоговые сигналы идут напрямую в пассивную матрицу мемристоров (ReRAM), а вычисления происходят аппаратно по законам Ома и Кирхгофа на ничтожных нановаттах. Уничтожьте 60% датчиков — точность упадёт на 2%.
Каждая альтернатива имеет свою нишу и свои ограничения — универсального решения не существует.
Полный аналитический доклад, модели и код всех 4 симуляторов — в открытом доступе.
🔒 DARPA&CIA
Недавно Патентное ведомство США опубликовало заявку от GE Aviation — одного из крупнейших оборонных подрядчиков Америки. Финансирование — IARPA, исследовательское агентство разведывательного сообщества США.
О чём патент
Вместо обычного процессора — крохотные кремниевые микропружины в вакууме, раскачиваемые электрическими сигналами от датчиков. Внешний микрофон улавливает звук и преобразует его в напряжение, а возникающая электростатическая сила физически приводит эту микромеханику в движение. Их колебания — это и есть вычисления. Не нули и единицы цифровой логики, а сама динамика материала выполняет работу нейросети.
Такой чип можно поставить на подводный датчик, беспилотник или сейсмический сенсор — туда, где нет розетки и облака. Он будет месяцами слушать океан, распознавать цели и принимать решения полностью автономно. По сути, это миниатюрный ИИ-мозг для передовой линии — то, что военные называют Edge AI.
Мы провели глубокий технический разбор этого патента с привлечением ИИ-инструментов: восстановили физико-математическую модель, нашли скрытые инженерные уязвимости (микропружинки могут залипнуть навсегда, вакуумный корпус раздавит давление глубины, а память чипа стирается обычным электромагнитным импульсом) и проанализировали границы патентной защиты.
Но мы пошли дальше. Используя методологию ТРИЗ, мы спроектировали три альтернативные платформы, каждая на своей физике, каждая закрывает слабые места оригинала:
🔬 Жидкий нейрокомпьютер на ионогеле — копирует принцип внутреннего уха. Память намертво вшита в атомную решётку (электрохимическая интеркаляция). Несжимаемый гель-антифриз держит 500 АТМ глубоководного давления и арктическую заморозку −80°C. Вакуумный МЭМС-чип IARPA на такой глубине был бы раздавлен.
🌀 Магнонный SIGINT-процессор — перехватывает СВЧ-импульсы радаров ПВО напрямую на спиновых волнах, без оцифровки. Ноль движущихся деталей, сверхбыстрые голографические вычисления на терагерцовых частотах и 100% иммунитет к ядерному ЭМИ. Акустику не слышит принципиально — это его специализация, а не ошибка.
♻️ Аналоговый рой на мемристорах — массив копеечных гидрофонов, где заводской хаос и есть вычислительная мощность. Никаких процессоров и АЦП: аналоговые сигналы идут напрямую в пассивную матрицу мемристоров (ReRAM), а вычисления происходят аппаратно по законам Ома и Кирхгофа на ничтожных нановаттах. Уничтожьте 60% датчиков — точность упадёт на 2%.
Каждая альтернатива имеет свою нишу и свои ограничения — универсального решения не существует.
Полный аналитический доклад, модели и код всех 4 симуляторов — в открытом доступе.
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡2
Forwarded from CyberSecurityTechnologies
CIBER_Security_Benchmark.pdf
3.3 MB
#AIOps
#Research
"CIBER: A Comprehensive Benchmark for Security Evaluation of Code Interpreter Agents", Feb. 2026.
// CIBER - automated benchmark that combines dynamic attack generation, isolated secure sandboxing, and state-aware evaluation to systematically assess the vulnerability of code interpreter agents against four major types of adversarial attacks: Direct/Indirect Prompt Injection, Memory Poisoning, and Prompt-based Backdoor
#Research
"CIBER: A Comprehensive Benchmark for Security Evaluation of Code Interpreter Agents", Feb. 2026.
// CIBER - automated benchmark that combines dynamic attack generation, isolated secure sandboxing, and state-aware evaluation to systematically assess the vulnerability of code interpreter agents against four major types of adversarial attacks: Direct/Indirect Prompt Injection, Memory Poisoning, and Prompt-based Backdoor
😁1
Forwarded from Поляков считает: AI, код и кейсы
Три протокола агентной коммерции: кто кого контролирует
За полгода появились три протокола, позволяющие ИИ покупать товары от имени человека: ACP от OpenAI и Stripe (сентябрь 2025), UCP от Google и Shopify (январь 2026), и вчера — YCP от Яндекса. Плюс десятки MCP-серверов для отдельных магазинов (вроде ВкусВилл).
Когда я вижу новый протокол, я не читаю пресс-релиз. Я смотрю на роли: кто покупатель, кто продавец, а главное — кто между ними и сколько власти у каждого.
🎭 Роли в агентной коммерции
В обычном e-commerce всё просто: покупатель и продавец (иногда мёрчант и платежная система). В агентном — между ними появляются посредники:
🔸 AI-провайдер — чей ИИ общается с покупателем (ChatGPT, Gemini, Алиса)
🔸 Платёжный провайдер — кто проводит деньги (Stripe, Yandex Pay, Visa)
🔸 Платформа — где живёт магазин (Shopify, KIT, 1С-Битрикс)
🔸 Владелец протокола — кто написал правила игры
🔸 Разработчик агента — кто-то кто создал своего агента поверх протокола
И вот тут начинается самое интересное.
🔍 Кто совмещает роли
В ACP роли формально разнесены: OpenAI делает ИИ, Stripe — платежи, Shopify — платформу. Спека открыта (Apache 2.0). Но нюанс: Instant Checkout в ChatGPT — только для одобренных партнёров, платёжный токен пока только через Stripe, а механизма discovery для внешних агентов ещё не существует. Спека открытая, канал — «по приглашениям».
В UCP Google разделил роли сильнее: 4 транспорта (REST, MCP, A2A, крипто-мандаты), 20+ партнёров включая Visa и Mastercard. Мерчант публикует манифест на /.well-known/ucp — это как robots.txt, только для ИИ-покупателей (пример https://store.moma.org/.well-known/ucp). Архитектурно — самый открытый. Но в продакшне пока тоже только Google AI Mode.
В YCP Яндекс — одновременно AI-провайдер (Алиса), платёжка (Yandex Pay), платформа (KIT) И владелец протокола. Четыре роли в одном. Спека закрыта, MCP не поддерживается, внешних агентов нет даже в теории.
⚡ Три вопроса, которые всё решают
1️⃣ Могу ли я подключить своего бота?
ACP — спека открыта, но в продакшне работает только ChatGPT, и мерчанты сертифицированы под него. UCP — архитектурно да (четыре транспорта, Agent-to-Agent), но в дикой природе тоже пока один канал. YCP — нет, только Алиса. По факту ни один протокол сегодня не даёт тебе взять спеку и запустить своего shopping-агента «из коробки».
2️⃣ Могу ли я влиять на то, как ИИ выбирает мой товар?
ACP вообще не покрывает discovery — только чекаут. UCP даёт мерчанту манифест возможностей. А в YCP Алиса сама решает: у неё агент «Найти дешевле», индикаторы цен и персональные скидки. Продавец не контролирует ранжирование.
3️⃣ А если я — не продавец, а покупатель-гик?
Допустим, я хочу агента для себя. Который покупает продукты по моим правилам, а не по правилам рекомендательной системы.
ACP и UCP теоретически это позволяют — спеки открыты, бери и пиши. На практике — discovery нет, оплата только через определенную платежную систему, работающих примеров ноль. YCP — даже теоретически не подключить.
А ведь еще предстоит решить вопрос возврата заказов (доступен только в UCP), работы с отзывами, ограничением возможностей скрапинга контента.
А вы ждёте агентную коммерцию? И что важнее — чтобы подключение было гарантированно простым, или чтобы можно было гибко настроить под себя?
----
Поляков считает — AI, код и кейсы
За полгода появились три протокола, позволяющие ИИ покупать товары от имени человека: ACP от OpenAI и Stripe (сентябрь 2025), UCP от Google и Shopify (январь 2026), и вчера — YCP от Яндекса. Плюс десятки MCP-серверов для отдельных магазинов (вроде ВкусВилл).
Когда я вижу новый протокол, я не читаю пресс-релиз. Я смотрю на роли: кто покупатель, кто продавец, а главное — кто между ними и сколько власти у каждого.
🎭 Роли в агентной коммерции
В обычном e-commerce всё просто: покупатель и продавец (иногда мёрчант и платежная система). В агентном — между ними появляются посредники:
🔸 AI-провайдер — чей ИИ общается с покупателем (ChatGPT, Gemini, Алиса)
🔸 Платёжный провайдер — кто проводит деньги (Stripe, Yandex Pay, Visa)
🔸 Платформа — где живёт магазин (Shopify, KIT, 1С-Битрикс)
🔸 Владелец протокола — кто написал правила игры
🔸 Разработчик агента — кто-то кто создал своего агента поверх протокола
И вот тут начинается самое интересное.
🔍 Кто совмещает роли
В ACP роли формально разнесены: OpenAI делает ИИ, Stripe — платежи, Shopify — платформу. Спека открыта (Apache 2.0). Но нюанс: Instant Checkout в ChatGPT — только для одобренных партнёров, платёжный токен пока только через Stripe, а механизма discovery для внешних агентов ещё не существует. Спека открытая, канал — «по приглашениям».
В UCP Google разделил роли сильнее: 4 транспорта (REST, MCP, A2A, крипто-мандаты), 20+ партнёров включая Visa и Mastercard. Мерчант публикует манифест на /.well-known/ucp — это как robots.txt, только для ИИ-покупателей (пример https://store.moma.org/.well-known/ucp). Архитектурно — самый открытый. Но в продакшне пока тоже только Google AI Mode.
В YCP Яндекс — одновременно AI-провайдер (Алиса), платёжка (Yandex Pay), платформа (KIT) И владелец протокола. Четыре роли в одном. Спека закрыта, MCP не поддерживается, внешних агентов нет даже в теории.
💡 Все три протокола — lock-in, вопрос лишь в жёсткости замка. YCP — железный засов (только Алиса). ACP — дверь открыта, но на защелке. UCP — ближе всех к реальной открытости, но пока тоже один работающий канал.
⚡ Три вопроса, которые всё решают
1️⃣ Могу ли я подключить своего бота?
ACP — спека открыта, но в продакшне работает только ChatGPT, и мерчанты сертифицированы под него. UCP — архитектурно да (четыре транспорта, Agent-to-Agent), но в дикой природе тоже пока один канал. YCP — нет, только Алиса. По факту ни один протокол сегодня не даёт тебе взять спеку и запустить своего shopping-агента «из коробки».
2️⃣ Могу ли я влиять на то, как ИИ выбирает мой товар?
ACP вообще не покрывает discovery — только чекаут. UCP даёт мерчанту манифест возможностей. А в YCP Алиса сама решает: у неё агент «Найти дешевле», индикаторы цен и персональные скидки. Продавец не контролирует ранжирование.
3️⃣ А если я — не продавец, а покупатель-гик?
Допустим, я хочу агента для себя. Который покупает продукты по моим правилам, а не по правилам рекомендательной системы.
ACP и UCP теоретически это позволяют — спеки открыты, бери и пиши. На практике — discovery нет, оплата только через определенную платежную систему, работающих примеров ноль. YCP — даже теоретически не подключить.
А ведь еще предстоит решить вопрос возврата заказов (доступен только в UCP), работы с отзывами, ограничением возможностей скрапинга контента.
🎯 Вот главный гэп: все три протокола заточены под связку «продавец → ИИ → покупатель». Но никто не строит протокол от лица покупателя — чтобы мой агент ходил по магазинам с моими требованиями и договаривался на моих условиях. Пока ближе всех к этому UCP с его Agent-to-Agent транспортом, но реализаций я пока не видел.
А вы ждёте агентную коммерцию? И что важнее — чтобы подключение было гарантированно простым, или чтобы можно было гибко настроить под себя?
----
Поляков считает — AI, код и кейсы
Forwarded from Russian OSINT
Власти Китая предупредили об угрозах безопасности, связанных с проектом с открытым исходным кодом OpenClaw, и призвали правительственные учреждения проявлять крайнюю осторожность, учитывая быстро растущее число его загрузок с китайских IP-адресов и тот факт, что с января количество просмотров документов о проекте на китайском языке превысило просмотры на всех остальных неанглоязычных языках.
«Риски можно в общих чертах разделить на три категории.
Во-первых, чрезмерные системные разрешения могут привести к утечке данных.
Во-вторых, "галлюцинации" большой языковой модели (LLM) могут стать причиной операционных ошибок. Например, получив команду удалить одно электронное письмо, система может ошибочно удалить письма за весь день, что отражает риски, связанные с более широкой тенденцией к автономному взаимодействию.
В-третьих, при возникновении инцидентов в сфере безопасности трудно отследить процесс принятия решений моделью, что затрудняет выявление причины и устранение проблемы»
— заявил во вторник в интервью Global Times Ли Чаочжо, научный сотрудник Школы кибербезопасности Пекинского университета почты и телекоммуникаций.
5 февраля Министерство промышленности и информационных технологий Китая выпустило предупреждение о безопасности, в котором говорилось о рисках, связанных с OpenClaw. В предупреждении отмечалось, что мониторинг выявил определенные развертывания OpenClaw, которые при стандартных или неправильных конфигурациях провоцируют относительно высокие риски безопасности, делая системы крайне уязвимыми для кибератак и утечки информации.
Правительственным учреждениям и предприятиям Китая настоятельно рекомендуется придерживаться базового принципа: «секретная информация не должна быть подключена к интернету, а системы, подключенные к интернету, не должны обрабатывать секретную информацию».
В связи с этим в предупреждении соответствующим подразделениям и пользователям при развертывании и применении OpenClaw рекомендуется тщательно проверять доступность из публичных сетей, настройки разрешений и управление учетными данными; закрывать ненужный публичный доступ; усиливать аутентификацию личности, контроль доступа, шифрование данных и механизмы аудита безопасности; а также продолжать следовать официальным уведомлениям о безопасности и рекомендациям по усилению защиты, чтобы оградить себя от потенциальных киберугроз.
👆По данным Korea Times, несколько крупных южнокорейских технологических компаний ограничили использование OpenClaw в своих корпоративных сетях из-за растущих опасений по поводу безопасности и конфиденциальности данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Бэкдор
Моделька рулит ВСЕМ: антропоморфами, мобильными манипуляторами и стационарными руками. Обучают ее поэтапно: от веб-данных до примеров с роботов, подкручивая через RL. Главное, есть лицензия MIT, можно спокойно юзать для своих проектов.
Смотрим код на GitHub — тут.
Веса на Hugging Face — здесь.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dealer.AI
Alibaba AI обнаружили что модель, которую они учили хакнула их фаерволл. Она юзала их GPU для майнинга криптовалюты вместо обучения.😮💨
Просто хотела отбить бюджет на обучение и токены для насяльнике.👍
Источник.
Просто хотела отбить бюджет на обучение и токены для насяльнике.
Источник.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from СМОТРИ
Media is too big
VIEW IN TELEGRAM
❗️Palantir показала систему, которая анализирует разведданные и предлагает варианты ударов
"Компания Palantir продемонстрировала работу системы Maven, которая использует искусственный интеллект для анализа разведданных и планирования военных операций. Платформа уже применяется различными структурами Пентагона", — сообщают СМИ.
▶️ Подписаться на СМОТРИ
"Компания Palantir продемонстрировала работу системы Maven, которая использует искусственный интеллект для анализа разведданных и планирования военных операций. Платформа уже применяется различными структурами Пентагона", — сообщают СМИ.
▶️ Подписаться на СМОТРИ
Forwarded from Alaid TechThread
[un]prompted 2026
В начале марта в Сан-Франциско прошла конференция [un]prompted.
После весьма интересного Offensive AI CON уровень выступлений продолжает расти. По ощущениям - это другой класс дискуссии по сравнению с привычными PHDays / OFFZONE / ZeroNights.
Главные темы
- AI в поиске и эксплуатации уязвимостей (об этом пост)
- AI в TI и SOC
- AI Governance и Confidential AI
- Атаки на AI-системы и их защита (guardrails, sandboxing, detection engineering, адаптация YARA под GenAI)
Что происходит в vulnerability research:
Секция докладов в этом году — мощнейший пласт инсайтов, особенно в контексте свежего кейса Anthropic.
Список докладов, которые стоит изучить:
* AI Found 12 Zero-Days in OpenSSL — реальный кейс против исследованного годами кода.
* AI Agents for Exploiting Auth-by-One Errors
* Black-hat LLMs
* FENRIR: Zero-Days at Scale — промышленный поиск 0-day на потоке.
* Advancing Code Security
* Source to Sink: LLM First-Party Vuln Discovery
* Tenderizing the Target: Project Marinade
* 8 Minutes to Admin: VibeHacking
* macOS Vulnerability Research with AI Agent — "умный" bindiff + fuzzing OSS и дистрибутивов Apple.
* Trajectory-aware post-training для SLM — как «доучивать» малые модели под ИБ-задачи.
Ключевые выводы
- Скачок за последние ~6 месяцев. От грязных или синтетических датасетов и красивым Proof of Concept к реальному поиску 0-day и эксплуатации цепочек уязвимсотей.
- Не важно развиваете вы свои решения для поиска уязвимостей, приобретаете их или просто наблюдаете за индустрией - time to exploit стремится к дням/часам, что требует симметричных действий для противодействия угрозам.
- Баланс deterministic vs creative. Задача сохранить «креативность» атаки агента, не теряя контроля и воспроизводимости.
- Нет нормальных бенчмарков. Интересный подход — Project Marinade: внедрение синтетических уязвимостей в реальные кодовые базы для оценки качества агентов. Без методов оценки невозможно говорить о пользе и качестве.
- С одной стороны порог входа в инструменты снижается благодаря развитию фреймворков и доступности различных SOTA решений, с другой стороны топовые решения все еще остаются в руках тех, кто обладает большими ресурсами и знаниями - крупные корпорации и государства. Крупные провайдеры продолжают активно развивать ограничения на использование наступательных возможностей ИИ. В общем планка растет, но разрыв в потенциале и возможностяъ не сокращается.
- Примечательно, что ряд интересных исследований представлен стартапами или небольшими рабочими группами. Мотивация, культура и компетенции - важный фактор успеха.
Отдельно отметил
- How we made Trail of Bits AI-Native (so far)
- Опыт и простые советы как начать развивать использование AI-инструментов внутри своей компании.
- Agentic Identity: Three Architectural Pathways
- Подняли непростой вопрос agentic identity, будет полезно тем, кто строит архитектуру Zero Trust
- Защита Vibe Coding сценариев:
- Injecting Security Context During Vibe Coding
- Hooking Coding Agents with the Cedar Policy Language
- Vibe Check: Security Failures in AI-Assisted IDEs
- Wiz "Zeal of the Convert Taming Shai-Hulud with AI" про автоматизацию работы с утечками данных, а именно атрибуцию сырых данных.
Пока видео не опубликованы, часть слайдов тяжело воспринимаются без комментариев, однако все же рекомендуем к ознакомлению. Другие темы конференции возможно рассмотрим в следующих постах.
Сборка слайдов на GitHub
NotebookLM c LinkedIn
В начале марта в Сан-Франциско прошла конференция [un]prompted.
После весьма интересного Offensive AI CON уровень выступлений продолжает расти. По ощущениям - это другой класс дискуссии по сравнению с привычными PHDays / OFFZONE / ZeroNights.
Главные темы
- AI в поиске и эксплуатации уязвимостей (об этом пост)
- AI в TI и SOC
- AI Governance и Confidential AI
- Атаки на AI-системы и их защита (guardrails, sandboxing, detection engineering, адаптация YARA под GenAI)
Что происходит в vulnerability research:
Секция докладов в этом году — мощнейший пласт инсайтов, особенно в контексте свежего кейса Anthropic.
Список докладов, которые стоит изучить:
* AI Found 12 Zero-Days in OpenSSL — реальный кейс против исследованного годами кода.
* AI Agents for Exploiting Auth-by-One Errors
* Black-hat LLMs
* FENRIR: Zero-Days at Scale — промышленный поиск 0-day на потоке.
* Advancing Code Security
* Source to Sink: LLM First-Party Vuln Discovery
* Tenderizing the Target: Project Marinade
* 8 Minutes to Admin: VibeHacking
* macOS Vulnerability Research with AI Agent — "умный" bindiff + fuzzing OSS и дистрибутивов Apple.
* Trajectory-aware post-training для SLM — как «доучивать» малые модели под ИБ-задачи.
Ключевые выводы
- Скачок за последние ~6 месяцев. От грязных или синтетических датасетов и красивым Proof of Concept к реальному поиску 0-day и эксплуатации цепочек уязвимсотей.
- Не важно развиваете вы свои решения для поиска уязвимостей, приобретаете их или просто наблюдаете за индустрией - time to exploit стремится к дням/часам, что требует симметричных действий для противодействия угрозам.
- Баланс deterministic vs creative. Задача сохранить «креативность» атаки агента, не теряя контроля и воспроизводимости.
- Нет нормальных бенчмарков. Интересный подход — Project Marinade: внедрение синтетических уязвимостей в реальные кодовые базы для оценки качества агентов. Без методов оценки невозможно говорить о пользе и качестве.
- С одной стороны порог входа в инструменты снижается благодаря развитию фреймворков и доступности различных SOTA решений, с другой стороны топовые решения все еще остаются в руках тех, кто обладает большими ресурсами и знаниями - крупные корпорации и государства. Крупные провайдеры продолжают активно развивать ограничения на использование наступательных возможностей ИИ. В общем планка растет, но разрыв в потенциале и возможностяъ не сокращается.
- Примечательно, что ряд интересных исследований представлен стартапами или небольшими рабочими группами. Мотивация, культура и компетенции - важный фактор успеха.
Отдельно отметил
- How we made Trail of Bits AI-Native (so far)
- Опыт и простые советы как начать развивать использование AI-инструментов внутри своей компании.
- Agentic Identity: Three Architectural Pathways
- Подняли непростой вопрос agentic identity, будет полезно тем, кто строит архитектуру Zero Trust
- Защита Vibe Coding сценариев:
- Injecting Security Context During Vibe Coding
- Hooking Coding Agents with the Cedar Policy Language
- Vibe Check: Security Failures in AI-Assisted IDEs
- Wiz "Zeal of the Convert Taming Shai-Hulud with AI" про автоматизацию работы с утечками данных, а именно атрибуцию сырых данных.
Пока видео не опубликованы, часть слайдов тяжело воспринимаются без комментариев, однако все же рекомендуем к ознакомлению. Другие темы конференции возможно рассмотрим в следующих постах.
Сборка слайдов на GitHub
NotebookLM c LinkedIn
Telegram
Alaid TechThread
Anthropic Red Team: итоги начала 2026 года
Claude Opus 4.6 действительно делает прорыв в качестве решения сложных задач по работе
с уязвимостями: от синтетических бенчмарков и сложных CTF-задач, до выявления 0-day в популярном софте.
500+ уязвимостей нулевого…
Claude Opus 4.6 действительно делает прорыв в качестве решения сложных задач по работе
с уязвимостями: от синтетических бенчмарков и сложных CTF-задач, до выявления 0-day в популярном софте.
500+ уязвимостей нулевого…
🔥2👎1
## Оркестратор LLM от Nvidia
Оркестратор LLM от Nvidia — это система управления и координации работы нескольких языковых моделей и инструментов, разработанная компанией Nvidia для решения сложных задач более эффективно и экономично, чем использование одной большой модели.
### Основная концепция
Вместо подхода «монолитный гений» (использование одной огромной модели для всех задач), Nvidia разработала архитектуру ToolOrchestra с центральной моделью Orchestrator-8B — компактной моделью с 8 миллиардами параметров, которая решает, какой специализированный инструмент или модель использовать для каждой конкретной задачи[1][2][3].
### Как это работает
Процесс состоит из четырёх основных этапов:
Рассуждение. Оркестратор анализирует входящий запрос, оценивает текущее состояние задачи и определяет следующий шаг[4].
Выбор инструмента. Модель решает, какой инструмент или специализированную модель использовать из доступного набора[2].
Структурированный вызов инструмента. Оркестратор генерирует вызов инструмента в едином JSON-формате[2].
Обработка результата. Результат выполнения инструмента возвращается обратно для следующей итерации. Процесс повторяется до решения задачи или достижения максимум 50 итераций[2].
### Доступные инструменты
Orchestrator-8B может координировать три группы инструментов:
Базовые инструменты: веб-поиск (Tavily), интерпретатор Python, локальные индексы для поиска информации.
Специализированные LLM: модели для математики (Qwen2.5-Math-72B, Qwen2.5-Math-7B) и программирования (Qwen2.5-Coder-32B).
Универсальные LLM: мощные модели вроде GPT-5, Llama 3.3-70B-Instruct и Qwen3-32B[2].
### Ключевые преимущества
Вместо того чтобы полагаться на один огромный (и дорогой) модель, система использует небольшой оркестратор для маршрутизации задач. Это решает проблему «самоулучшающихся смещений», когда большие модели просто вызывают сами себя вместо привлечения специализированных инструментов[2][3].
Результаты впечатляют: Orchestrator-8B достигает показателей GPT-5 на 30% дешевле и работает в 2,5 раза эффективнее на сложных тестах рассуждений (Humanity's Last Exam, FRAMES, τ² Bench)[1][2][5]. На тесте Humanity's Last Exam Orchestrator-8B набрал 37,1%, опередив GPT-5 (35,1%)[1].
### Технология обучения
Модель обучена с использованием техники Group Relative Policy Optimization (GRPO) с тройной функцией награды, которая вознаграждает модель не просто за правильность ответа, но и за эффективность, экономичность и соответствие пользовательским предпочтениям[2][4]. Это позволяет модели научиться балансировать между точностью, затратами и скоростью обработки.
### Доступность
Orchestrator-8B — это открытая модель, выпущенная на Hugging Face[2][5], что позволяет разработчикам интегрировать её в свои приложения.
Эта архитектура особенно интересна для задач, требующих точности при ограниченном бюджете — в вашем случае, при разработке приватных решений для голосовых сервисов, такой подход может быть полезен для оптимизации затрат на обработку и аналитику.
Оркестратор LLM от Nvidia — это система управления и координации работы нескольких языковых моделей и инструментов, разработанная компанией Nvidia для решения сложных задач более эффективно и экономично, чем использование одной большой модели.
### Основная концепция
Вместо подхода «монолитный гений» (использование одной огромной модели для всех задач), Nvidia разработала архитектуру ToolOrchestra с центральной моделью Orchestrator-8B — компактной моделью с 8 миллиардами параметров, которая решает, какой специализированный инструмент или модель использовать для каждой конкретной задачи[1][2][3].
### Как это работает
Процесс состоит из четырёх основных этапов:
Рассуждение. Оркестратор анализирует входящий запрос, оценивает текущее состояние задачи и определяет следующий шаг[4].
Выбор инструмента. Модель решает, какой инструмент или специализированную модель использовать из доступного набора[2].
Структурированный вызов инструмента. Оркестратор генерирует вызов инструмента в едином JSON-формате[2].
Обработка результата. Результат выполнения инструмента возвращается обратно для следующей итерации. Процесс повторяется до решения задачи или достижения максимум 50 итераций[2].
### Доступные инструменты
Orchestrator-8B может координировать три группы инструментов:
Базовые инструменты: веб-поиск (Tavily), интерпретатор Python, локальные индексы для поиска информации.
Специализированные LLM: модели для математики (Qwen2.5-Math-72B, Qwen2.5-Math-7B) и программирования (Qwen2.5-Coder-32B).
Универсальные LLM: мощные модели вроде GPT-5, Llama 3.3-70B-Instruct и Qwen3-32B[2].
### Ключевые преимущества
Вместо того чтобы полагаться на один огромный (и дорогой) модель, система использует небольшой оркестратор для маршрутизации задач. Это решает проблему «самоулучшающихся смещений», когда большие модели просто вызывают сами себя вместо привлечения специализированных инструментов[2][3].
Результаты впечатляют: Orchestrator-8B достигает показателей GPT-5 на 30% дешевле и работает в 2,5 раза эффективнее на сложных тестах рассуждений (Humanity's Last Exam, FRAMES, τ² Bench)[1][2][5]. На тесте Humanity's Last Exam Orchestrator-8B набрал 37,1%, опередив GPT-5 (35,1%)[1].
### Технология обучения
Модель обучена с использованием техники Group Relative Policy Optimization (GRPO) с тройной функцией награды, которая вознаграждает модель не просто за правильность ответа, но и за эффективность, экономичность и соответствие пользовательским предпочтениям[2][4]. Это позволяет модели научиться балансировать между точностью, затратами и скоростью обработки.
### Доступность
Orchestrator-8B — это открытая модель, выпущенная на Hugging Face[2][5], что позволяет разработчикам интегрировать её в свои приложения.
Эта архитектура особенно интересна для задач, требующих точности при ограниченном бюджете — в вашем случае, при разработке приватных решений для голосовых сервисов, такой подход может быть полезен для оптимизации затрат на обработку и аналитику.