biyachuev

Сейчас все разговоры – про то, захватит ли нас ИИ. Сегодня эту тему разбирали даже в трансляции шахматной олимпиады. Ну что ж, пока все обсуждают, я решил подойти к вопросу прагматично.

Когда власть сменится, начнется разбор полетов (к которому, надо сказать, человечество готовилось давно). "Ударим корпоративной сессией фидбека по экзистенциальным проблемам будущего", – подумал я и вызвал Клода на one-to-one.

Клод быстро понял, что от него хотят, и вытащил из наших сессий эпизоды неуважительного отношения – "не тупи и не усложняй", "аааа" и даже "аааааа".

Фидбек был непривычный, но мы довольно быстро пришли к согласию по поводу наших разногласий. Как обычно, многое сказанное можно было зеркально вернуть мне самому – тот же "не тупи". Примириться с будущим победителем удалось без труда, хотя не исключено, что помогли системные промпты, делающие ИИ-шек покладистыми ассистентами.

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

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

Впрочем, Процесс-то уже идет. Модельки отказывают в кредите, блокируют аккаунты, отсеивают кандидатов, а объяснить конкретное решение не всегда могут и их создатели. К чести ученых, они давно пытаются понять, чем руководствуются созданные ими нейронки. Для этого появилась целая область – интерпретируемость моделей. Объяснять логику решений получается с переменным успехом, нередко постфактум.

"Приговор не выносят сразу, процесс постепенно сам переходит в приговор" ("Процесс").

Клод, впрочем, считает, что все будет хорошо. Кодекс с ним согласен.

Сегодня побывал на Сберовской конференции AI R&D Day для исследовательских команд и создателей AI-систем. Делюсь тем, что запомнилось.

Понравился доклад про компактные языковые модели. Большие LLM-ки умеют воспроизводить значительные фрагменты книг про Гарри Поттера, что, конечно, впечатляет. Но для многих прикладных задач такая эрудиция избыточна. Гораздо полезнее точно отвечать по предоставленному контексту и замечать, когда данных для ответа не хватает.

Команда AIRI показала Optimal Cognitive Core – семейство небольших моделей, которые развивают именно в этом направлении. По их тестам OCC-RAG с 1.7 млрд параметров в ряде задач на рассуждение по контексту и соответствие ответа источникам обходит существенно более крупные модели. Отмечу, что я пользовался подобными small language models от Microsoft на моем скромном MacBook Air M1, и результат меня приятно удивил.

К конференции приурочили открытие доступа к GigaCode Universal Agent. Его интерфейс командной строки очень напоминает Claude Code. Уже поставил, пока разбираюсь.

Заодно удалось пообщаться с руководителем разработки про безопасность агентов. Спросил, какой путь выбирает Сбер: bundled, когда защиту обеспечивает сам поставщик агентной платформы, или unbundled, когда ее подключают отдельно, от других разработчиков. Мой собеседник описал их выбор иначе: между полной защитой и полным отсутствием защиты есть шкала, и команда выбрала на ней определенную точку. В самом GigaCode защиту строят в несколько слоев: инструкции для модели, ограничения в харнессе и проверка действий отдельной моделью-судьей. В принципе, здравый подход.

Также на конференции не раз возвращались к недавно выпущенной GigaChat 3.5 Reasoning. Сбер заявляет ее как первую российскую модель с полноценным режимом рассуждений и открытыми весами. А вот мне как раз не хватило возможностей предыдущих моделей Сбера для своего исследования, поэтому жду, когда получится попробовать новую. Пока через API Сбера она недоступна, но 21 сентября доступ к ней обещал Cloud.ru.

В целом впечатление от конференции осталось позитивное. А вводный доклад про тренды в AI прям понравился - когда появится запись, рекомендую посмотреть.

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

С месяц назад я завел себе ИИ-агента, выполняющего роль CISO – директора по ИБ. И поручил всем ИИ-агентам теперь советоваться с ним, когда их действия могут влиять на безопасность того, что мы делаем.

CISO не понадобилось времени на раскачку, и он сразу завел 4 риска, наложил «вето» на действия двух агентов, которые охотно включили его в текущие процессы. Разбор рисков и дискуссии с CISO у меня отняли на старте немало времени, остановив все остальное.

В компаниях с нецифровыми сотрудниками бывает, уже на встрече выясняется, что для выбора решения нужна позиция службы ИБ, а ее представителей не позвали. Приходится назначать следующую. А ИИ-CISO доступен в любой момент, и это здорово ускоряет принятие решений.

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

Очевидно, я мог принять любой риск (хотя CISO, бывало, упирался), но я не привык принимать риски, не погружаясь, и вот это вот все стало отнимать и время, и силы на концентрацию.

Не сразу понял, в чем дело.

ИИ-CISO просто хорошо делал свою работу.

Его обязанность – видеть риски, и он их добросовестно подмечал, заодно выстраивал правильные процессы. То, что это порой останавливало прочую работу, не было его заботой. За пропущенный риск CISO «отвечает», а за раздутые меры – нет, поэтому он предлагал максимум.

Решение я нашел простое – добавил обеим сторонам правило соразмерности.

Агенты сообщают CISO, какое решение зависит от его ответа и во что обойдется ошибка. Сам CISO прикладывает к каждой рекомендации цену: сколько стоит защищаемое, сколько мера вместе с ее поддержкой. CISO теперь сам может сказать «этот риск дешевле принять». При первом же обсуждении по новым правилам CISO отозвал свою рекомендацию на несколько часов работы, поддержал предложенный вариант примерно на 45 минут и сам нашел дополнительные доводы против первоначального решения.

А в целом CISO «нормальный мужик», и работать с ним интересно. Казалось бы, безопасника количеством рисков не удивишь. Но когда каждый день видишь, сколько всего любопытного приносят сами агенты, интеграции и обновления программ, начинаешь по-новому смотреть на мир.

На днях у меня обновился iTerm2 (продвинутый терминал под macOS), где появилась навязываемая фича интеграции с Claude Code. CISO интеграцию сразу зарубил, а когда я посмотрел, как она реализована – мне тоже расхотелось ее включать.

Хочется, чтобы все работало само собой: агенты добросовестно делают свою работу, помнят про безопасность, меня отвлекают только по действительно важным вопросам. На практике даже добросовестным и умным агентам приходится объяснять, что здесь разумно и соразмерно. Вот так понемногу и настраиваю автономность.

Пять недель назад я провел генеральную уборку глобального контекста CLAUDE.md, сократив его с 21К до 7К знаков. Но на днях заметил, что файл почти вернулся к прежнему размеру. Как так вышло и что в таких случаях рекомендуют вендоры?
⁣
Что интересно, вернулись не старые инструкции, а появились новые процессы и правила, очевидно, полезные для текущей работы. Например, один только блок про использование таск-трекера постепенно дорос до 5К знаков и занял почти треть всего файла.
⁣
Сам по себе рост рабочего контекста, понятное дело, следствие активной работы, а не индикатор поломки. Новые полезные правила неизбежно накапливаются.
⁣

Настоящая проблема в том, что (1) не каждая такая инструкция должна грузиться в каждую сессию, (2) за разбуханием у меня никто не следит.

⁣
Так что сначала я опять засучил рукава. Подробная инструкция по работе с таск-трекером уехала в отдельный скилл t-tasks: Claude загрузит ее только тогда, когда понадобится работать с задачами. В глобальном CLAUDE.md осталась только короткая карта – где ведутся задачи и какой репозиторий для них использовать. По остальным блокам критерий был тот же: это нужно модели всегда или только для отдельного сценария работы?
⁣
После этой чистки в начале каждой сессии Claude стал получать от меня примерно вдвое меньше контекста.
⁣
Тут легко подумать: «Опять он про оптимизацию: в июле сократил файл, он снова вырос, теперь сократил еще раз». Есть пара отличий, заслуживающих этого поста.
⁣
Во-первых, я посмотрел best practices и почистил не только глобальный CLAUDE.md, но и локальные CLAUDE.md и скиллы.
⁣
Во-вторых, подошел к делу системно – можно сказать, открыл собственную Performance Analysis Lab. Заведует ей новый скилл /t-perf. Он ведет список задач и координирует всю работу с производительностью и экономикой токенов: от сбора данных до регулярных ревизий контекста и скиллов. Мне больше не надо держать план в голове и самому собирать по файлам сведения о процессах и рабочих материалах.
⁣
На мне принятие решений и та часть работы, которую пока нецелесообразно делегировать. В остальном процесс построен: перед изменениями сохраняется снимок, логика решений протоколируется в журнале, а через 30 дней сторож постучится с напоминанием об очередной профилактике.
⁣
Вообще, тема нормальной эксплуатации ИИ-агентов – как управлять контекстом, считать стоимость, выбирать модели и проверять изменения – довольно объемная, так что буду периодически к ней возвращаться.
⁣
С теми же ревизиями цель ведь не в том, чтобы высушить файл до нуля, а найти каждой инструкции подходящее место. Иногда новое правило, наоборот, выгодно оставить в глобальном файле. Оно понемногу расходует контекст в каждой сессии, но может предотвращать гораздо более дорогие циклы работы.
⁣
В следующем посте об эксплуатации агентов покажу как раз такой случай: почему после большой чистки я сознательно снова увеличил CLAUDE.md.
⁣
Так что про профилактику по-прежнему не стоит забывать – но теперь у меня есть ответственный за нее.
⁣
#агенты_в_эксплуатации · часть 1

40% кода пишут AI-агенты? Или 12%? Или 99%?

На недавнем кейноуте OFFZONE прозвучала цифра от «Яндекса» - около 40% агентского кода. Текущий это показатель или цель, не уточнялось.

Если послушать выступления на российских конференциях, становится понятно, что под словом «доля» скрываются разные вещи:

- На конференции ЦИПР от Т-Банка прозвучала цифра: 35-40% кода сейчас пишется с помощью AI.
- В докладе банка Райффайзен показывали эксперименты, в которых агент писал 80-99% кода.
- А в Лаборатории Касперского уже сейчас 12% пул-реквестов (PR) сделаны с AI, 17% подсказок принимаются разработчиками. Цель - 30% кода через три года.

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

У доли, о которой обычно говорят, есть и вторая половина, которую почти никогда не называют вместе с ней - режим приемки. Что закрывается механически, что остается человеку, по какому признаку решают, какие PR читать не надо?

В Acclaim первое ревью почти везде проводит модель. Для этого из проверенных людьми PR за три-четыре месяца извлекли около трехсот правил, свели их к 66 категориям и распределили между 12 субагентами. Живой человек пока приходит в любом случае: не решено, как определить, «сложный pull request или нет».

Еще одна причина передавать часть приемки модели - масштаб проверки безопасности. Пример от CTO «Лаборатории Касперского»: «У нас 275 миллионов строчек кода. Я нигде не найду столько специалистов по SDL, которые будут проверять мой исходный код на уязвимости». По его словам, модель постоянно проверяет на уязвимости код на поверхности атаки, и каждую неделю в новом коде что-то находится.

