29 июня 2026 года InfoQ опубликовал 29-минутную виртуальную панель с четырьмя специалистами по AI Security, и общий вывод там довольно неприятный: самые опасные атаки на ИИ бьют не по самой модели, а по связям вокруг нее. Для тех, кто уже встроил LLM, RAG или агентные системы в продукт, безопасность ИИ теперь упирается не в красивый демо-стенд, а в доступы, логи, пайплайны данных и право модели что-то делать без человека.
Как пишет InfoQ, в обсуждении участвовали Эльхам Аршад из Trentino Digitale, Сабри Аллани из Expleo Group, Виджай Дилвейл из UltraViolet Cyber и исследователь безопасности ИИ Игор Малйкович из Университета Генуи. Панель вышла в серии Securing the AI Stack: From Model to Production и собрала типичный для 2026 года набор страхов: prompt injection, data poisoning, model drift, злоупотребление RAG, кража весов модели, jailbreak, а также социальную инженерию, которую генеративный ИИ поставил на конвейер.
Проблема не в «умной модели», а в том, куда ее подключили
Самая полезная мысль панели проста: индустрия переходит от защиты детерминированного софта к защите вероятностных систем. У обычного сервиса есть код, вход, выход и более-менее понятная логика отказа. У ИИ-системы есть еще контекст, внешние документы, обучение на данных, цепочки вызовов, инструменты и привилегии. Поэтому атака часто возникает на стыке компонентов. Prompt injection, по формулировке Малйковича, это не столько «дыра в модели», сколько провал границы между недоверенным пользовательским вводом и системными инструкциями. С data poisoning та же история: проблема обычно начинается не в модели, а на входе в тренировочный пайплайн, куда попадают подмешанные данные без нормальной валидации.
Из этого вытекает довольно приземленный вывод для команд: модель сама по себе часто не главный риск. Главный риск появляется, когда ей дали доступ к почте, тикетам, CRM, CI/CD, облачным API, внутренней базе знаний и еще разрешили действовать от легитимной учетной записи. Аллани отдельно выделяет косвенный prompt injection в агентных системах: атакующему не нужно ломать модель, достаточно спрятать инструкцию в PDF, письме, тикете или веб-странице, которую агент потом штатно обработает. Дальше начинается магия плохого автоматизатора: ассистент резюмирует документ, выполняет «невинное» действие и сам же эксфильтрует данные через разрешенный коннектор. С точки зрения классических средств защиты все выглядит почти законно. И в этом весь фокус.
На этом фоне эксперты довольно жестко пересобирают профиль security-инженера. Базовая кибербезопасность никуда не делась, но ее уже мало. Нужны threat modeling для моделей, данных, промптов и агентных поверхностей; понимание происхождения и целостности датасетов; навыки adversarial testing и red teaming именно для ИИ; наблюдаемость на уровне prompt/response telemetry, трасс вызовов инструментов и retrievаl traces; плюс нормальная инженерная дисциплина вокруг IAM, аудита и governance. Аллани прямо ссылается на NIST AI RMF и ISO/IEC 42001 как на полезную рамку мышления, а не на бумажную декорацию для комплаенса. И да, читать научные статьи по AI Security теперь тоже часть профессии: темп появления новых атак и защит там уже такой, что пересказа в блогах не хватает.
Самые разрушительные атаки уже бьют по людям и автоматизации
Когда экспертов спросили о самых опасных атаках прямо сейчас, ответы вышли показательно не «про модель». Аршад называет наиболее массовыми prompt manipulation, prompt injection и jailbreaking: порог входа низкий, часто хватает просто удачно написанного текста, а последствия каскадируют дальше по пайплайнам и решениям людей. Но Аллани и Дилвейл делают еще более неприятный акцент: самым разрушительным классом атак сегодня становится AI-усиленная социальная инженерия. Генеративные модели позволяют собирать контекст из открытых источников и утечек, писать правдоподобные письма с упоминанием реальных проектов, коллег и событий, а затем вести убедительный диалог в продолжение. Не «улучшенный фишинг», а промышленное производство убеждения. Даже MFA тут не панацея, потому что атака все чаще идет через helpdesk, восстановление доступа, токены сессий и штатные бизнес-процессы, на которые просто грамотно надавили.
Малйкович добавляет важную оговорку: не существует одной «самой опасной» AI-атаки для всех систем сразу. Для LLM, особенно подключенных к инструментам и рабочим процессам, prompt injection действительно может быть разрушительным. Для систем компьютерного зрения такая атака вообще не имеет смысла. Зато если говорить о предельном сценарии, то эксперт указывает на zero-click agentic remote code execution: ситуацию, когда агенту дали слишком много автономии и слишком слабые guardrails, а он выполняет удаленные действия без прямого участия пользователя. Пока это скорее предупреждение о классе риска, чем универсальный диагноз для каждого продакта. Но звучит как хороший повод не выдавать агенту root и не аплодировать его инициативности раньше времени.
Отдельный блок панели посвящен incident response, и тут тоже плохие новости для любителей чек-листов из прошлого десятилетия. У ИИ-инцидента другой вопрос в логе: не «кто получил доступ», а «почему система решила сделать именно это в этот момент». Обычных логов для ответа мало. Командам приходится восстанавливать, что модель увидела, какие документы извлекла, какой контекст или политика повлияли на вывод, какие инструменты были вызваны и какая версия промпта или модели тогда работала. Поэтому компании начинают собирать AI-specific playbooks: сохраняют prompts, retrieved documents, tool-call traces, hashes версий моделей, снимки политик, происхождение данных обучения. Для containment предлагают не только изоляцию хоста, но и отключение рискованных коннекторов, сужение retrieval scope, откат версии промпта или модели, а затем поведенческое regression-тестирование, чтобы система вернулась хотя бы к понятному baseline.
Следующий сдвиг еще радикальнее. По мнению участников панели, по мере роста автономности агентов security-архитектура должна смещаться от защиты периметра к контролю поведения и полномочий. Агенту нужен отдельный identity, свой профиль прав, жизненный цикл, аудит и понятный human override. Нужен Zero Trust не только для людей и сервисов, но и для действий модели на уровне инструмента: удалить конфиг, отправить письмо наружу, изменить запись поставщика, запустить пайплайн — все это должно проходить через узкие права, политику и, где нужно, ручное подтверждение. Аршад даже приводит в пример поведенческий подход, который уже продвигает Obsidian Security: важно знать не только что агент может делать, но и как он обычно себя ведет, к каким API обращается и какие данные трогает. Иначе расследовать отклонения будет примерно так же удобно, как разбирать аварию беспилотника по скриншоту из чата.
Главный вопрос теперь не в том, появятся ли новые атаки на ИИ, а в том, насколько быстро компании перестанут считать модель доверенным компонентом только потому, что она «работает в проде». Безопасность ИИ, если верить панели InfoQ, все больше сводится к неприятой, но взрослой формуле: не пытаться сделать систему идеальной, а строить такую, у которой ограничен радиус поражения, понятны мотивы действий и всегда есть способ дернуть стоп-кран.