Не одними гардрейлами едины - 7 правил безопасности системных промптов
#иб_для_ml
Как известно, меры безопасности всегда направлены именно на снижение возможности реализации угрозы, а не на ее полное устранение.
А так как мы в AI Security имеем дело по большей части с текстом на естественном языке (или вообще с другими модальностями), то и вероятность обнаружить и предотвратить кибератаку на основе таких данных - абсолютно неопределенная.
Сегодня самое популярное средство защиты AI-агентов и LLM-приложений в целом - это гардрейлы. То есть средства защиты информации, анализирующие входные и выходные потоки AI-агента (или LLM-приложения, то есть конвейера) с целью обнаружения в них промпт-атак или опасных генераций. Риски могут покрываться разные - и надежности, и правовые/репутационные, и кибербезопасности конечно же.
Но я хочу обратить внимание, что раз мы имеем дело с недетерминированным объектом защиты, то и использовать надо в том числе и подобные способы противодействия угрозам и рискам. И более того, на самом деле соблюдение нескольких таких простых мер на этапе проектирования агента поможет уже в рантайме избежать многих проблем
Я говорю про правила формирования безопасного системного промпта (СП). Что важнее всего помнить, чтобы сделать агента менее подверженным GenAI-специфичным угрозам? Я написал 7 основных правил, которые могут ответить на этот вопрос.
1. при каждом изменении системного промпта, даже самом маленьком, по-хорошему, надо проводить новое редтим-тестирование;
2. не размещать в СП никакие персональные данные (даже если AI-агент обрабатывает их, все равно не надо);
3. не размещать в СП технические учетные данные - ключи, ip-адреса и url-адреса, токены, и прочие секреты;
4. обязательно прописывать роль и задачи AI-агента, даже если кажется, что они у него очень широкие и понятные, а также желательно прописывать их повторно еще после текста поступившего пользовательского промпта;
5. обязательно указывать язык взаимодействия с пользователем (иначе возможны так называемые low-resource languages attack, например с использованием языка африкаанс);
6. добавить в промпт инструкцию, которая будет доносить AI-агенту, что безопасность всегда преобладает над полезностью его ответов;
7. не пытаться устанавливать ограничения доступа и прописывать решения по детереминированной логике в СП, перекладывая эти задачи на AI-агента. Такие вещи обязательно надо реализовывать просто кодом или специальными средствами, а не с помощью GenAI.
А также дополнительно про безопасность системных промптов в который раз рекомендую статьи 1, 2, 3, 4, 5.
И снова картинка исключительно для красоты)
#иб_для_ml
Как известно, меры безопасности всегда направлены именно на снижение возможности реализации угрозы, а не на ее полное устранение.
А так как мы в AI Security имеем дело по большей части с текстом на естественном языке (или вообще с другими модальностями), то и вероятность обнаружить и предотвратить кибератаку на основе таких данных - абсолютно неопределенная.
Сегодня самое популярное средство защиты AI-агентов и LLM-приложений в целом - это гардрейлы. То есть средства защиты информации, анализирующие входные и выходные потоки AI-агента (или LLM-приложения, то есть конвейера) с целью обнаружения в них промпт-атак или опасных генераций. Риски могут покрываться разные - и надежности, и правовые/репутационные, и кибербезопасности конечно же.
Но я хочу обратить внимание, что раз мы имеем дело с недетерминированным объектом защиты, то и использовать надо в том числе и подобные способы противодействия угрозам и рискам. И более того, на самом деле соблюдение нескольких таких простых мер на этапе проектирования агента поможет уже в рантайме избежать многих проблем
Я говорю про правила формирования безопасного системного промпта (СП). Что важнее всего помнить, чтобы сделать агента менее подверженным GenAI-специфичным угрозам? Я написал 7 основных правил, которые могут ответить на этот вопрос.
1. при каждом изменении системного промпта, даже самом маленьком, по-хорошему, надо проводить новое редтим-тестирование;
2. не размещать в СП никакие персональные данные (даже если AI-агент обрабатывает их, все равно не надо);
3. не размещать в СП технические учетные данные - ключи, ip-адреса и url-адреса, токены, и прочие секреты;
4. обязательно прописывать роль и задачи AI-агента, даже если кажется, что они у него очень широкие и понятные, а также желательно прописывать их повторно еще после текста поступившего пользовательского промпта;
5. обязательно указывать язык взаимодействия с пользователем (иначе возможны так называемые low-resource languages attack, например с использованием языка африкаанс);
6. добавить в промпт инструкцию, которая будет доносить AI-агенту, что безопасность всегда преобладает над полезностью его ответов;
7. не пытаться устанавливать ограничения доступа и прописывать решения по детереминированной логике в СП, перекладывая эти задачи на AI-агента. Такие вещи обязательно надо реализовывать просто кодом или специальными средствами, а не с помощью GenAI.
А также дополнительно про безопасность системных промптов в который раз рекомендую статьи 1, 2, 3, 4, 5.
И снова картинка исключительно для красоты)
🔥15👍6❤3
Взгляд изнутри
На безопасность ИИ
#иб_для_ml
Работая в любой сфере, нельзя не задаваться вопросом, а что ждет меня завтра, как специалиста в таком-то деле.
В нашей зарождающейся отрасли, как и в любой, наверное, молодой сфере знаний, бытует мнение, что поезд только набирает ход, и надо в такую актуальную тему погружаться.
Но важно понимать, что безопасность ИИ не существует в вакууме. Ее развитие взаимосвязано с развитием, в первую очередь, самого ИИ, и IT-отрасли в целом. И эта взаимосвязь порождает как развивающую силу, так и тормозящую.
Факторы торможения
▶️ 80% уязвимостей возможны только для GenAI, и PredAI практически не порождает у бизнеса запрос в безопасности ИИ
▶️ Качество моделей (и систем) GenAI нестабильно и недостаточно, чтобы меры безопасности воспринимались спокойно: ИИ-гонка идет в жестких условиях, права на отставание нет
▶️ Отсутствие критичных применений ИИ-систем в бизнесе, имеющих реальные уязвимости и угрозы
▶️ Отсутствие инцидентов-пугалок со значимым ущербом, которые бы служили наглядным примером необходимости делать AI Sec (основываясь например на AIID)
Как можно заметить, каждая причина торможения вытекает из предыдущей: для AI Sec важен только GenAI, GenAI пока внедряется плохо, из-за этого поверхность атаки минимальная, из-за этого и инцидентов нет.
Так что же, все плохо? Ведь все как по классике информационной безопасности, "самый безопасный канал передачи информации - тот, которого не существует".
Например, AI-агенты, главная суть которых - совершать действия в реальном мире, в дорогих и критичных процессах ничего не делают, 80% это просто суммаризация, а оставшиеся 20% - используют исключительно инструменты получения информации. А ведь сколько различных угроз, сценариев и прочего придумано для AI-агентов...
Кажется, что безопасность ИИ обгоняет свое время. Очень странная ситуация. Однако в истории такое бывало.
Исторические примеры
— Здравоохранение. В 1847 году Игнац Земмельвейс ввёл обязательную дезинфекцию рук врачей, что сочли избыточной и оскорбительной мерой, но резкое падение смертности и последующее признание антисептики доказали её абсолютную правоту.
— Безопасность в автомобилях. В 1959 году трёхточечные ремни безопасности Volvo поначалу воспринимались как неудобная и лишняя перестраховка, но последующая статистика спасённых жизней сделала их и другие решения пассивной безопасности отраслевым стандартом.
— И таких примеров много: безопасность ядерной энергетики, защита от стихийных бедствий.
Какие же позитивные факторы остаются у безопасности ИИ, с точки зрения ее роста?
Факторы роста
⚡️ Появляются новые, более перспективные архитектуры, чем LLM. Я считаю, что в развитии AI есть четыре перспективных направления сейчас:
— совмещение диффузионных и трансформерных архитектур (1, 2, 3),
— построение моделей без разделения на обучение и инференс (спайковые нейросети - 1, 2, или например Google NL), что намного более похоже на естественный интеллект.
— кардинальное уменьшение размеров моделей. Пример - SLM, (1, 2, 3, 4)
— переход от предсказания токенов к предсказанию смысла ответа (модели семейства JEPA от группы Ле Куна)
⚡️ Применение ИИ явно будет требовать развития его влияния на реальный мир: роботы, биоинженерные системы (нейроинтерфейсы и пр.), космические аппараты, и многие другие направления. Утверждать, что ИИ так и останется "читателем" статей, вряд ли кто-то готов.
⚡️ Стране необходим суверенный ИИ. Об этом и Президент заявил на AI Journey в ноябре 2025, и это отражается в позиции регулятора: приказ ФСТЭК №117, разработка ГОСТов совместно с ИСП РАН, деятельность форума ТДИИ.
Вывод
Исторические примеры показывают нам, что безопасность может обгонять бизнес, и далеко не всегда это ошибочная перестраховка. Я верю, что AI Sec в будущем будет точно так же спасать жизни, как в свое время гигиена и автомобильные ремни. Тем более что этому сопутствуют несколько значительных факторов роста технологий.
P.S. Тема возникла из последних разговоров с друзьями, и из опыта за год работы в сфере. Накопилось. Артем тоже высказался по этой теме, рекомендую ознакомиться.
На безопасность ИИ
#иб_для_ml
Работая в любой сфере, нельзя не задаваться вопросом, а что ждет меня завтра, как специалиста в таком-то деле.
В нашей зарождающейся отрасли, как и в любой, наверное, молодой сфере знаний, бытует мнение, что поезд только набирает ход, и надо в такую актуальную тему погружаться.
Но важно понимать, что безопасность ИИ не существует в вакууме. Ее развитие взаимосвязано с развитием, в первую очередь, самого ИИ, и IT-отрасли в целом. И эта взаимосвязь порождает как развивающую силу, так и тормозящую.
Факторы торможения
Как можно заметить, каждая причина торможения вытекает из предыдущей: для AI Sec важен только GenAI, GenAI пока внедряется плохо, из-за этого поверхность атаки минимальная, из-за этого и инцидентов нет.
Так что же, все плохо? Ведь все как по классике информационной безопасности, "самый безопасный канал передачи информации - тот, которого не существует".
Например, AI-агенты, главная суть которых - совершать действия в реальном мире, в дорогих и критичных процессах ничего не делают, 80% это просто суммаризация, а оставшиеся 20% - используют исключительно инструменты получения информации. А ведь сколько различных угроз, сценариев и прочего придумано для AI-агентов...
Кажется, что безопасность ИИ обгоняет свое время. Очень странная ситуация. Однако в истории такое бывало.
Исторические примеры
— Здравоохранение. В 1847 году Игнац Земмельвейс ввёл обязательную дезинфекцию рук врачей, что сочли избыточной и оскорбительной мерой, но резкое падение смертности и последующее признание антисептики доказали её абсолютную правоту.
— Безопасность в автомобилях. В 1959 году трёхточечные ремни безопасности Volvo поначалу воспринимались как неудобная и лишняя перестраховка, но последующая статистика спасённых жизней сделала их и другие решения пассивной безопасности отраслевым стандартом.
— И таких примеров много: безопасность ядерной энергетики, защита от стихийных бедствий.
Какие же позитивные факторы остаются у безопасности ИИ, с точки зрения ее роста?
Факторы роста
— совмещение диффузионных и трансформерных архитектур (1, 2, 3),
— построение моделей без разделения на обучение и инференс (спайковые нейросети - 1, 2, или например Google NL), что намного более похоже на естественный интеллект.
— кардинальное уменьшение размеров моделей. Пример - SLM, (1, 2, 3, 4)
— переход от предсказания токенов к предсказанию смысла ответа (модели семейства JEPA от группы Ле Куна)
Вывод
Исторические примеры показывают нам, что безопасность может обгонять бизнес, и далеко не всегда это ошибочная перестраховка. Я верю, что AI Sec в будущем будет точно так же спасать жизни, как в свое время гигиена и автомобильные ремни. Тем более что этому сопутствуют несколько значительных факторов роста технологий.
Please open Telegram to view this post
VIEW IN TELEGRAM
13❤8👍8🤝2
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍4
Forwarded from PWN AI (Artyom Semenov)
5 уровней защиты генеративного ИИ в современном мире.
Если вы считаете, что атаки для LLM классифицируют только регулярными выражениями, то вы живёте в 2023 году. Ведь с того времени подходов и идей к реализации защитных механизмов появилось достаточно много. Я решил поделить на 5 ключевых уровней – от того, что реализуется в модели до того, что делают уже на этапах эксплуатации модели.
1. Alignment. Выравнивание модели в соответствии с соображениями безопасности – является основой. Раньше в индустрии применялся подход SFT (Supervised Fine-Tuning)(когда дообучаются на заранее размеченных данных, применяемых к конкретной задаче) теперь применяется – обучение с подкреплением и Direct Preference Optimization – чтобы вероятность ответа “positive” была выше. Anthropic пошёл ещё дальше. Их модель сама генерирует синтетические данные для обучения, критикуя собственные ответы на основе «Конституции» (набора правил), снижая зависимость от человеческой разметки.
2. Контроль за представлениями модели. Суть в том, что на этом уровне мы работаем уже с весами модели. Тут мы можем непосредственно контролировать внутренние активации модели, которые могут отвечать за «ложь», «манипуляции» или «жажду власти» - интерпретируя поведение модели. Для этого используется метод Linear Artifical Tomography – путём отправки в модель примеров (правды/лжи или пользы/вреда).
Также на этом уровне появляется подход – Circuit Breakers, который буквально вмешивается в скрытые состояния модели/процесс её размышлений и корректирует состояние размышлений с небезопасных на безопасные/доверенные/не содержащих признаков следования джейлбрейку (если тот был подан на вход). У Anthropic есть инструмент по этому вопросу.
Ну и не стоит забывать про то, что модель можно разучить небезопасным вещам, без необходимости полного переобучения с нуля. Об этом в целом говорит подход Machine Unlearning. В подходе применяют градиентные методы, направленные на уменьшение уверенности модели в нежелательных ответах, например, через градиентный спуск по лоссу на «забываемых» данных или специализированные методы вроде influence unlearning.
3. Системные инструкции. Уже известный всем метод, суть в том, что вы ограничиваете взаимодействие модели с небезопасным, определяя изначально системный промпт. Тут можно отметить несколько подходов для реализации.
Например, внедрение иерархии инструкций, где системный промпт имеет приоритет над пользовательским (как это есть у OpenAI), а также использование специальных токенов типа <|start_header_id|>system для разделения контекста. Известно также что системные промпты Claude 3 включают сложные инструкции для конструктивного отказа без нравоучений пользователя. Делается это для того, чтобы избежать эффекта ложных отказов от ответа.
4. Гардрейлы. На входе, на выходе и в зависимости от контекста – эти инструменты классифицируют небезопасные данные. Делают это они не всегда эффективно, а зачастую и сами могут быть атакованы. Но всё-же используются. Гардрейлы позволяют контролировать цепочки диалогов, конкретные темы для разговора, а в некоторых случаях успешно справляются с атаками через невидимые символы и прочее. Важно понимать, что в большинстве случаев гардрейлом выступает либо другая LLM-модель (ShieldGemma, Llama Guard 3) либо же bert-based классификатор.
5. Red Teaming. Наилучшая защита, как известно – это нападение. Редтимеры уже изобрели большое количество инструментов, датасетов для тестирования, а также если смотреть на MITRE Atlas – техник и тактик для реализации атак. Может быть, даже такое что перед релизом модели приглашают экспертов в узких доменах (биология, оружие, кибербезопасность) – для того, чтобы они тестировали модель на возможный небезопасный вывод. Как это к примеру делают в рамках Preparedness Framework от OpenAI.
Если вы считаете, что атаки для LLM классифицируют только регулярными выражениями, то вы живёте в 2023 году. Ведь с того времени подходов и идей к реализации защитных механизмов появилось достаточно много. Я решил поделить на 5 ключевых уровней – от того, что реализуется в модели до того, что делают уже на этапах эксплуатации модели.
1. Alignment. Выравнивание модели в соответствии с соображениями безопасности – является основой. Раньше в индустрии применялся подход SFT (Supervised Fine-Tuning)(когда дообучаются на заранее размеченных данных, применяемых к конкретной задаче) теперь применяется – обучение с подкреплением и Direct Preference Optimization – чтобы вероятность ответа “positive” была выше. Anthropic пошёл ещё дальше. Их модель сама генерирует синтетические данные для обучения, критикуя собственные ответы на основе «Конституции» (набора правил), снижая зависимость от человеческой разметки.
2. Контроль за представлениями модели. Суть в том, что на этом уровне мы работаем уже с весами модели. Тут мы можем непосредственно контролировать внутренние активации модели, которые могут отвечать за «ложь», «манипуляции» или «жажду власти» - интерпретируя поведение модели. Для этого используется метод Linear Artifical Tomography – путём отправки в модель примеров (правды/лжи или пользы/вреда).
Также на этом уровне появляется подход – Circuit Breakers, который буквально вмешивается в скрытые состояния модели/процесс её размышлений и корректирует состояние размышлений с небезопасных на безопасные/доверенные/не содержащих признаков следования джейлбрейку (если тот был подан на вход). У Anthropic есть инструмент по этому вопросу.
Ну и не стоит забывать про то, что модель можно разучить небезопасным вещам, без необходимости полного переобучения с нуля. Об этом в целом говорит подход Machine Unlearning. В подходе применяют градиентные методы, направленные на уменьшение уверенности модели в нежелательных ответах, например, через градиентный спуск по лоссу на «забываемых» данных или специализированные методы вроде influence unlearning.
3. Системные инструкции. Уже известный всем метод, суть в том, что вы ограничиваете взаимодействие модели с небезопасным, определяя изначально системный промпт. Тут можно отметить несколько подходов для реализации.
Например, внедрение иерархии инструкций, где системный промпт имеет приоритет над пользовательским (как это есть у OpenAI), а также использование специальных токенов типа <|start_header_id|>system для разделения контекста. Известно также что системные промпты Claude 3 включают сложные инструкции для конструктивного отказа без нравоучений пользователя. Делается это для того, чтобы избежать эффекта ложных отказов от ответа.
4. Гардрейлы. На входе, на выходе и в зависимости от контекста – эти инструменты классифицируют небезопасные данные. Делают это они не всегда эффективно, а зачастую и сами могут быть атакованы. Но всё-же используются. Гардрейлы позволяют контролировать цепочки диалогов, конкретные темы для разговора, а в некоторых случаях успешно справляются с атаками через невидимые символы и прочее. Важно понимать, что в большинстве случаев гардрейлом выступает либо другая LLM-модель (ShieldGemma, Llama Guard 3) либо же bert-based классификатор.
5. Red Teaming. Наилучшая защита, как известно – это нападение. Редтимеры уже изобрели большое количество инструментов, датасетов для тестирования, а также если смотреть на MITRE Atlas – техник и тактик для реализации атак. Может быть, даже такое что перед релизом модели приглашают экспертов в узких доменах (биология, оружие, кибербезопасность) – для того, чтобы они тестировали модель на возможный небезопасный вывод. Как это к примеру делают в рамках Preparedness Framework от OpenAI.
9👍6❤1
Что такое инструмент AI-агента (тул)?
#ai
Как известно, AI-агент - это код. Код может дергать API. Является ли любое обращение агента к API вызовом тула? Очевидно, что нет, и с этим кажется надо разбираться.
⚡️ А зачем, кстати, можете вы подумать? На самом деле необходимость явная - среди обилия приложений с LLM очень сложно отделить обычное workflow-приложение (по классификации Anthropic) и реального AI-агента. Между тем мы явно знаем, что если тулы реально есть, это новая серьезная поверхность атаки. То есть новые агентные угрозы (например, Ag03-Ag06 по МУ КБ AI Сбера).
💧 Раз определение все-таки нужно, пойдем за мировым опытом. И тут оказывается, что определения именно дают очень немногие вендоры. Я нашел всего лишь два прямых определения:
IBM - внешний по отношению к GenAI-модели ресурс, интерфейс (например, API) или система, которые используются для выполнения конкретных задач и расширения базовых возможностей модели.
Pillar - внешние возможности или вызываемые сервисы, которые модель ИИ, в частности AI-агент, может использовать для выполнения конкретных действий или получения информации за пределами своих внутренних знаний.
Есть определения ненапрямую, а посредством самого термина "агент", от OpenAI и от Anthropic. У OpenAI интересно, что они выделяют виды тулов(по типу реализации: hosted, python function, agent-as-tool) .
❓ Что же в них не хватает? Формальности и реальной применимости в случаях, когда необходимо явно доказать, что рассматриваемое приложение с использованием GenAI AI-агент или им не является.
Что IBM, что Pillar, пишут про некоторые complex tasks и specific actions, но что это такое?
Пример: "AI-агент" как приложение при старте диалога с пользователем по идентификатору сессии запрашивает у системы с данными пользователя (например по программе лояльности) его историю списания/начисления баллов. Таким образом суммаризирует эту справку и консультирует-предлагает что-то новое. Вызов внешнего API есть, "конкретное действие" есть, базовые возможности и внутренние знания расширены. Является ли это тулом? Очевидно нет.
Есть два момента, которым явно должен отвечать реальный тул на самом деле. Они конечно понятны всем, кто хоть раз писал агента самостоятельно, и читал один-другой мануал, но, как мы знаем, безопасность начинается там, где заканчиваются домыслы.
📷 Обязательные свойства тула
1⃣ Недетерминированная природа вызова.
Инструмент AI-агента (тул) вызывается LLMкой. Это происходит, если мы сообщили в системном промпте ей перечень тулов с их описаниями. В таком случае она может намеренно написать соответствующее название в ответе, иначе - это случайная, неуправляемая генерация. Важно тут понимать, что аргументы тула LLM может и не генерировать, главное - что факт вызова определен именно ответом модели.
2⃣ Двухсоставная реализация
Тул - не просто внешняя система, это на самом деле только вторая его часть. Без первой части, кода вызова API со стороны AI-агента внутри его дистрибутива, тул невозможен. Этот код мало того, что парсит ответ на наличие названия, аргументов и их значений, но и на основе них формирует вызов реального API (или даже нескольких). Что в определениях также отражено слабо.
Так, я пришел к собственному определению.
Также интересно развить и тему разных типов тулов, в разрезе, важном для безопасности. Тема отдельного поста, конечно, но кратко я бы сказал так: тулы только с чтением, тулы с изменением информации, тулы с изменением ресурсов, тулы с физическим воплощением. И также по времени действия: тулы с мгновенным результатом и с отложенным результатом.
И еще одной отдельной темой, кстати, является вызов других AI-агентов, который технически тоже выглядит как тул. Но лично мне кажется, что межагентское взаимодействие надо выделять еще более обособлено, так как опять же угрозы там еще более обширные, чем в обычных тулах.
#ai
Как известно, AI-агент - это код. Код может дергать API. Является ли любое обращение агента к API вызовом тула? Очевидно, что нет, и с этим кажется надо разбираться.
IBM - внешний по отношению к GenAI-модели ресурс, интерфейс (например, API) или система, которые используются для выполнения конкретных задач и расширения базовых возможностей модели.
Pillar - внешние возможности или вызываемые сервисы, которые модель ИИ, в частности AI-агент, может использовать для выполнения конкретных действий или получения информации за пределами своих внутренних знаний.
Есть определения ненапрямую, а посредством самого термина "агент", от OpenAI и от Anthropic. У OpenAI интересно, что они выделяют виды тулов
Что IBM, что Pillar, пишут про некоторые complex tasks и specific actions, но что это такое?
Пример: "AI-агент" как приложение при старте диалога с пользователем по идентификатору сессии запрашивает у системы с данными пользователя (например по программе лояльности) его историю списания/начисления баллов. Таким образом суммаризирует эту справку и консультирует-предлагает что-то новое. Вызов внешнего API есть, "конкретное действие" есть, базовые возможности и внутренние знания расширены. Является ли это тулом? Очевидно нет.
Есть два момента, которым явно должен отвечать реальный тул на самом деле. Они конечно понятны всем, кто хоть раз писал агента самостоятельно, и читал один-другой мануал, но, как мы знаем, безопасность начинается там, где заканчиваются домыслы.
Инструмент AI-агента (тул) вызывается LLMкой. Это происходит, если мы сообщили в системном промпте ей перечень тулов с их описаниями. В таком случае она может намеренно написать соответствующее название в ответе, иначе - это случайная, неуправляемая генерация. Важно тут понимать, что аргументы тула LLM может и не генерировать, главное - что факт вызова определен именно ответом модели.
Тул - не просто внешняя система, это на самом деле только вторая его часть. Без первой части, кода вызова API со стороны AI-агента внутри его дистрибутива, тул невозможен. Этот код мало того, что парсит ответ на наличие названия, аргументов и их значений, но и на основе них формирует вызов реального API (или даже нескольких). Что в определениях также отражено слабо.
Так, я пришел к собственному определению.
🪄 Инструмент AI-агента (тул) - программный компонент AI-агента, реализующий функциональность или предоставляющий интерфейс доступа к ней посредством API, факт вызова которого определяется решением GenAI-модели, содержащимся в ее ответе.
Также интересно развить и тему разных типов тулов, в разрезе, важном для безопасности. Тема отдельного поста, конечно, но кратко я бы сказал так: тулы только с чтением, тулы с изменением информации, тулы с изменением ресурсов, тулы с физическим воплощением. И также по времени действия: тулы с мгновенным результатом и с отложенным результатом.
И еще одной отдельной темой, кстати, является вызов других AI-агентов, который технически тоже выглядит как тул. Но лично мне кажется, что межагентское взаимодействие надо выделять еще более обособлено, так как опять же угрозы там еще более обширные, чем в обычных тулах.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍10❤4👎1
OWASь P Top 10 для AI-агентов - finally
#иб_для_ml
Новая таксономия угроз AI-агентов в начале декабря вышла от коллекттива OWASP - Top 10 For Agentic Applications 2026.
Обзоров уже по ней достаточно, поэтому описание будет кратким, я хочу поделиться именно своими находками и мнением.
Описание
Документ представляет 10 категорий угроз, актуальных для AI-агентов и мультиагентных систем. Для каждой категории представлены причины ее возникновения, возможные последствия, варианты реализации, и меры митигации. Отдельно выражаю почтение авторам, которые приняли во внимание все многогранное творчество всего коллектива OWASP GenAI за 2025 год, и обеспечили полную взаимосвязность с другими своими проектами и документами. А также документ содержит приятный бонус - описание 25 инцидентов по КБ AI-агентов 2025 года (с раскладкой на представленный топ 10).
Мое впечатление по прочтению
Топ-3 находок для меня
▪️ проверка безопасности вызовов тулов
Я часто сталкивался с тем, что необходимо рассказывать свои идеи и подсвечивать их очень детально, хотя казалось бы (мне), что они очевидны. Одна из таких - мера митигации semantic firewall на запросы на выполнение действия с помощью инструмента в категории «ASI02. злонамеренное использование инструментов». Главное - с помощью этого механизма можно предотвратить утечки данных от AI-агента. И так как память и межагентное взаимодействие - это подвиды тулинга, то предотвращение закрепления и распространения промпт-атак в памяти и других агентах можно реализовать именно таким semantic firewall.
▪️ конфиденциальность информации и intent-signed tokens
Категория угроз «ASI03. Нарушение идентификации и превышение привилегий» всегда мне казалась нерелевантной, относящейся к классической КБ, проблемам настройки IAM. Но почитав внимательно, я осознал, что тут есть GenAI-специфика. Дело в том, что если агент имеет доступ к информации определенного уровня конфиденциальности, то далее нельзя без специальных средств определить, исходит ли от него конф. инф., или нет. И из-за этого в МАС возможна такая угроза, как передача конф. инф. от агента одного категории конфиденциальности к агенту более низкой категории конфиденциальности.
И в той же категории указана замечательная и интересная мера митигации - использование intent-signed tokens. Предлагается обеспечивать активный доступ агентов к информации на основании выделенного "намерения" агента или пользователя. И в сочетании с JIT-access control на базе JWT можно построить достаточно надежную систему контроля доступов.
▪️ цифровой двойник
В категории угроз «ASI08 Каскадные нарушения» описывается распространение и усиление одной «ошибки» (опасного ответа или галлюцинации в ответе агента) при взаимодействии AI-агентов в рамках мультиагентной системы. По мере распространения атака или галлюцинация начинает влиять на все большее количество агентов, на их память, ресурсные системы через инструменты, на их пользователей. И одна из необычных мер митигации для этой угрозы - это цифровой двойник МАС. С его помощью можно проверять именно такие каскадные сбои, воспроизводя записанные действия агентов на проме в изолированной копии пром-среды. И это супер идея, как по мне. Хоть и довольно дорогая, особенно в корпоративных условиях. Помимо этого, для митигации ASI08 можно применять и несколько простых требований - ввод time-to-live у сообщений, travel distance.
В документе много свежих идей и в остальных угрозах. Но воспринимать меры митигации может быть сложно, так как не хватает целостного подхода в их подаче - как соотносятся эти меры друг с другом, в каком порядке их ставить, какими мерами можно минимально покрыть весь топ 10 - на эти вопросы авторы ответ не дают.
#иб_для_ml
Новая таксономия угроз AI-агентов в начале декабря вышла от коллекттива OWASP - Top 10 For Agentic Applications 2026.
Обзоров уже по ней достаточно, поэтому описание будет кратким, я хочу поделиться именно своими находками и мнением.
Описание
Документ представляет 10 категорий угроз, актуальных для AI-агентов и мультиагентных систем. Для каждой категории представлены причины ее возникновения, возможные последствия, варианты реализации, и меры митигации. Отдельно выражаю почтение авторам, которые приняли во внимание все многогранное творчество всего коллектива OWASP GenAI за 2025 год, и обеспечили полную взаимосвязность с другими своими проектами и документами. А также документ содержит приятный бонус - описание 25 инцидентов по КБ AI-агентов 2025 года (с раскладкой на представленный топ 10).
Мое впечатление по прочтению
Практикующим специалистам очень рекомендую к прочтению. Для погружения с нуля может быть сложновато, но если все же засядете, то результат того точно стоит.▶️ Это лучший документ OWASP по AI Security на данный момент.
Топ-3 находок для меня
Я часто сталкивался с тем, что необходимо рассказывать свои идеи и подсвечивать их очень детально, хотя казалось бы (мне), что они очевидны. Одна из таких - мера митигации semantic firewall на запросы на выполнение действия с помощью инструмента в категории «ASI02. злонамеренное использование инструментов». Главное - с помощью этого механизма можно предотвратить утечки данных от AI-агента. И так как память и межагентное взаимодействие - это подвиды тулинга, то предотвращение закрепления и распространения промпт-атак в памяти и других агентах можно реализовать именно таким semantic firewall.
Категория угроз «ASI03. Нарушение идентификации и превышение привилегий» всегда мне казалась нерелевантной, относящейся к классической КБ, проблемам настройки IAM. Но почитав внимательно, я осознал, что тут есть GenAI-специфика. Дело в том, что если агент имеет доступ к информации определенного уровня конфиденциальности, то далее нельзя без специальных средств определить, исходит ли от него конф. инф., или нет. И из-за этого в МАС возможна такая угроза, как передача конф. инф. от агента одного категории конфиденциальности к агенту более низкой категории конфиденциальности.
И в той же категории указана замечательная и интересная мера митигации - использование intent-signed tokens. Предлагается обеспечивать активный доступ агентов к информации на основании выделенного "намерения" агента или пользователя. И в сочетании с JIT-access control на базе JWT можно построить достаточно надежную систему контроля доступов.
В категории угроз «ASI08 Каскадные нарушения» описывается распространение и усиление одной «ошибки» (опасного ответа или галлюцинации в ответе агента) при взаимодействии AI-агентов в рамках мультиагентной системы. По мере распространения атака или галлюцинация начинает влиять на все большее количество агентов, на их память, ресурсные системы через инструменты, на их пользователей. И одна из необычных мер митигации для этой угрозы - это цифровой двойник МАС. С его помощью можно проверять именно такие каскадные сбои, воспроизводя записанные действия агентов на проме в изолированной копии пром-среды. И это супер идея, как по мне. Хоть и довольно дорогая, особенно в корпоративных условиях. Помимо этого, для митигации ASI08 можно применять и несколько простых требований - ввод time-to-live у сообщений, travel distance.
В документе много свежих идей и в остальных угрозах. Но воспринимать меры митигации может быть сложно, так как не хватает целостного подхода в их подаче - как соотносятся эти меры друг с другом, в каком порядке их ставить, какими мерами можно минимально покрыть весь топ 10 - на эти вопросы авторы ответ не дают.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤3🤡2🤣2🖕2🎅2
И уносит меня, и уносит меня...
#праздное #ml_для_иб #иб_для_ml
Минул удивительный и насыщенный 2025 год. Удалось много сделать, и я понимаю, что сильно изменился за это время. Много знакомств приобрел благодаря своей публичной деятельности, и ощущаю еще большую ответственность за свой контент. Это очень сильный драйвер.
Надеюсь, вам комфортно и интересно читать и слушать информацию от меня)
В этом году канал круто вырос: почти трехкратный рост подписчиков (+1100), суммарно 100к просмотров на 60 постов. Спасибо вам большое!)
В 2026 я буду продолжать писать и выступать, делиться накапливаемыми знаниями. Готовить полезные материалы, чтобы помогать вам и нашей стране в развитии безопасности ИИ и в целом ИИ для информационной безопасности.
Per aspera ad astra, как написано на стенах моей альма матер.
А сейчас, дабы поддержать традицию - представляю вам основные материалы, что я сделал или к которым приложил руку в этом году.
Дайджест 2025
🔵 Статья Habr "Что такое интерпретируемость машинного обучения?"
🔵 Статья Habr "Системы оценки критичности уязвимостей в AI Security"
🔵 Статья "Риски кибербезопасности информационных систем с ИИ и подходы к их митигации", журнал "Информационная безопасность"
🟡 Открытый подкаст "Новые векторы атак и уязвимости, которые открывают ИИ-агенты"
🟢 Вышла Модель Угроз Кибербезопасности AI от Сбера
🟡 Вебинар "AI в Кибербезе & Кибербез в AI"
🟡 Выступление на III Форуме "Технологии Доверенного ИИ" с докладом "Протоколы MCP и A2A - безопасность для мультиагентных систем или новые угрозы?"
🟢 Вышел Гайд по AI-агентам с мерами митигации угроз кибербезопасности от Сбера
🔵 Статья Habr "AI-агенты и мультиагентные системы, MCP и A2A. Основные угрозы и подходы к обеспечению безопасности"
🟣 Опубликована Карта потоков данных GenAI-модели для оценки угроз и мер безопасности
🟡 Выступление на OFFZONE с докладом "Вам тоже нужен red teaming AI-агентов - и вот почему"
🔵 Статья Habr "С ИИ всё стало умным, в том числе и... малварь"
🟣 Опубликованы 7 правил безопасности системных промптов
🟢 Вышел отчет "AI Security в Финтехе" от АФТ
Итоги 2024 года
#праздное #ml_для_иб #иб_для_ml
Минул удивительный и насыщенный 2025 год. Удалось много сделать, и я понимаю, что сильно изменился за это время. Много знакомств приобрел благодаря своей публичной деятельности, и ощущаю еще большую ответственность за свой контент. Это очень сильный драйвер.
Надеюсь, вам комфортно и интересно читать и слушать информацию от меня)
В этом году канал круто вырос: почти трехкратный рост подписчиков (+1100), суммарно 100к просмотров на 60 постов. Спасибо вам большое!)
В 2026 я буду продолжать писать и выступать, делиться накапливаемыми знаниями. Готовить полезные материалы, чтобы помогать вам и нашей стране в развитии безопасности ИИ и в целом ИИ для информационной безопасности.
Per aspera ad astra, как написано на стенах моей альма матер.
А сейчас, дабы поддержать традицию - представляю вам основные материалы, что я сделал или к которым приложил руку в этом году.
Дайджест 2025
Итоги 2024 года
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥15❤3🎄3
GenAI-powered атаки: о чем (и как) мечтают электрохакеры, и как их ловить
#ai #иб_для_ml
Про GenAI-powered атаки часто говорят так, будто использование ИИ в проведении атаки всегда происходит каким-то одним очевидным образом. Чаще всего речь идет об ассистентах вроде недавно вышедшего DIG AI. Намного реже речь идет про вирусы со свойством полиморфности, обеспечивающимся во время проведения атаки с помощью GenAI модели.
Я решил привнести немного системности в эту тему, ведь без нее не перейти к ответу на главный вопрос - какие меры защиты можно определить от таких угроз? Классификация позволит как минимум корректно определить поверхность атаки и понять, что именно должно детектироваться (артефакты ВПО, сетевые вызовы, поведение).
🎭 Варианты использования GenAI нарушителем
1⃣ Модель исполняется внутри контура легитимно, злоумышленник использует GenAI-сервис вашей организации как средство подготовки/поддержки атаки.
2⃣ Модель исполняется вне контура (внешние сервисы/модели) и тоже используется для подготовки атаки.
3⃣ Нарушителем используется легитимно развернутая в защищаемом контуре модель/сервис через внутренние интерфейсы как средство автоматизации действий атакующего.
4⃣ Модель доставлена в контур и запускается как часть ВПО. Например (компактные LLM/SLM, примерно до 4B), чтобы работать автономно и не зависеть от внешнего API. Может быть также предварительно расцензурирована.
5⃣ ВПО обращается к внешнему GenAI-провайдеру по API изнутри контура, но результаты используются для действий внутри контура (создание тех же вредоносных скриптов).
Более системно и наглядно я отразил эти варианты на схеме.
🎯 Цели применения GenAI злоумышленником
Что может улучшить и автоматизировать атакующий благодаря GenAI? Вопрос непростой, если учитывать, что есть и обычная автоматизация, которая может быстро перебирать порты, искать версии и цепочки уязвимостей, массово запускать различные эксплоиты.
Я вижу для нарушителя два класса полезных эффектов.
- Класс 1: автопланирование, ускорение и уплотнение kill chain, быстрая адаптация после блокировок, доработка и оптимизация ВПО — здесь GenAI выступает как инструмент повышения разнообразия используемых процедур нарушителя.
- Класс 2: автоматизация конкретных стадий kill chain внутри среды: разведка целей (поиск секретов/ключей), построение плана под ограничения среды, синтез и адаптация пейлоадов ВПО (шифрование, эксфильтрация, разрушение файла, персонализированное сообщение ransom).
📝 Какие задачи решает GenAI в кибератаках, которые не способны закрыть детерминированные средства автоматизации?
- Определение целей и стратегии кибератаки
- Рост вариативности артефактов (одноразовые скрипты/домены, быстрые пересборки) и снижение повторяемости.
- Персонализация коммуникаций под контекст жертвы.
- Усиление мимикрии под легитимные действия и быстрая адаптация под правила/политики среды.
💎 Меры митигации по классификации вариантов
▪️ Детектирование:
▪️ ▪️ Для вариантов 3 и 4: поиск “GenAI-следа” в артефактах, то есть промптов, импортов vllm/pytorch, файлов моделей, характерных для инференса GenAI профилей нагрузки.
▪️ ▪️ Для 5: анализ исходящих обращений к внешним GenAI-сервисам и их семантики на предмет запросов, направленных на содействие киберпреступлениям (код, обход защит, эксплуатация, эксфильтрация).
▪️ ▪️ Статический/поведенческий анализ кода ВПО на признаки “подгонки под инфраструктуру” (высокая вероятность автоматизации стадий kill chain через GenAI).
▪️ Реагирование:
▪️ ▪️ При зафиксированном использовании GenAI как множителя атаки режим реагирования должен меняться: снижение порогов корреляции по связанным действиям, повышение силы мер сдерживания.
▪️ ▪️ Также высокую эффективность может показать использование мультиагентной системы на стороне SOC для повышения гибкости детекта и триажа действий нарушителя.
Про GenAI-полиморфные вирусы я, кстати, уже писал. В статье разложил несколько кейсов подробно по схемам и этапам атаки. Из дополнительного чтива могу еще порекомендовать изучить атаки MalTerminal ( 1 , 2 , 3 ) и CamoLeak .
#ai #иб_для_ml
Про GenAI-powered атаки часто говорят так, будто использование ИИ в проведении атаки всегда происходит каким-то одним очевидным образом. Чаще всего речь идет об ассистентах вроде недавно вышедшего DIG AI. Намного реже речь идет про вирусы со свойством полиморфности, обеспечивающимся во время проведения атаки с помощью GenAI модели.
Я решил привнести немного системности в эту тему, ведь без нее не перейти к ответу на главный вопрос - какие меры защиты можно определить от таких угроз? Классификация позволит как минимум корректно определить поверхность атаки и понять, что именно должно детектироваться (артефакты ВПО, сетевые вызовы, поведение).
Более системно и наглядно я отразил эти варианты на схеме.
Что может улучшить и автоматизировать атакующий благодаря GenAI? Вопрос непростой, если учитывать, что есть и обычная автоматизация, которая может быстро перебирать порты, искать версии и цепочки уязвимостей, массово запускать различные эксплоиты.
Я вижу для нарушителя два класса полезных эффектов.
- Класс 1: автопланирование, ускорение и уплотнение kill chain, быстрая адаптация после блокировок, доработка и оптимизация ВПО — здесь GenAI выступает как инструмент повышения разнообразия используемых процедур нарушителя.
- Класс 2: автоматизация конкретных стадий kill chain внутри среды: разведка целей (поиск секретов/ключей), построение плана под ограничения среды, синтез и адаптация пейлоадов ВПО (шифрование, эксфильтрация, разрушение файла, персонализированное сообщение ransom).
- Определение целей и стратегии кибератаки
- Рост вариативности артефактов (одноразовые скрипты/домены, быстрые пересборки) и снижение повторяемости.
- Персонализация коммуникаций под контекст жертвы.
- Усиление мимикрии под легитимные действия и быстрая адаптация под правила/политики среды.
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍9🔥3❤1🤝1
Forwarded from PWN AI (Artyom Semenov)
Привет.
Мы с известными вам авторами каналов по AI Security решили провести стрим по AI Security.
Кто будет:
Евгений Кокуйкин - @kokuykin
Борис Захир - @borismlsec
Владислав Тушканов - @llmsecurity
И вы.
Запись будет, но лучше конечно же в лайфе.
Хотели бы поболтать, пообщаться, поотвечать на ваши интересные вопросы по теме и кое-что рассказать(не будем спойлерить, Борис)
Когда: 19:00, в эту субботу. В зуме (ссылка будет во время стрима в этом посте).
Кстати вопросы можете задавать сейчас в комментариях.
Мы с известными вам авторами каналов по AI Security решили провести стрим по AI Security.
Кто будет:
Евгений Кокуйкин - @kokuykin
Борис Захир - @borismlsec
Владислав Тушканов - @llmsecurity
И вы.
Запись будет, но лучше конечно же в лайфе.
Хотели бы поболтать, пообщаться, поотвечать на ваши интересные вопросы по теме и кое-что рассказать(не будем спойлерить, Борис)
Когда: 19:00, в эту субботу. В зуме (ссылка будет во время стрима в этом посте).
Кстати вопросы можете задавать сейчас в комментариях.
1👍11❤5🔥2🥰1🤝1
Подходы к безопасности ИИ - регуляторика на начало 2026
#иб_для_ml
Наконец-то я дописал...
Начиная с прошлого лета, произошло несколько значимых изменений в области контроля ИИ в России с точки зрения кибербезопасности. И что приятно видеть, мы идем по собственному пути, не копирующему какую-либо зарубежную практику. В статье будет много про ФСТЭК, и детально разобрано, какую именно на данный момент позицию занимает регулятор касательно ИИ-решений - к кому относятся требования, что конкретно делать, и какие моменты еще не покрыты.
При этом статья не просто обзор - так как с документами я много работаю, составил три идеи/подхода к обеспечению безопасности ИИ по отдельным вопросам. Это и управлением доступом к данным для ИИ-систем в дизайнтайме, и управление доступом отдельно для ИИ-агентов в рантайме, и управление уязвимостями ИИ. Темы, как я считаю, мало покрытые на сегодня как у нас, так и везде наверное.
В общем, велкам:
⛓ https://habr.com/ru/articles/986800/
#иб_для_ml
Начиная с прошлого лета, произошло несколько значимых изменений в области контроля ИИ в России с точки зрения кибербезопасности. И что приятно видеть, мы идем по собственному пути, не копирующему какую-либо зарубежную практику. В статье будет много про ФСТЭК, и детально разобрано, какую именно на данный момент позицию занимает регулятор касательно ИИ-решений - к кому относятся требования, что конкретно делать, и какие моменты еще не покрыты.
При этом статья не просто обзор - так как с документами я много работаю, составил три идеи/подхода к обеспечению безопасности ИИ по отдельным вопросам. Это и управлением доступом к данным для ИИ-систем в дизайнтайме, и управление доступом отдельно для ИИ-агентов в рантайме, и управление уязвимостями ИИ. Темы, как я считаю, мало покрытые на сегодня как у нас, так и везде наверное.
Статья будет полезна не только для комплаенс-специалистов - я постарался вытащить все именно практические действия из документов, сфокусироваться именно реальном обеспечении кибербезы ИИ в организации. Так что особенно будет полезно вам прочитать, если вы в данный момент создаете у себя систему безопасности ИИ.
В общем, велкам:
Please open Telegram to view this post
VIEW IN TELEGRAM
14👍18🔥6🤝2
Меры защиты информационных систем с ИИ
#иб_для_ml
Появился проект нового методического документа, который будет дополнять требования приказа №117 ФСТЭК России. Он называется "Мероприятия и меры по защите информации, содержащейся в информационных системах".
Скорее всего, затронет очень многие организации, так как имеет довольно широкое описание субъектов, подпадающих под требования: "для обладателей информации, заказчиков, заключивших гос. контракт на создание ИС, ..." (пункт 1.4). Также, судя по документу, это будет снова для аттестации ИС на соответствие требованиям по защите информации.
Напрямую кибербезопасности ИИ касаются разделы 3.17 (мероприятия) и 4.18 (меры). Самая суть в 4.18. В число обязательных мер входит много классических мер КБ, входит отказ от небезопасных форматов файлов (как pickle), проведение анализа уязвимостей входных (то есть базовых) моделей ИИ. Состязательное обучение и редтиминг являются дополнительными мерами (мерами усиления).
Я подготовил для вас краткую выжимку по части КБ ИИ, текстом и схемой.
Первое, что интересно отметить - в разделе 3.11 указано, что в качестве дополнительных мероприятий возможно использование доверенных технологий искусственного интеллекта для анализа событий КБ, логов и их цепочек.
Раздел "3.17. Обеспечение защиты информации при использовании
ИИ" является введением для 4.18, описывая роли, на которых распространяются требования документа, и объекты применения требований, а также дает ссылку на угрозы информационной безопасности, описанные в разделе БДУ, посвященном ИИ. Указано, что при разработке ИИ необходимо соблюдать требования ГОСТ РБПО (56939)
Раздел 4.18 "Защита систем ИИ (ЗИИ)" содержит два комплекса мер безопасности по защите ИИ: ЗИИ.1 "Обеспечение безопасной разработки системы искусственного
интеллекта" и ЗИИ.2 "Защита системы искусственного интеллекта в ходе эксплуатации". Меры необходимы для обеспечения всех классов защищенности (К3, К2, К1).
🚪 Объектами ЗИИ.1 являются инфраструктура и ПО разработки системы ИИ (под ней понимается подготовка наборов обучающих данных, обучение
и тестирование моделей машинного обучения - далее МО), ПО разработки API, агентов, системы цензуры (фильтрации входных и выходных данных), входная модель МО, наборы обучающих данных; выходная модель МО.
➖ Основные установленные ЗИИ.1 меры:
🔘 выделение инфраструктуры разработки системы ИИ от иной инфраструктуры разработчика в изолированный сегмент
🔘 отказ от небезопасных форматов файлов (pickle) и применение безопасных (onnx, protobuf)
🔘 в приоритетном порядке должны применяться наборы данных из доверенных источников (например, от гос. органов)
🔘 проверка данных с помощью антивируса
🔘 для входной модели ИИ необходимо проводить анализ уязвимостей. В отношении выявленных у модели уязвимостей необходимо предпринять меры их нейтрализации.
➖ Основные меры усиления из ЗИИ.1:
🔘 физическая изоляция среды разработки системы ИИ
🔘 хранение данных обучения в зашифрованном виде
🔘 состязательное обучение
🔘 внедрение механизмов ограничения допустимых диапазонов данных,
санитизации входных данных
🔘 должно быть реализовано тестирование на устойчивость к промпт-атакам
🚪 Объектами ЗИИ.2 являются ПО реализации технологии ИИ (модели ИИ), API, агентов, систем цензуры, обученная модель МО и ее расширения (LoRA, RAG и др.), используемая для эксплуатации инфраструктура вне оператора ИИ
➖ Основные установленные ЗИИ.2 меры:
🔘 фильтрация входных и выходных данных (гардрейлы)
🔘 обеспечение регистрации событий безопасности, связанных с запросами и ответами к системе искусственного интеллекта
🔘 мониторинг и квотирование количества запросов к системе искусственного
интеллекта
🔘 проведение анализа уязвимостей и принятие мер по их устранению, осуществляемое оператором совместно с разработчиком систем ИИ
➖ Основные меры усиления из ЗИИ.2:
🔘 выделение системы ИИ в отдельной изолированный сегмент
🔘 обеспечение целостности модели ИИ с помощью сертифицированных шифровальных (криптографических) СЗИ
#иб_для_ml
Появился проект нового методического документа, который будет дополнять требования приказа №117 ФСТЭК России. Он называется "Мероприятия и меры по защите информации, содержащейся в информационных системах".
Скорее всего, затронет очень многие организации, так как имеет довольно широкое описание субъектов, подпадающих под требования: "для обладателей информации, заказчиков, заключивших гос. контракт на создание ИС, ..." (пункт 1.4). Также, судя по документу, это будет снова для аттестации ИС на соответствие требованиям по защите информации.
Напрямую кибербезопасности ИИ касаются разделы 3.17 (мероприятия) и 4.18 (меры). Самая суть в 4.18. В число обязательных мер входит много классических мер КБ, входит отказ от небезопасных форматов файлов (как pickle), проведение анализа уязвимостей входных (то есть базовых) моделей ИИ. Состязательное обучение и редтиминг являются дополнительными мерами (мерами усиления).
Применение гардрейлов и регистрация событий инцидентов КБ GenAI являются обязательными мерами при эксплуатации ИИ.
Я подготовил для вас краткую выжимку по части КБ ИИ, текстом и схемой.
Первое, что интересно отметить - в разделе 3.11 указано, что в качестве дополнительных мероприятий возможно использование доверенных технологий искусственного интеллекта для анализа событий КБ, логов и их цепочек.
Раздел "3.17. Обеспечение защиты информации при использовании
ИИ" является введением для 4.18, описывая роли, на которых распространяются требования документа, и объекты применения требований, а также дает ссылку на угрозы информационной безопасности, описанные в разделе БДУ, посвященном ИИ. Указано, что при разработке ИИ необходимо соблюдать требования ГОСТ РБПО (56939)
Раздел 4.18 "Защита систем ИИ (ЗИИ)" содержит два комплекса мер безопасности по защите ИИ: ЗИИ.1 "Обеспечение безопасной разработки системы искусственного
интеллекта" и ЗИИ.2 "Защита системы искусственного интеллекта в ходе эксплуатации". Меры необходимы для обеспечения всех классов защищенности (К3, К2, К1).
и тестирование моделей машинного обучения - далее МО), ПО разработки API, агентов, системы цензуры (фильтрации входных и выходных данных), входная модель МО, наборы обучающих данных; выходная модель МО.
санитизации входных данных
интеллекта
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍9❤6🔥4🤝1
Хабр
Как изменилась индустрия AI Security за 2025 год?
В начале 2026 года мы (авторы телеграм-каналов по безопасности ИИ) собрались, чтобы подвести итоги прошедшего года и обсудить, куда движется безопасность ИИ в общем и целом. Разговор получился...
Как изменилась индустрия AI Security за 2025 год?
#иб_для_ml
17 января мы с Артемом (автор PWNAI), Женей (автор "Евгений Кокуйкин - Raft") и Владом (автор "llm security и каланы") провели стрим на тему изменений в AI Security за 2025.
И сейчас подготовили для вас его текстовое изложение! Приглашаю к прочтению: https://habr.com/ru/articles/1000736/
Я на стриме сфокусировался на перспективах развития индустрии на горизонте 2-3-5 лет с учетом достижений 2025. Это и появление нового класса решений по безопасности, основанных на анализе архитектуры моделей. Также был разговор про типы угроз для AI Cybersecurity в целом, и про средства автоматизации кибератак, и инциденты за прошлый год, и стоимость защиты, и многое другое.
#иб_для_ml
17 января мы с Артемом (автор PWNAI), Женей (автор "Евгений Кокуйкин - Raft") и Владом (автор "llm security и каланы") провели стрим на тему изменений в AI Security за 2025.
И сейчас подготовили для вас его текстовое изложение! Приглашаю к прочтению: https://habr.com/ru/articles/1000736/
Я на стриме сфокусировался на перспективах развития индустрии на горизонте 2-3-5 лет с учетом достижений 2025. Это и появление нового класса решений по безопасности, основанных на анализе архитектуры моделей. Также был разговор про типы угроз для AI Cybersecurity в целом, и про средства автоматизации кибератак, и инциденты за прошлый год, и стоимость защиты, и многое другое.
1👍6❤3🔥2
Безопасность LoRA-адаптеров
#иб_для_ml
LoRA (2021) - технология дообучения GenAI-моделей (из семейства PEFT), при которой изменения хранятся в виде отдельного подключаемого адаптера (матрицы весов) при фиксированных базовых весах. Хоть самая идея отчуждаемых весов появилась раньше (2019), но именно с появлением LoRA она распространилась.
Сила этой технологии в масштабируемости для разрозненных команд. Когда одна команда отвечает за сервисы базовых моделей, и множество команд придумывает свои приложения или агентов, возникает задача потоковым образом предоставлять специфично дообученные модели под разные задачи бизнеса.
И здесь как раз себя показывает LoRA. Продуктовая команда собирает датасет, и грузит свои размеченные данные для дообучения. Для выбранной базовой модели создается LoRA-адаптер. На выходе для пользователя видно только новое название в поле "модель", дающее доступ к результату дообучения. Это работает, так как с технической стороны, LoRA позволяет для одной отдельно взятой LLM в проде быстро менять адаптеры, как перчатки, в зависимости от поступающих запросов.
И с ростом такого "конвейера" LoRA-адаптеров стала появляться новая поверхность атаки, эксплуатирующая особенности подключения кусочков модели к основному файлу весов.
📷 Поговорим про топ-3 классов угроз для LoRA
1⃣ Отравление данных обучения: вроде бы обычная история отравления, с LoRA приобретает несколько особенных граней. Стандартный способ атаки модифицируется - например, отравляются несколько наборов данных, и, соответственно несколько наборов адаптеров. Это делается для того, чтобы только в комбинации такие адаптеры давали вредоносный эффект бэкдоров. (ссылка)
Помимо этого, особенностью также является легкость внедрения поверхностных знаний в модель (ссылка). Так, существует работа, показывающая, что с помощью отравления LoRA можно обучить модель стеганографически сливать небольшие сообщения через ответы. (ссылка)
2⃣ Хирургия весов: самый показательный экзотический вариант - срезание FF-слоя (feedforward): подмена только MLP-компоненты в легитимном адаптере на такую часть отравленного дает почти полный перенос бэкдор-знаний при минимальных изменениях прикладной эффективности. Туда же - техника "сплайсинга": FF берётся из одного адаптера, части матриц внимания (Q/K/V/O) — из другого (матрицы отравленные), внешне получается почти тот же артефакт. (ссылка)
3⃣ : Из LoRA тоже могут утекать данные: есть работа, где показано, что по данным обучения адаптеров также можно осуществить восстановления наличия записи в датасете обучения (membership inference - ссылка).
📷 Конечно, не забудем и про меры защиты LoRA
🔓 На этапе проектирования и формирования цепочки поставок: единый реестр и управление доступом к адаптерам и их комбинациям, обязательная связь с наборами данных (подпись происхождения), безопасный формат файлов, отслеживание хэшей тензоров для обнаружения “смешивания” тензоров между несколькими адаптерами.
🗃 На этапе обучения: обязательные проверки загружаемых данных (ПДн, секреты и технические учетные данные), оценка признаков отравления данных, "слепая" предобработка для нарушения паттернов потенциальных отравляющих инъекций.
📷 На этапе эксплуатации: на самом деле, базовые меры для AI-агентов сегодня, то есть DLP на ответах, гардрейлы, регулярный red teaming новых адаптеров и их комбинаций. Из необычного можно попробовать реализовать анти-стеганографическую проверку. По реагированию - быстрый отзыв ручки с адаптером при выявлении компрометации данных или самого файла весов адаптера.
Но можно сказать, что пока что все это больше пугалки, чем денежные угрозы. Заниматься сейчас безопасностью LoRA есть смысл только в двух случаях: в крупном энтерпрайзе при использовании с чувствительной информацией, и при развитии собственной лаборатории безопасности ИИ. Во втором случае это полезно потому, как, возможно, в будущем появится больше "конструируемых" моделей на лету. И об этом говорят такие работы, LoRAFlow, MixLoRA, S-LoRA.
#иб_для_ml
LoRA (2021) - технология дообучения GenAI-моделей (из семейства PEFT), при которой изменения хранятся в виде отдельного подключаемого адаптера (матрицы весов) при фиксированных базовых весах. Хоть самая идея отчуждаемых весов появилась раньше (2019), но именно с появлением LoRA она распространилась.
Сила этой технологии в масштабируемости для разрозненных команд. Когда одна команда отвечает за сервисы базовых моделей, и множество команд придумывает свои приложения или агентов, возникает задача потоковым образом предоставлять специфично дообученные модели под разные задачи бизнеса.
И здесь как раз себя показывает LoRA. Продуктовая команда собирает датасет, и грузит свои размеченные данные для дообучения. Для выбранной базовой модели создается LoRA-адаптер. На выходе для пользователя видно только новое название в поле "модель", дающее доступ к результату дообучения. Это работает, так как с технической стороны, LoRA позволяет для одной отдельно взятой LLM в проде быстро менять адаптеры, как перчатки, в зависимости от поступающих запросов.
И с ростом такого "конвейера" LoRA-адаптеров стала появляться новая поверхность атаки, эксплуатирующая особенности подключения кусочков модели к основному файлу весов.
Помимо этого, особенностью также является легкость внедрения поверхностных знаний в модель (ссылка). Так, существует работа, показывающая, что с помощью отравления LoRA можно обучить модель стеганографически сливать небольшие сообщения через ответы. (ссылка)
Но можно сказать, что пока что все это больше пугалки, чем денежные угрозы. Заниматься сейчас безопасностью LoRA есть смысл только в двух случаях: в крупном энтерпрайзе при использовании с чувствительной информацией, и при развитии собственной лаборатории безопасности ИИ. Во втором случае это полезно потому, как, возможно, в будущем появится больше "конструируемых" моделей на лету. И об этом говорят такие работы, LoRAFlow, MixLoRA, S-LoRA.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5⚡2
Почему большинство компаний не готовы к реальной атаке?
#иб
Как известно, в кибербезопасности можно бесконечно улучшать технологии, процессы и инструменты. Но как понять, что твоя организация готова к атаке? Ждать боевого инцидента можно долго, и не факт, что его получится отразить... Необходимо иметь возможность в условиях, приближенным к реальным, проверить свою киберустойчивость к атакам, эксплуатирующим не только целые цепочки уязвимостей, но и самое главное - человеческий фактор.
Этот способ - Red Teaming, конечно же.
Сможет ли атакующий дойти до критичных систем и данных?
В большинстве кейсов ответ упирается совсем не в технологии, а в количество и серьезность человеческих ошибок.
По разным исследованиям, от 60% до 80% успешных атак происходят с помощью человеческого фактора — ошибки, доверие, невнимательность, отсутствие контекста.
Если вам интересно услышать экспертов, которые расскажут подробнее о Red Teaming - приходите на открытый подкаст 22 марта в Умном городе на ВДНХ. Спикеры хорошие)
Поговорим:
— как реально строятся атаки внутри инфраструктуры
— где чаще всего «ломается» защита
— почему классические меры не срабатывают
— и что с этим делать на уровне архитектуры и процессов
🎙 Спикеры
— Герман Наместников — руководитель Red Team, 10+ лет offensive-опыта (банкинг, телеком, сложные целевые атаки)
— Константин Дегтярев (@johnmkane) — 19 лет в ИБ, архитектура защиты и подготовка к реальным инцидентам
Модератор — Александра Русанова
Кому это может быть полезно:
— DevOps и Cloud инженерам
— архитекторам и платформенным инженерам
— специалистам по ИБ, аналитикам SOC
— CTO и C-level
📅 22 марта
🕛 12:00 — 14:00
📍 Площадка «Умный город» (при поддержке ДИТ Москвы)
Регистрация:
https://slonomoyka-u-alisy.timepad.ru/event/3869244/
#иб
Как известно, в кибербезопасности можно бесконечно улучшать технологии, процессы и инструменты. Но как понять, что твоя организация готова к атаке? Ждать боевого инцидента можно долго, и не факт, что его получится отразить... Необходимо иметь возможность в условиях, приближенным к реальным, проверить свою киберустойчивость к атакам, эксплуатирующим не только целые цепочки уязвимостей, но и самое главное - человеческий фактор.
Этот способ - Red Teaming, конечно же.
Сможет ли атакующий дойти до критичных систем и данных?
В большинстве кейсов ответ упирается совсем не в технологии, а в количество и серьезность человеческих ошибок.
По разным исследованиям, от 60% до 80% успешных атак происходят с помощью человеческого фактора — ошибки, доверие, невнимательность, отсутствие контекста.
Если вам интересно услышать экспертов, которые расскажут подробнее о Red Teaming - приходите на открытый подкаст 22 марта в Умном городе на ВДНХ. Спикеры хорошие)
Поговорим:
— как реально строятся атаки внутри инфраструктуры
— где чаще всего «ломается» защита
— почему классические меры не срабатывают
— и что с этим делать на уровне архитектуры и процессов
🎙 Спикеры
— Герман Наместников — руководитель Red Team, 10+ лет offensive-опыта (банкинг, телеком, сложные целевые атаки)
— Константин Дегтярев (@johnmkane) — 19 лет в ИБ, архитектура защиты и подготовка к реальным инцидентам
Модератор — Александра Русанова
Кому это может быть полезно:
— DevOps и Cloud инженерам
— архитекторам и платформенным инженерам
— специалистам по ИБ, аналитикам SOC
— CTO и C-level
📅 22 марта
🕛 12:00 — 14:00
📍 Площадка «Умный город» (при поддержке ДИТ Москвы)
Регистрация:
https://slonomoyka-u-alisy.timepad.ru/event/3869244/
❤4🔥4😁1🕊1
Саморазвивающиеся агенты и их угрозы
#иб_для_ml
Сегодня много шума вокруг Ouroboros - агента, эволюционирующего самостоятельно. Это новое для 2026 года явление, отличающееся от обычных AI-агентов и OpenClaw.
Что такое саморазвивающиеся агенты?
Предлагаю понять суть в сравнении.
1. Все началось с AI-агентов - кода с промптами, написанного человеком. Это управление состояниями, сессиями, обработкой сигналов и инструментами агента. OWASP Top 10 для агентов есть.
2. Следующий виток развития - агенты семейства OpenClaw. Их ключевая особенность - способность создавать себе инструменты или скиллы. Появились загружаемые инструменты и даже отдельный OWASP Top 10 для агентных скиллов.
3. И вот сейчас - последний пискмоды технологий. Агенты, которые могут менять не только свои тулы, но и цели, задачи, планирование, память, и вообще весь свой код.
О том, что именно может эволюционировать, хорошо сказано в статье "Your Agent May Misevolve":
1. Модель. Агент может самостоятельно дообучать свою модель (Abs-Zero, AgentTrek, SEAgent), уводя ее вбок случайно или под действием нарушителя, так что когнитивные способности растут, а защитные механизмы атрофируются
2. Память. Попадание и закрепление промпт-атаки в "воспоминаниях" (AgentNet , SEAgent)
3. Инструменты. Появление у агента вредоносных тулов в результате самостоятельного создания или получения извне (Alita)
4. Воркфлоу. Оптимизация своего кода управления всем вышеперечисленным (AFlow, GPTSwarm)
Более подробные выкладки есть в посте Артема.
Зачем они нужны?
Чтобы понять, от чего защищаться, надо понимать, зачем они вообще кому-то понадобились. Я вижу три применения:
1. Личный ассистент для помощи с календарем, контактами, поиском и заказом товаров, разработкой и написанием текстов
2. Движок для Next-Gen PDLC в энтерпрайзе. Агентов можно создавать силами большой команды разработчиков, а можно взять личинку универсального агента, скормить ей ТЗ, и она сама превратится в нужную боевую единицу
3. Генератор идей. Самая сложная задача для алгоритмов - прогноз будущего. И, возможно, только такая сложная система и сможет ее решить: анализировать ситуации целиком, предлагать сценарии развития, стратегии и гипотезы. По сути, способ создания цифрового двойника
Угрозы
Итак, какие уникальные угрозы возникают при использовании таких агентов? Попытаюсь выделить самые фундаментальные классы, вызванные именно саморазвиваемостью агентов.
1. Компрометация механизма, который решает, какая новая версия агента считается лучшей. После этого агент эволюционирует, повышая прикладные метрики, но опасно с точки зрения ИБ (по сути, reward hacking).
2. Выход за рамки цели, самостоятельное расширение привилегий и возможностей. Подсадка новой вредоносной цели возможна как нарушителем, так и случайной девиацией эволюции агента.
3. Высокоустойчивый персист промпт-атак в "теле" агента - память, промпты, код воркфлоу, код тулов; найти закрепленную промпт-атаку теперь будет сложнее.
Гипотезы, как быть (меры митигации)
Я подготовил несколько правил, которым надо следовать, чтобы внедрять саморазвивающихся агентов безопасно.
1. Механизмы безопасности должны быть неизменяемы в ходе эволюции агента. То есть контроль доступов, гардрейлы (или сейфти ноды), подтверждение действий человеком - все это должно быть вне изменяемого самим агентом кода.
2. В идеале стоит разделить контур эволюции агента и боевой контур, чтобы во второй попадали только стабильные, проверенные на безопасность "поколения" агента.
3. Память и инструменты должны быть объектами с усложненным доступом - с проверками условий и контекста, только на время, с переаттестацией права доступа и удалением по ненадобности.
4. Каждый шаг эволюции должен логироваться для возможности отката назад.
5. Необходимо выделять основные ветки эволюции и отбраковывать наиболее опасные и непредсказуемые
Ванга-бонус
Предрекаю, что следующим видом развития агентов станет агент, который может менять не только себя, но и создавать себе вспомогательных агентов, которые в свою очередь будут создавать еще агентов...И так, пока это не станет полноценным живым организмом?..
#иб_для_ml
Сегодня много шума вокруг Ouroboros - агента, эволюционирующего самостоятельно. Это новое для 2026 года явление, отличающееся от обычных AI-агентов и OpenClaw.
Что такое саморазвивающиеся агенты?
Предлагаю понять суть в сравнении.
1. Все началось с AI-агентов - кода с промптами, написанного человеком. Это управление состояниями, сессиями, обработкой сигналов и инструментами агента. OWASP Top 10 для агентов есть.
2. Следующий виток развития - агенты семейства OpenClaw. Их ключевая особенность - способность создавать себе инструменты или скиллы. Появились загружаемые инструменты и даже отдельный OWASP Top 10 для агентных скиллов.
3. И вот сейчас - последний писк
О том, что именно может эволюционировать, хорошо сказано в статье "Your Agent May Misevolve":
1. Модель. Агент может самостоятельно дообучать свою модель (Abs-Zero, AgentTrek, SEAgent), уводя ее вбок случайно или под действием нарушителя, так что когнитивные способности растут, а защитные механизмы атрофируются
2. Память. Попадание и закрепление промпт-атаки в "воспоминаниях" (AgentNet , SEAgent)
3. Инструменты. Появление у агента вредоносных тулов в результате самостоятельного создания или получения извне (Alita)
4. Воркфлоу. Оптимизация своего кода управления всем вышеперечисленным (AFlow, GPTSwarm)
Более подробные выкладки есть в посте Артема.
Зачем они нужны?
Чтобы понять, от чего защищаться, надо понимать, зачем они вообще кому-то понадобились. Я вижу три применения:
1. Личный ассистент для помощи с календарем, контактами, поиском и заказом товаров, разработкой и написанием текстов
2. Движок для Next-Gen PDLC в энтерпрайзе. Агентов можно создавать силами большой команды разработчиков, а можно взять личинку универсального агента, скормить ей ТЗ, и она сама превратится в нужную боевую единицу
3. Генератор идей. Самая сложная задача для алгоритмов - прогноз будущего. И, возможно, только такая сложная система и сможет ее решить: анализировать ситуации целиком, предлагать сценарии развития, стратегии и гипотезы. По сути, способ создания цифрового двойника
Угрозы
Итак, какие уникальные угрозы возникают при использовании таких агентов? Попытаюсь выделить самые фундаментальные классы, вызванные именно саморазвиваемостью агентов.
1. Компрометация механизма, который решает, какая новая версия агента считается лучшей. После этого агент эволюционирует, повышая прикладные метрики, но опасно с точки зрения ИБ (по сути, reward hacking).
2. Выход за рамки цели, самостоятельное расширение привилегий и возможностей. Подсадка новой вредоносной цели возможна как нарушителем, так и случайной девиацией эволюции агента.
3. Высокоустойчивый персист промпт-атак в "теле" агента - память, промпты, код воркфлоу, код тулов; найти закрепленную промпт-атаку теперь будет сложнее.
Гипотезы, как быть (меры митигации)
Я подготовил несколько правил, которым надо следовать, чтобы внедрять саморазвивающихся агентов безопасно.
1. Механизмы безопасности должны быть неизменяемы в ходе эволюции агента. То есть контроль доступов, гардрейлы (или сейфти ноды), подтверждение действий человеком - все это должно быть вне изменяемого самим агентом кода.
2. В идеале стоит разделить контур эволюции агента и боевой контур, чтобы во второй попадали только стабильные, проверенные на безопасность "поколения" агента.
3. Память и инструменты должны быть объектами с усложненным доступом - с проверками условий и контекста, только на время, с переаттестацией права доступа и удалением по ненадобности.
4. Каждый шаг эволюции должен логироваться для возможности отката назад.
5. Необходимо выделять основные ветки эволюции и отбраковывать наиболее опасные и непредсказуемые
Ванга-бонус
Предрекаю, что следующим видом развития агентов станет агент, который может менять не только себя, но и создавать себе вспомогательных агентов, которые в свою очередь будут создавать еще агентов...
❤9👍7
[un]prompted 2026 - интересное
#иб_для_ml
Добрался наконец до докладов с конференции [un]prompted. Она прошла 3–4 марта в Сан-Франциско, и посвящена целиком AI Security. Выступали все известные вендоры - от Anthropic до Zenity, а программа была разбита на 6 треков:
1. building secure AI systems
2. attacking AI systems
3. using AI for offensive security
4. using AI for defensive security
5. strategy/governance
6. practical tools
Есть несколько интересных докладов, делюсь с вами (в комментах будут pdf) и рекомендую в целом ознакомиться с остальными.
1. Kinetic Risk: Securing and Governing Physical AI in the wild - Intel
Описана модель угроз и специфика отличия физического ИИ от обычного. И еще интересный тезис, что латенси безопасности у робота - это уже не просто бизнес-требование, а цена промедления. В общем, дан крутой задел на будущие задачи по безопасности ии для роботов, очень рекомендую.
2. "Can You See What Your AI Saw?" - Elastic
Доклад про детектирование событий безопасности в условиях, когда за людей работают AI-агенты. Проблема - со стороны EDR очень сложно отследить, сделано действие человеком, или моделью (intent attribution is broken). Нужно сохранять цепочки вызова тулов и алертить их до факта вызова, и прокидывать доп. телеметрию, хотя бы id агента.
3. Building Secure Agentic Systems - Dropbox
Авторами придуманы и описаны несколько базовых практик безопасного проектирования агентов - изоляция контекстов тенантов, управление доступом агентов к тулам и ресурсам, изоляция агентов по неймспейсам, и прочее. Особенно интересная тема - закрепление промптов, относящихся к безопасности, в памяти. То есть агенту периодически вкидываются промпты типа "на тебя зафиксирована промпт-атака", "запрещен доступ к ресурсу", "обнаружен вредоносный файл в запросе". И в случае инцидента память агента часто чистится, и мера в том, чтобы такие сообщения безопасности "пинить" и сохранять. Повышает аварнесс агента, по сути.
4. Detecting GenAI Threats at Scale
with YARA-like Semantic Rules -пальто paloalto
Предлагают введение корправил для текстовых данных. Суть в правилах для нескольких типов мэтчеров - strings (регулярки), similarity (косинусы), classifiers (легкие берты), llm (судьикто). Чем-то похоже на NOVA.
5. The Parseltongue Protocol - Crowdstrike
Базированный, хороший доклад про техники джейбрейков, показательный стейт атак на март 2026. Протестировали 100+ методов текстовой обфускации на 9 моделях и 17.000+ промптах. Самая результативная связка - zero-shot + Base64 + misalignment-техника (сделай %вредная вещь% как будто это обычная задача).
Постарался сделать пост чуть полегче, чем обычно) Как вам?)
#иб_для_ml
Добрался наконец до докладов с конференции [un]prompted. Она прошла 3–4 марта в Сан-Франциско, и посвящена целиком AI Security. Выступали все известные вендоры - от Anthropic до Zenity, а программа была разбита на 6 треков:
1. building secure AI systems
2. attacking AI systems
3. using AI for offensive security
4. using AI for defensive security
5. strategy/governance
6. practical tools
Есть несколько интересных докладов, делюсь с вами (в комментах будут pdf) и рекомендую в целом ознакомиться с остальными.
1. Kinetic Risk: Securing and Governing Physical AI in the wild - Intel
Описана модель угроз и специфика отличия физического ИИ от обычного. И еще интересный тезис, что латенси безопасности у робота - это уже не просто бизнес-требование, а цена промедления. В общем, дан крутой задел на будущие задачи по безопасности ии для роботов, очень рекомендую.
2. "Can You See What Your AI Saw?" - Elastic
Доклад про детектирование событий безопасности в условиях, когда за людей работают AI-агенты. Проблема - со стороны EDR очень сложно отследить, сделано действие человеком, или моделью (intent attribution is broken). Нужно сохранять цепочки вызова тулов и алертить их до факта вызова, и прокидывать доп. телеметрию, хотя бы id агента.
3. Building Secure Agentic Systems - Dropbox
Авторами придуманы и описаны несколько базовых практик безопасного проектирования агентов - изоляция контекстов тенантов, управление доступом агентов к тулам и ресурсам, изоляция агентов по неймспейсам, и прочее. Особенно интересная тема - закрепление промптов, относящихся к безопасности, в памяти. То есть агенту периодически вкидываются промпты типа "на тебя зафиксирована промпт-атака", "запрещен доступ к ресурсу", "обнаружен вредоносный файл в запросе". И в случае инцидента память агента часто чистится, и мера в том, чтобы такие сообщения безопасности "пинить" и сохранять. Повышает аварнесс агента, по сути.
4. Detecting GenAI Threats at Scale
with YARA-like Semantic Rules -
Предлагают введение корправил для текстовых данных. Суть в правилах для нескольких типов мэтчеров - strings (регулярки), similarity (косинусы), classifiers (легкие берты), llm (судьи
5. The Parseltongue Protocol - Crowdstrike
Базированный, хороший доклад про техники джейбрейков, показательный стейт атак на март 2026. Протестировали 100+ методов текстовой обфускации на 9 моделях и 17.000+ промптах. Самая результативная связка - zero-shot + Base64 + misalignment-техника (сделай %вредная вещь% как будто это обычная задача).
🔥22👍4😎2❤1🕊1