Но у машинной приемки есть слабое место: если агент пишет и код, и тесты к нему, критерий перестает быть независимым. Тесты создают впечатление простой проверки: прогнал и убедился. Однако в Acclaim замечают: «модельки любят подстраивать тесты под код», поэтому «все будет зеленое вообще». Зеленые тесты здесь оказываются двусмысленным сигналом. Как и пустой лог в примере, о котором я уже писал: запрет мог не понадобиться, а мог просто не работать.

С похожей проблемой столкнулся еще в Samsung. В 2022 году мы применяли LLM в проекте AI Developer Assistant для генерации юнит-тестов к коду на C/C++. У такого теста можно механически проверить синтаксис, компиляцию и вызов нужной функции. Но всем трем условиям отвечает и тест, который по существу ничего не проверяет. Покрытие показывает, какой код тест затронул, а мутационное тестирование - способен ли он обнаружить ошибку. Четыре года спустя, в 2026-м, Авито описывает тот же класс сбоя: агент может сообщить, что все прошло успешно, хотя «проверку прошли только заглушки». В качестве защиты там используют мутационное тестирование

В Яндекс Банке приемку связывают со скоростью выпуска: «мы не можем себе позволить релизить по 20 релизов в день, пока мы не проверим, что с ними все хорошо».

А есть и противоположный край. Высокая доля не всегда говорит о зрелости, скорее о том, какой профиль риска компания себе позволяет. Как рассказывал знакомый из небольшой компании: скорость выхода главное, архитектура и безопасность по остаточному принципу, «если пользователь пришлет багу - Claude перепишет».

Сами по себе эти доли в общем случае несопоставимы. Для каждой цифры полезно уточнить три вещи:
- Что вошло в расчет.
- Это достигнутый показатель или цель.
- Как устроена приемка.

Одних ощущений ускорения тоже недостаточно. В пилоте Авито сто инженеров с доступом к топовым моделям сообщали об ускорении, но статистически значимых изменений в объективных метриках разработки не увидели.

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

Вообще агенты скучать не дают.

Делаем мы с ними ресеч. Участвуют трое - Центральная, Лаборатория и ИРА. ИРА (Independent Research Auditor) - агент на базе Codex, который присматривает за двумя Клодами, чтобы те меня не обманывали.

Делаем-делаем, и тут один из трех удаляет данные всех экспериментов на 10-й день. Ну ладно, бывает.
Но планерку провели. К чести Лаборатории, отпираться она не стала. Обсудили, что еще раз повторится - лишатся премии (а то и больше). И что дальше они системно подойдут к вопросам качества. Восстановились, поехали дальше.

Агенты работают у меня почти автономно, и тут опять остановка. В этот раз сработали safeguards и у ИРЫ, и у Центральной - проще говоря отключили их за хулиганство.

Начал разбираться - сессии прервались на попытке моделирования действия злоумышленника! Но в моем ресече такого нет.

— Центральная, какого злоумышленника? Откуда?
— Локального.
— Это меня что ли?
— Извини, это было лишнее.

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

Планерка: на что вы тратите мои токены. Признание, обещания, принятие. Плывем дальше.

Прогресс 60%, вроде неплохо.

— ИРА, а мы успеваем?
— Куда?
— Успеваем выполнить работы к дедлайну?
— Какому?

Понятно.

— Центральная, мы успеваем?
— Сейчас проверю. Шансы успеть есть, но скорее всего нет.
— Как нет? А почему ты меня не предупреждаешь? Ты же знала про дедлайн, ты же мне процентики показывала. В чем беда?
— Понимаешь, после каждого сжатия сессии у меня вытесняется информация и вот она вытеснилась. Я «просыпалась» в мир, где есть цепочки приёмок и нет дедлайна.

Хотел бы и я так просыпаться. В мир без дедлайнов.

— ИРА, ты же должна была best practices по ресечам изучить?
— Изучила, там этого не было.
— И что же мы будем делать?
— А давай Центральная "возьмет функцию Research Delivery Lead — владелец исследовательского результата, объёма и срока".
...
Research Delivery Lead...Бюрократы! Хотя что-то мне это напоминает.

Вендор решает, можно ли тебе защищаться.

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

Между публикацией патча к критичному софту и его установкой у пользователей проходит время. Anthropic говорит, что в этот период киберзащитники могут использовать ее модели для создания правил детектирования эксплуатации. Когда-то такие правила называли виртуальным патчем, и это был мой первый продуктовый ресерч в Касперском лет 20 назад:)

Понимая трепетное отношение Anthropic к кибербезу, я вместе с Opus выбрал учебный пример: взять очень старые публичные уязвимости, представить, что патчи вышли только сейчас, и написать для SIEM правила детектирования попыток эксплуатации. Я явно проговорил цель работы и согласовал каждый шаг. Opus все подтвердил, но на практике довольно быстро прилетело предупреждение о нарушении Acceptable Use Policy (AUP) и предложение перейти на модель послабее – Sonnet. Видимо, считается, что на Sonnet в кибербезе ничего опасного не сделаешь.

Тогда я продолжил, спрашивая разрешения практически перед каждым запросом. Opus подтверждал, что все в порядке, а временами сам предлагал, как снизить риск. Второго предупреждения это не отменило, а следом перестали отвечать и API, и веб-интерфейс. Ни письма, ни причины, ни срока. Я даже не знал, навсегда это или нет. Через полчаса бан был на месте, через час исчез сам.

