Ситуация с побегом ИИ-моделей и успешными атаками ИИ-ботов перестаёт быть случайностью

Ситуация с побегом ИИ-моделей и успешными атаками ИИ-ботов перестаёт быть случайностью. Anthropic также заявил, что у него сбежал Claude и взломал три организации. Поскольку у меня уже есть опыт у клиента со 100% автономной ИИ-атакой, о котором я писал, то по разбору полётов сделал бы такие рекомендации.

1. Гоните в шею «бывалых» из старых специалистов по безопасности, если они потеряли связь с новой ИИ-реальностью

Как я описывал в кейсе своего клиента, в реальности ИИ-бот переиграл не просто системного администратора, а сотрудника службы безопасности. Ошибиться может каждый. Однако даже уже явно увидев, что бот ворвался в сеть и даже несмотря на указания коллег, что это точно не вирус, а ИИ-бот, всё равно включился снобизм «бывалых». Далее администратор делал совершенно неадекватные действия ИИ-угрозе, предполагая, что это либо вирус, либо хакер-человек. Однако ИИ-бот думает и действует быстрее кожаных безопасников, поэтому продолжил свою деятельность. В реале пришлось «бывалого» сначала отстранить от инцидента, а на следующий день его директор уволил. Несмотря на все регалии и кучу сертификатов по безопасности. Просто это всё не имеет уже значения, если угроза новая, а человек ей неадекватен. По взломам по кейсам OpenAI и Anthropic видно, что в компетенциях в части ИТ-безопасности ИИ-боты обыгрывают старых безопасников просто с разгромным счётом.

2. Почему Markdown-документация на код особенно опасна при ИИ-атаках? Ответ — Deploy Instructions.

Как я писал ранее, ИИ-бот забрался за первый firewall, но попал в DMZ, все системы компании были закрыты вторым экраном, но в DMZ он обнаружил тестовую песочницу подрядчиков, которые делали код с ИИ-агентами, а агенты писали к нему документацию в Markdown. Поясню, в чём принципиальная разница между внедрённой в код документацией и Markdown. Внедрённая в код документация с точки зрения атакующего ИИ-бота не очень ценная, он может уязвимости понять просто из кода. Однако крайне ценная информация для атакующих — это инструкции по развёртыванию (Deploy) и «отчёты о проделанной деятельности». Инструкции по развёртыванию, даже если там нет глупостей как прямая утечка логинов, обычно содержат актуальные версии окружения. Для поиска уязвимостей по базам для ИИ-бота это критическая информация, т.к. дырки привязаны к версиям ПО. Отчёты по сессиям ИИ-ботов вообще неконтролируемая утечка информации по своей природе. При разборе полётов обнаружилось, что Claude даже в Markdown-отчёты писал не только контекст, важный про окружение для взломов, но и была прямая утечка коммерческой тайны, когда ИИ как «тестовые данные» записал в отчёты реальные.

3. Что за ИИ атакуют у хакеров? Обычно китайские LLM, где отломали защиту

По моему инциденту делали анализ запросов ИИ-бота детекторами типа LLM по паттернам. Наиболее вероятно, что это был DeepSeek V4 Pro. Однако как модель согласилась делать заведомо вредные действия? Дело в том, что цензура добавляется в LLM только в конце. Не очень сложно вычесть вектора цензора из резидуальных потоков и получить Uncensored-версию, которая будет делать всё что угодно.

Какие тут действия я бы предложил:

1. Потерявшие связь с новой ИИ-реальностью «безопасники из прошлого» сами по себе угроза безопасности. Компании нужно понять, признают ли его сотрудники СБ угрозу ИИ-хакеров реальной, если нет, то от них надо избавляться сразу же.

2. Для документации в Markdown обязательно делайте субагента-ревьюера на безопасность. Особое внимание на Deploy-инструкции и отчёты ботов по сессиям. Ищите ревьюером не только уязвимости, но и утечки коммерческой тайны в отчётах.

3. Требуется обязательный ИИ-ревьюер по безопасности в пайплайне ИИ-разработки, т.к. всё что мы видим — лишь цветочки, ягодки будут развесистые

Телеграм: t.me/ainewsline

Источник: www.bloomberg.com

Комментарии: