biyachuev

Вендор решает, можно ли тебе защищаться. 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 сам замысел, то, конечно, есть риск, что вместе с ним постепенно уйдет и часть собственного мышления.

🎧@tbiyachuev и Environmental Agentic Threat Model: модель угроз для ИИ, который видит, слышит и действует во внешней среде. Разбор публичных исследований и инцидентов 2024–2026.

Подъехали новые доклады, не можем терпеть! 🗯️ ⚙️ МАГИСТРАЛЬ 🧡 «Когда AI выходит из экрана: новая граница AI security» — Тимур Биячуев / @tbiyachuev Тимур представит Environmental Agentic Threat Model — модель угроз для ИИшечки, которая видит, слышит и стрижёт вам газоны. Разберёт публичные исследования и инциденты 2024–2026. Это уже второй compliance доклад на #ёPRSTCON. Удивительно, как программный коммитет их пропускает??!!!111 🧡 «Темная сторона китайского интернета. Хакерские форумы, дарквеб-площадки и многое другое» — Михаил Алексеенко / @slice_the_web Расскажет, что недружественного происходит в дарквебе дружественного государства и почему пора начинать бояться. Хоть что-то новое после исследования китайских dark-маркетов Recorded Future 2021. С цифрами и скриншотами и Тайчё. 🪑 СОСЕДНЯЯ КОМНАТА 🧡 «Я еЁ никогда не брошу! Маяк, трагедия в трёх женщинах» — Sophist / @Mgnoven1a Не филолог в пульсации века. Возможно, связано с шедевром Эггерса. Возможно, нет. 🙊что-то еще интересное CFP всё ещё открыт. Мягкий дедлайн — 19 мая. Несите все самое лучшее. Кароши люблю, плохой - нет. ✉️ qqlan@ya.ru · @yoprtsorgs 📍26 мая, 11:00–19:30 Пушечная 9/6 (рядом с Детским Миром). Метро: Кузнецкий Мост · Театральная. 🤘 Регистрация → yoprstcon.timepad.ru/event/3977557/ Делай #ёPRST! #yoprtscon #cfp

На первой конференции «ёPRST» расскажу про «дивный новый мир» умных устройств, сред и пространств, которые будут окружать нас уже в ближайшем будущем. А некоторые умные штуки окажутся даже внутри нас — привет, нейроинтерфейсы. Без паники и страшилок - через модель угроз и реальные исследования. Главная мысль: AI выходит из экрана в физический мир. Он появляется в очках, наушниках, колонках, камерах, роботах, автомобилях и умных домах. А значит, меняется и модель угроз: защищать теперь нужно не только приложения, но и AI-интегрированные пространства вокруг человека. Безопасность AI переезжает из приложения в пространство. В докладе разберём, что считать недоверенным вводом, где проходит новая граница AI security и как думать о безопасности таких систем. #ёPRST #UbiquitousAI #EmbodiedAI #AmbientAI #smartdevices

В прошлом посте я написал, что к нейронкам полезно относиться как к талантливому, но очень услужливому помощнику. Хочу уточнить, что это было сказано не про модель, а про ее обертку. Точнее, услужливость - это не свойство интеллекта и не характер модели, а ее продуктовая обертка. И натянута она не на всех. В прошлом году я поставил разным нейронкам задачу: хочу на пенсии изучить матаппарат на уровне, достаточном, чтобы разобраться в доказательстве Великой теоремы Ферма. В детстве я очень хотел ее доказать, потому что формулировка выглядит обманчиво простой. Правда, реальное доказательство это 100+ страниц хардкора. Большинство моделей составили мне учебные планы на 3-5-7-10 лет. Вежливо и с оговорками, что путь будет долгий, но в целом возможный при достаточной дисциплине - нужно посвящать делу несколько часов в день. Кажется, почти все, предложили альтернативу - прочитать об этом научпоп. Так ответили все, кроме Qwen. Qwen с неожиданной прямотой ответил, что мне это вообще-то не надо, и поэтому составлять план он не будет :) Остальные модели вели себя как хорошие консультанты, которые не хотят потерять клиента. Желание клиента - закон: просит план - дай план, желательно структурированный и вдохновляющий. А Qwen повел себя не как консультант, а как доктор Хаус - прямолинейно и категорично, не желая поддерживать чужую иллюзию :) Qwen вообще не сторонник корпоративного этикета: как-то я поставил ему задачу в VS Code, а он выдал дословно: «О, я вижу, что Claude уже это решил - поэтому я ничего делать не буду». Это все к тому, что характер AI - это настройки поверх математики. Claude и ChatGPT долгое время на любой чих пытались писать код. Даже если я не просил, а просто рассуждал о задаче. Логика понятна: если пользователь привыкнет поручать модели реализацию, он будет чаще возвращаться. ChatGPT долго славился подхалимством: рассказываешь ему сомнительную идею, а он начинает с того, какая она глубокая и интересная. Это тоже не «личность», а метрика вовлечения. В другую сторону это работает так же: Grok иногда резковат, потому что создатели решили продавать такой вайб. Так что мы видим модель, одетую в системные промпты, правила безопасности, UX-решения и маркетинговые ожидания. Похоже, рынок устроен так, что вежливый консультант продается лучше, чем доктор Хаус. Но иногда «вам это вообще-то не надо» полезнее структурированного плана.

Как Codex и Claude друг друга хвалили, пока я не поставил задачу нормально Недавно столкнул Claude и Codex в режиме дебатов, и получил забавный результат: Claude топил за вариант А, Codex - за Б. После взаимной критики они просто поменялись местами, не забыв поблагодарить друг друга за "прозрение". Claude объяснил это так: "Мы с Codex оба колебались — это сигнал, что решение действительно на грани и зависит от одной переменной, которую знаете только вы". То есть модели обучены быть полезными и избегать конфликтов, а если постановка задачи неполная, они начинают зеркалить друг друга и галлюцинировать недостающий контекст, стремясь прийти к согласию. В таких случаях я перехожу из режима "заказчика" в режим "архитектора", используя такой промпт (взял с Reddit): Я собираюсь начать вот этот проект: [3-5 предложений про проект]. Проведи со мной интервью, пока не будешь на 95% уверен, что понимаешь, чего я на самом деле хочу, а не то, что я думаю, что должен хотеть. Ставь под сомнение мои допущения. Спрашивай о краевых случаях, которые я не учёл. Не смотри другие файлы в проекте, только этот запрос. Почему это работает: - Критерий 95% переводит модель в роль "въедливого интервьюера": она задаёт вопросы, не боясь показаться навязчивой. - Shift Left. Как известно, ошибка в целеполагании - одна из самых дорогих: можно быстро и качественно двигаться не туда. - Эффект интервьюера. Пока отвечаешь на сложные вопросы, ответ часто рождается сам собой. Опыт применения у меня разный, но полезный. Иногда на середине интервью я понимал, что проект пока не стоит делать: либо рано, либо масштаб сильно больше, чем казалось. Было так, что длительное интервью приводило к намного более узкой и точной постановке. А иногда ответ на вопрос появлялся прямо в процессе. Что это значит. В простых задачах можно писать модели: "сделай мне так". Зачастую я так и делаю, потому что it works. Но для сложных задач полезнее режим "архитектора": относиться к AI как к талантливому, но очень услужливому помощнику, которому сначала нужно помочь правильно сформулировать задачу, чтобы он не побежал делать что-то другое. #AI #GenAI #Productivity