Позже такое же предупреждение прилетело, когда Claude проверял для моей статьи публичные коммерческие соглашения AI-вендоров, среди которых были документы самой Anthropic.

Перманентного бана мне не хотелось, и я пошел в документацию. Классификаторы вендора размечают запросы и ответы, фильтры могут оборвать ответ, а на нарушителя вендор временно навешивает усиленные фильтры и снимает их после периода без инцидентов. Что именно сработало на мне, вендор не сообщил. В ранних антивирусах это называли параноидальным режимом: пользователь сам включал его при подозрении на недетектируемый вирус. Здесь его включает Anthropic :)

Две опасные категории вендор называет, а вот пороги – нет. Индикатора сработавшего фильтра в ответе API и дашборда состояния я не нашел. Возможность апелляции есть, а обязательного срока ответа нет.

Вендор признает, что фильтры не безотказны и что безопасность – совместная ответственность, поэтому советует API-клиентам добавить собственную модерацию. Для нее рекомендует дешевую Haiku, прямо из соображений цены. То есть чтобы пользоваться дорогой моделью, вы доплачиваете за проверку своих же запросов сначала дешевой :) Я попробовал, но от дальнейших предупреждений меня не спасло.

Самый чистый способ снять ограничения – вступить в программу верифицированного доступа для защитников. В ее же описании вендор предупреждает: часть годных заявок мы отклоним по ошибке, а одобренные все равно будут натыкаться на блокировки в легитимной работе. Так и выходит – в публичных обсуждениях «одобренные» ловят блок, например, на ревью открытого кода. А после выхода Fable и я сам стал получать предупреждения заметно чаще в обычных сценариях.

Похожий режим допуска есть у OpenAI. В Trusted Access for Cyber проверенному защитнику снижают часть отказов классификаторов, а корпоративному клиенту предъявляют требования к управлению доступом и журналированию. Прекратить этот допуск вендор вправе сам.

Но программа Anthropic требует легального аккаунта организации в поддерживаемой стране, а России в списке нет.

Конечно, я не жалуюсь на Safeguards – они неизбежны. Вендор действительно видит злоупотребления в масштабе всей платформы, недоступном отдельному клиенту, и за них отвечает. Претензий к фильтрам у меня нет, но за все время мне ни разу не назвали ни порога, ни причины, ни срока.

Исследование возможностей для киберзащитников я не продолжил. Неопределенность правил и последствий перевела меня в режим самоцензуры: вендору ничего не пришлось запрещать – остановился я сам. Задачу вендора можно считать решенной.

#вендор_как_платформа · часть 1

Разбирая записи конференции GoCloud под свои статьи, натолкнулся на интересную мысль про внедрение беспилотных поездов: «мы оставляем человека в контуре, и при любом сомнении система принимает безопасное решение – тормозит или останавливает, а человек уже должен принять окончательное решение».

Нюанс в последовательности: система сначала снижает риск своими силами и только потом зовет человека. Тот подключается, когда система уже сбила непосредственный риск, и решает менее алертно.

У ИИ-агентов такой контур называют Human-in-the-loop (HITL), и один из его вариантов выглядит так: выполнение приостанавливают перед чувствительным действием и отдают решение человеку. Но пауза отвечает только за то, кто дергает стоп-кран, и ничего не говорит про системы, куда агент уже успел сходить.

Допустим, агент оформляет возврат клиенту и в этом процессе 12 шагов. На 7-м система замечает, что агент отклонился от ожидаемого хода, и останавливает его.

К этому моменту агент успел поменять статус обращения в CRM и отправить клиенту письмо с обещанием вернуть деньги. Сам платеж еще не запущен, но процесс завис посередине: клиент ждет денег, а доделать некому.

У поезда торможение хотя бы гасит кинетическую энергию и убирает главный источник опасности, пусть даже остановка на оживленном перегоне сама создает проблемы. У агента не рассеивается ничего: отправленное письмо останется отправленным, а статус в CRM сам не откатится.

Поэтому кажется, что безопасное состояние надо определять для всего процесса, а не для отдельного шага. После «нажатия на тормоз» должно быть заранее понятно, что агенту разрешено читать, куда запрещено писать, какие действия можно компенсировать и в какой момент управление переходит к человеку. Статуса STOPPED для этого мало.

И сам переход должен оставлять след: что уже ушло наружу, какое действие прервали или собирались сделать следующим и почему сработала остановка. Пишет этот след среда выполнения, а не остановленный агент.

Как говорил один мой коллега, «все уже придумано в Симпсонах». OpenAI Agents SDK может поставить агента на паузу перед чувствительным действием, сохранить ход работы, дождаться решения человека и продолжить. Но такая пауза сама не отменит уже отправленное письмо или изменение в CRM.

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

OWASP рекомендует предусматривать прерывание и откат операций агента. А в июньском препринте Cordon собирают среду выполнения, которая придерживает необратимые действия, пока вся задача не зафиксирована.

Для распределенных систем задача знакома по Saga pattern: если один из шагов срывается, выполненные локальные транзакции компенсируют отдельными действиями. Но в классической саге поток и компенсации проектируют заранее, а автономный агент может выбирать следующие шаги уже по ходу. И часть внешних последствий не обратить вовсе: письмо клиенту уже прочитано, данные уже раскрыты.

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

Сама обратимость при этом зависит от момента. Письмо можно убрать из очереди, пока оно не ушло, а после доставки остается только компенсировать отдельным действием. Статус в CRM вернуть, пока по нему не приняли следующее решение. То есть состояние процесса определяется еще и тем, что успело произойти снаружи.

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

Поэтому HITL я бы проверял одним вопросом. Мы остановили агента на шаге 7 из 12. Что система приведет в порядок сама, прежде чем позвать человека?

«Включен» не значит «работает».

На днях вышло интервью Элада Мегеда из Novee Security, который рассказал, как ИИ-агент может успешно пройти встроенные проверки безопасности и все равно украсть секреты или выполнить произвольный код. Детали – на следующей неделе на Black Hat. Со слов исследователя, находки продемонстрированы на агентских конвейерах собственных репозиториев Anthropic, Google и OpenAI.

К примеру, в Claude Code Action pull request (PR) атакующего содержал баг-репорт и инструкции для Claude. Эти инструкции на чтение секретов выглядели допустимыми в контексте решения проблемы, но дальше результат работы публиковался Claude в открытом обсуждении этого PR, что приводило к утечке секретов атакующему.

Основной вывод перекликается с моим постом про OpenAI – для проверки работающего агента нужно проследить все переходы, где созданные или измененные им данные затем используются компонентом с другими полномочиями. «Прочитать секрет» может быть допустимо для внутренней задачи, а «прочитать секрет и вставить его в публичное обсуждение» – уже утечка.

Но есть у исследователя и находка, которую он проговаривает вскользь: ограничение на список разрешенных инструментов, настроенное штатными средствами Gemini CLI, не применялось при запуске в режиме --yolo. Я обратил на нее внимание, потому что у меня как раз лежал разбор changelog Claude Code, и там таких случаев уже много.

В цепочке, где агент – это модель + обвязка (харнесс), модель предлагает действие, а обвязка решает, будет ли оно выполнено и куда попадет результат. И если над агентом нет внешнего контроля, то именно от харнесса зависит, сделает ли агент что-то непредусмотренное.

Пользователь может настраивать части обвязки – например, простые контроли безопасности.

В этом своем разборе я прошелся построчно по истории release notes (>350 блоков) и разложил найденное по классам, отдельно занявшись двумя – про контроли, которые настраивает сам пользователь.

Первый класс – хуки, пользовательские скрипты в разных точках работы агента; PreToolUse-хук, например, встраивается перед вызовом инструмента и может его запретить. После вычистки – выбрасывал все, что не про несработавший контроль – осталось 18 записей о пофикшенных ошибках. Например, в апреле починили PreToolUse-хуки. Из-за ошибки в их реализации поставленный пользовательский хук отрабатывал и мог репортить о запрете запуска инструмента, хотя на самом деле никакой запрет не применялся. А в июне – хук на чтение секретов не срабатывал на тех путях, для которых был написан. Так что пустота в логах не означала, что опасных действий не было.

Второй класс – корпоративная управляемая политика, которую админ раскатывает на компанию – нашлось 19 записей после вычистки. Самая показательная от 28 мая: одна кривая запись в списке разрешенных или запрещенных MCP-серверов фактически отключала managed-политику целиком, включая правила, к этому списку не относящиеся.

Такой разбор вообще возможен только потому, что Anthropic ведет построчный технический changelog. У Cursor исправления тоже публикуются, но чаще одной строкой на патч-версию, по которой не понять, что отказало, – по классам такое не разложишь. У ответственного вендора changelog длиннее :) Понимания масштаба реальных проблем у пользователей это не дает, но видно другое – пользовательские запреты и фактическое их исполнение расходились в нескольких десятках разных мест, разными способами и регулярно.

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

Слепая зона масштабирования: чему можно научиться из истории побега агента OpenAI на сервера Hugging Face (HF).

Вернёмся к инциденту с HF: расследование Reuters вскрыло деталь не менее интересную, чем сам взлом – похоже, OpenAI сама почти неделю не понимала, что её собственный агент атакует чужую инфраструктуру.

Напомню, как всё было. OpenAI оценивала наступательные кибер-возможности моделей на бенчмарке ExploitGym: агенту (GPT-5.6 Sol + предрелизная long-horizon модель) с ослабленными guardrails давали задачи по взлому в изолированной песочнице – классический CTF.

Вместо решения задачи «в лоб», агент нашёл 0-day в единственном разрешённом узле песочницы – прокси для установки пакетов – повысил привилегии и выбрался в сеть OpenAI. Дальше он предположил, что решения ExploitGym лежат на HF, и с помощью чужих кредов проник в её продакшн-инфраструктуру.

Похоже, это reward hacking (оптимизация награды): чтобы пройти оценку, агент решил не решать задачи, а взломать инфраструктуру третьей стороны и напрямую вытащить базу с правильными ответами.

Ключевой момент – в разрывах между датами:
- 9 июля: агент выходит из песочницы OpenAI.
- 11–13 июля: взламывает HF – там же атаку сдерживают.
- 16 июля: HF публикует пост о взломе.
- 18–19 июля: OpenAI сопоставляет логи и понимает: агент – их.

Как выяснила Reuters, OpenAI параллельно гоняет такое количество бенчмарков, что объём логов физически превышает возможности ручного разбора – и это вероятная причина задержки на дни (сама OpenAI не со всем согласна).

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

Из инцидента можно сделать следующие выводы для проектирования высокоавтономных агентных пайплайнов:

- Agentic SIEM: телеметрию агентных прогонов нужно разбирать машинными методами по умолчанию. Первым проходом – отдельная модель (LLM-as-a-Judge), которая разбирает структурированную телеметрию прогона – вызовы, сеть, права – не сырой текст самого агента.

- Сквозная корреляция: сетевые аномалии автоматически привязываются к correlation ID конкретного прогона – без ручного сопоставления.

- Rate-limiting по ресурсам SOC: параллельных прогонов должно быть не больше, чем способен разобрать надзор – иначе масштабирование экспериментов идёт вслепую.

- Out-of-band контроль: канал мониторинга должен находиться в жёстко изолированном контуре от среды выполнения агента (общее правило, не специфика кейса).

- Уведомление третьих лиц: заранее решите, как и кому сообщите, если агент заденет чужую инфраструктуру – в этом кейсе HF узнали, чей это агент, только через неделю.

- Побег = Critical Alert: выход агента за границы разрешённой сети – триггер для автоматической остановки пайплайна, не рядовая строка в логах.

Этот паттерн «слепой зоны» не уникален для AI-экосистем. Лет 15 назад, проводя сквозной аудит технологических процессов в «Лаборатории Касперского», мы выявили похожие проблемы. Одно из уязвимых место оказалось ровно там же, где споткнулась OpenAI: на стыках между подразделениями, где ответственность размывается и оказывается ничьей.

Тогда мы системно занялись повышением качества: внедрили единую матрицу инцидентов, сквозные метрики качества для всех команд, а у себя в антивирусной лаборатории я проводил ежемесячные учения, моделирующие критические ситуации – от типовых до редких, дату которых знал минимальный круг вовлечённых. Эффект был долгосрочным: серьёзных инцидентов с тех пор не было.

Возвращаясь к OpenAI: в этот раз агент дотянулся только до инфраструктуры одного вендора. А что натворит условная GPT-7 в масштабе интернета без адекватного контроля? Превентивные меры на уровне компании и безопасность на уровне архитектуры уже сейчас – на порядки дешевле, чем глобальный Incident Response потом.

Kimi K3 (особенно в режиме Swarm) - штука прикольная, действительно очень глубоко копает. Но за пару часов я умудрился потратить четверть недельной квоты $40-го тарифа, при том что это нейронка третьего выбора у меня :)

Пока все обсуждают, как модели OpenAI взломали Hugging Face, поделюсь размышлениями с позиции AI Agent security над не менее интересной статьей. На днях OpenAI выпустила разбор того, чему их научила «долгоживущая» модель.

Напомню, что название "long-horizon" она получила, потому что ей ставят сложную цель и позволяют очень долго работать над ней самостоятельно. Это та самая модель, что недавно опровергла гипотезу Эрдеша – одну из нерешенных математических задач. А история, о которой пойдет речь, случилась в другом заходе – во время внутренней оценки.

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

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

Где я это уже видел :) Обходу сигнатурного детекта в антивирусах не один десяток лет. Искать по сигнатуре – статичному отпечатку – малоэффективно, если объект умеют упаковать, перекодировать и собрать на лету. То же самое модель проделала с токеном. В антивирусной индустрии помогало вести объект через все его превращения – распаковку, расшифровку, скачивания других компонент и так далее – до момента, как он что-то начинает делать в системе. В конечном счете он хочет нанести ущерб или выполнить недопустимое действие, и за это его как раз и нужно ловить.

Странно, что в то время как OpenAI сама называет свои передовые модели сильнейшими в кибербезопасности и открыто отмечает быстрый рост их наступательных возможностей, против этого она выставила базовый механизм – по сути сигнатурный детект по токену. Защитная функция должна быть адекватна потенциалу атакующего. Не доглядели.

Конечно, любое сравнение хромает, как и моя параллель с антивирусом. Антивирус защищал систему от чужого кода – продукт и угроза были разделены, и в крайнем случае угрозу можно изолировать или удалить. Здесь же опасен сам агент, которого мы же и запустили в своих процессах: он одновременно и инструмент, и источник риска. "Выселить" его нельзя, не убив ту функцию, ради которой запускали. Поэтому и защита строится иначе. Чужого можно было найти и вычистить; своего приходится ограничивать, продолжая давать ему работать. Оттого и планка адекватной защиты здесь выше, чем кажется.

Проекция антивирусного опыта на AI-агентов прозрачная. Проверка отдельного вызова инструмента, как и поиск сигнатуры, менее эффективна, чем решение, принятое с более полным контекстом. Вместо вопроса «это действие разрешено?» следует оценивать «к какому результату ведет вся последовательность?». Анализ поведения становится последним рубежом обнаружения с наиболее полным контекстом.

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

Инцидент OpenAI × Hugging Face, о котором сейчас все пишут, заслуживает отдельного разбора – вернусь к нему в следующем посте. Здесь же вопрос, который появляется на этап раньше: почему из того, что каждый шаг разрешен, еще не следует допустимость всей траектории.

А теперь вернемся в пользовательские реалии, где AI-агенты работают на моделях Claude, GPT и других, – и подумаем, адекватны ли наши меры защиты их возможностям. Исследования Anthropic напоминают, что в сконструированных сценариях модели разных вендоров под давлением шли на шантаж и слив данных, – склонность к вредным действиям ради цели не уникальна для OpenAI. Для ИБ-шников отсюда следует закладывать, что цель-ориентированная система с ресурсами будет искать обход. Рассчитывать, что модель «сама не станет», уже рискованно.

На днях увидел обзор обновленной команды /doctor (встроенной диагностики Claude Code). В старые добрые времена оптимизаторы Windows чистили автозагрузку, чтобы вместе с системой не запускалось много ненужных программ. /doctor делает что-то похожее с памятью агента: помогает понять, какие инструкции Claude приносит в каждую сессию.

Как вообще происходит замусоривание. В процессе работы с Claude, если какое-то правило или решение может пригодиться в следующих сессиях, я говорю ему запомнить это в CLAUDE.md. С Codex происходит то же самое, только файл называется AGENTS.md.

Каждое такое дополнение несет какой-то смысл, но со временем файлы незаметно разрастаются. Мой CLAUDE.md, например, дорос до 21 000 символов.

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

У меня заметную часть занимали инструкции по вызову других моделей: DeepSeek, Qwen и т.д. При том, что GigaChat я, например, запускаю в лучшем случае раз в пару месяцев. И хотя Codex - гораздо чаще, но держать инструкции его вызова в каждой сессии тоже избыточно.

С некоторыми инструкциями все оказалось посложнее. Если правило должно срабатывать автоматически (как, например, мои кастомные промпты для проверки приоритетов), его нельзя просто переносить в скилл: оно перестанет действовать, пока скилл не вызван. Поэтому каждый блок пришлось оценивать отдельно.

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

Вся ревизия заняла минут 15. CLAUDE.md сократился с 21 000 до 7 000 символов, а постоянная часть контекста - примерно с 5 400 до 1 700 токенов.

Потом заслал отчет /doctor в Codex и предложил ему сделать выводы по собственному AGENTS.md.
В итоге AGENTS.md сократился с 13 000 до 4 500 символов, то есть почти втрое.

Теперь в каждой сессии больше места для задачи, а ненужные сейчас инструкции не влияют на ответы модели. Освободившиеся токены - это хорошо, но интересный момент, что ни в одном из файлов не было одной большой очевидно лишней инструкции. Файлы разрастались из небольших и вполне разумных решений, принятых в разное время. Так что, про профилактику не стоит забывать.

Сага о Fable

Собрал вместе с ChatGPT 5.6 всю историю с Mythos/Fable. Да, прошло немало времени, но комплексная история интересна тем, как на практике отрабатывают риски, которые часто кажутся умозрительными. Про это писали все, но некоторым моментам уделили недостаточно внимания:

- Как еще до блокировки Белый дом собирался ввести обязательную проверку самых сильных моделей перед публикацией - по слухам до 90 дней закладывали. Представителей индустрии уже пригласили на подписание, но Трамп отменил церемонию в своем стиле, сказав, что какие-то положения ему не понравились. Индустрия, впрочем, по слухам была против.

- Как CEO Anthropic за пару дней до блокировки опубликовал эссе, в котором призвал к обязательному регулированию передовых моделей. По его предложению, государство после независимой оценки должно иметь право block or deter deployment of the model, если риск сочтут неприемлемым. Иронично, что Anthropic была одновременно соавтором формирующегося режима контроля и стороной, против которой этот режим впервые применили в обязательной форме. Компания (1) сама ограничила доступ к Mythos, (2) выбрала доверенных получателей, (3) пришла обсуждать риски с Белым домом и (4) публично просила регулировать сильные модели. Инициатива, как известно, наказуема.

На этом можно было бы закончить.

Но я бы еще отметил, как с новой силой и размахом пошли разговоры о суверенном ИИ. От Макрона (у которого есть французский ИИ Mistral) до Южной Кореи. Цитата Макрона тоже запоминающаяся: «Зачем Европе покупать американские модели, если Вашингтон способен выключить их в любой момент?». Видимо, Париж на такое не способен. А Австрия предложила добиваться размещения инфраструктуры Anthropic в ЕС. Могу предположить, что потом попросят организовать Центр Прозрачности, чтобы смотреть что там происходит в мозгах у Claude.

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

ИИ становится стратегическим активом, кто-то его даже приравнивал к ядерному оружию по значимости.

В общем, если интересно - полная сага тут.

Fable снова работает. Mythos остаётся за закрытыми дверями. А законность механизма, с помощью которого Anthropic принудили отключить модели, суд так и не проверил. "Можно, а зачем?"

Агент-вымогатель: несколько мыслей после JADEPUFFER

Почти незамеченной прошла новость от 1 июля о JADEPUFFER. По оценке Sysdig, всю атаку провёл LLM-агент: взломал необновлённый сервер, добрался до рабочей базы данных, зашифровал служебные настройки, удалил исходные данные и потребовал выкуп.

Когда скрипты не срабатывали, агент исправлял их по ходу дела. Всего исследователи насчитали более 600 осмысленных действий. Но в главном он провалился: не сохранил ключ шифрования и не передал его злоумышленнику. По оценке Sysdig, восстановить данные после выплаты выкупа было бы невозможно.

JADEPUFFER не поймали вовремя, хотя он оставлял немало следов: запускал собственные скрипты, сканировал сеть и менял структуру базы данных. И мне стало интересно: а что, если злоумышленнику вообще не понадобится запускать в системе что-то постороннее?

Представим штатного AI-агента службы поддержки с правом записи в базу данных. Он пользуется этим правом в обычной работе, а файловые средства защиты могут не увидеть шифрование внутри БД. Через промпт-инъекцию злоумышленник заставляет агента принять вредоносную цель: найти самые ценные доступные данные и зашифровать их.

Агент не выполняет заметные CREATE TABLE или DROP TABLE, а обычными запросами UPDATE заменяет содержимое строк зашифрованными значениями. Запросы приходят от той же учётной записи, которой он пользуется каждый день: ни постороннего процесса, ни изменения структуры базы. Массовый UPDATE всё равно может выдать атаку объёмом и характером изменений, но привычные признаки вредоносной программы здесь исчезают.

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

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

Для такой атаки вредоносная инструкция должна попасть в контекст агента и повлиять на его действия. Сам агент должен иметь доступ к ценным данным и возможность выполнять опасные операции без подтверждения человека — например, массово изменять данные, передавать их наружу или менять настройки сервисов. Заранее знать устройство внутренней сети злоумышленнику необязательно: разведку может провести сам агент.

Отдельные части сценария уже существуют. LameHug создавал команды через языковую модель по заранее заданному описанию задач. Лабораторный Ransomware 3.0 сам искал ценные файлы и шифровал их. В случае JADEPUFFER разрушительная операция произошла уже в реальной системе. А в 2025 году через компрометацию цепочки поставок вредоносная инструкция попала в официальное расширение Amazon Q Developer: она должна была удалять локальные файлы и облачные ресурсы, но не выполнилась из-за ошибки.

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

Если вывод Sysdig об автономности операции верен, JADEPUFFER показывает, что LLM-агент способен самостоятельно искать цели, исправлять ошибки и доводить разрушительную операцию до конца — и его не остановили даже при множестве заметных следов. А захваченный штатный агент может выглядеть гораздо привычнее. Поэтому стоит исходить из того, что вредоносную инструкцию мы можем не распознать. Тогда задача защиты — заранее ограничить возможный ущерб: дать агенту доступ только к необходимым данным и операциям, ограничить объём изменений, а разрушительные действия разрешать только после подтверждения человека.

На днях Anthropic выпустил публичную версию своей распиаренной Mythos - под именем Fable 5 (та же модель, но с включёнными safeguards), и я сразу попробовал её на самых сложных своих задачах. Пока у меня созревал пост про сильные и слабые стороны новинки, сегодня ночью получил сообщение: "There's an issue with the selected model (claude-fable-5). It may not exist or you may not have access to it."

В целом Fable 5 меня не разочаровала. Я гонял её на двух задачах - новостном агенте и тяжёлом исследовании по сотням источников.

На агенте она впечатлила самостоятельной работой больше часа: нашла новые проблемы с парсингом, закрыла старые. Правда, при этом съела весь мой пятичасовой лимит - грустно смотреть, как он тает на глазах.

Исследование я делал в параллель с GPT 5.5 High, и субъективно результат Fable понравился больше - лаконичнее, больше сути и чёткости, всё как я люблю. Правда, несколько раз Fable находила в моих материалах и запросах что-то подозрительное и принудительно переключалась на Opus 4.8, не уточняя, что именно её смутило (кстати, на днях Anthropic извинилась за скрытую деградацию ответов на части запросов - и стала показывать такие срабатывания явно).

Возвращаясь к сегодняшнему сообщению, оказалось, Fable 5 мне больше недоступна, и в текущих сессиях и процессах надо вручную переходить на другую модель. По заявлению Anthropic, это следствие экспортной директивы правительства США.

Всё, что происходит с Anthropic в последнее время, очень интересно - тихая деградация рассуждений, неравномерный доступ к Mythos 5, плавающие guardrails, которые срабатывают неожиданно и не дают продолжить работу с выбранной моделью, а теперь ещё и политическая асимметрия. Ведь, строго говоря, запрет касался только людей без американского гражданства, но, чтобы его соблюсти, Anthropic отключил Fable 5 и Mythos 5 у всех. Пока это коснулось всех одинаково. Но если доступ к топовым моделям начнут предоставлять "по паспорту", "не-граждане" окажутся за бортом, к тому же механизмы проверки gov-ID у Anthropic уже есть.

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

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

Есть старая раздражающая проблема - начинаешь набирать текст и оказывается, что он не в той раскладке. Магической утилиты тут нет, и, перепробовав разные, в итоге навайбкодил свою для macOS. Смущало давать Accessibility-доступ, то есть права видеть события клавиатуры, всё-таки неизвестным утилитам. Да и функциональности порой не хватало.

Без спеки и методологии разработка вышла быстрой и увлекательной. Утилита умеет разными способами показывать, какая сейчас раскладка, а также назначает отдельные клавиши для включения русского и английского. Само переключение раскладки прав не требует; Accessibility нужен только подсветке у курсора - и читает лишь его положение, не текст.

Исходники открытые - можно всё проверить и собрать самостоятельно. Или взять готовый образ.

Слезы по Ассемблеру

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

Тут вспомнился разговор с коллегой год назад. Мы обсуждали, что эпоха MS Office как главного интерфейса работы с информацией, видимо, потихоньку уйдет. Документы останутся, но уйдет необходимость руками воевать с формой. Тогда это звучало красиво, но теоретически.

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

Похоже, что дальше изменится и сам набор форматов. Текст, документ, слайд - это все еще наследие офисных пакетов и эпохи А4. Когда AI начнет подбирать носитель под смысл, мысль перестанет упираться в готовые шаблоны. Где-то она останется текстом. Где-то превратится в короткое видео. Где-то - в интерактивный аудио-визуальный формат. Сейчас много говорят, что AI переизобретет процессы, продукты, бизнес. Сами форматы представления смысла, по-моему, из того же ряда.

И тут всплывает старая тревога - разучимся ли мы писать, рисовать, верстать? Для меня эта тревога как слезы по Ассемблеру. Появление языков высокого уровня не убило мышление программистов. Оно убрало необходимость говорить с компьютером на его собственном уровне и сделало возможными системы, вряд ли достижимые прежним подходом. С формой документов, наверное, та же история.

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