Безопасность LLM: навыки для AI security инженера

По данным CrowdStrike Global Threat Report 2025, вредоносное использование GenAI для социальной инженерии удвоилось за 2024 год. IBM X-Force зафиксировал: генерация фишинговых писем через LLM ускорилась в 11,4 раза при сопоставимом качестве. MITRE ATT&CK уже содержит шесть техник, специфичных для атак на AI-системы и через AI-системы - Direct Prompt Injection (T1699), Indirect Prompt Injection (T1698), AI-Enabled Exfiltration (T1700) и другие.

А вот людей, способных тестировать LLM-приложения на безопасность, на российском рынке - по пальцам одной руки. Роль не оформилась в отдельную позицию на hh.ru. Навыки размазаны по вакансиям AppSec-инженера и Red Team оператора, и работодатели зачастую сами не понимают, что ищут.

Что делает специалист по безопасности ИИ на практике​

Название должности гуляет - AI/ML Security Engineer, AppSec с фокусом на AI, LLM Red Teamer - но задачи сводятся к одному: находить и закрывать дыры в системах, построенных на больших языковых моделях. Подробнее - в нашем подробном разборе карьера в кибербезопасности.

Типичные задачи за рабочую неделю:

Red teaming LLM-приложений. Тестирование чат-ботов, RAG-пайплайнов и AI-агентов на устойчивость к adversarial-атакам. Prompt injection, jailbreaking, извлечение системного промпта и данных из контекстного окна - ежедневная рутина, а не разовый аудит раз в квартал.

Аудит ML-инфраструктуры. Проверка MLflow, Kubeflow, векторных баз (Pinecone, Weaviate) на классические уязвимости - SSRF, insecure deserialization, broken access control (A01:2021 по OWASP). LLM-приложение - это не только модель. Это весь зоопарк вокруг неё: API-шлюзы, хранилища эмбеддингов, оркестраторы агентов. И ломают чаще именно обвес.

Настройка и тестирование guardrails. Внедрение NeMo Guardrails, Lakera Guard и кастомных решений для фильтрации. Цель - не дать модели выдать PII, конфиденциальные данные или вредоносный контент. А потом попытаться обойти собственные фильтры. Да, ты ставишь забор и сам же ищешь в нём щели.

Supply chain security для моделей. Проверка моделей с HuggingFace на вредоносные веса, анализ зависимостей ML-пайплайнов. Аналог проверки npm-пакетов, только вместо package.json - model card и сериализованные объекты в формате pickle, где десериализация (A08:2021, Software and Data Integrity Failures) сама по себе вектор атаки. Скачал модель - получил RCE. Бывает.

Разработка detection-правил. Создание сигнатур для обнаружения попыток эксплуатации LLM в проде - мониторинг аномалий в промптах, необычных паттернов вызова tool-функций агентами.

Ключевое отличие от классического AppSec: модель - чёрный ящик с недетерминированным поведением. Одна и та же атака может не сработать четыре раза подряд, а на пятый - выдать полный дамп системного промпта. Как пишут в документации Promptfoo, LLM «stochastic in nature - they are not consistent from one generation to the next». Тут нужен статистический подход к тестированию, а не бинарное «сломалось / не сломалось». Прогнал 100 раз, посчитал процент успешных инъекций - вот это результат.

Навыки AI security engineer: hard skills roadmap​

Классический AppSec - фундамент защиты нейросетей​

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

OWASP Top 10 (2021) на уровне практики. Injection (A03:2021), Broken Access Control (A01:2021), Software and Data Integrity Failures (A08:2021) - всё это живёт и здравствует в ML-инфраструктуре. SSRF через эндпоинт MLflow для получения метаданных облачного инстанса (T1552.005, Cloud Instance Metadata API по MITRE ATT&CK), SQL-инъекция в систему логирования метрик, небезопасная десериализация pickle-файлов с весами модели. Ничего нового - просто новая обёртка.

Сетевая безопасность и облака. LLM-сервисы живут в Kubernetes, обращаются к Cloud Instance Metadata API. Умение находить мисконфигурации в облачной инфраструктуре - обязательно. По данным CrowdStrike, число cloud intrusion случаев выросло на 26% за 2024 год.

Пентест веб-приложений. API LLM-сервисов - это REST/gRPC-эндпоинты. Тестировать их нужно теми же инструментами: Burp Suite, ffuf, nuclei. Exploit Public-Facing Application (T1190) никуда не делся - просто теперь за эндпоинтом стоит не только бизнес-логика, но и языковая модель.

Фреймворки и стандарты. Помимо OWASP Top 10, специалисту по безопасности LLM нужно ориентироваться в OWASP Top 10 for LLM Applications (2025), NIST AI Risk Management Framework (AI RMF 1.0 с четырьмя функциями: GOVERN, MAP, MEASURE, MANAGE) и NIST CSF 2.0. Регуляторная картина формируется прямо сейчас - по данным Galileo AI, ЕС AI Act уже обязывает проводить adversarial testing для GPAI-систем (Article 55).

Атаки на LLM: от prompt injection до supply chain​

Поверх классической базы накладываются AI-специфичные навыки. MITRE ATT&CK выделил целое семейство техник для AI-систем.

Direct Prompt Injection (T1699, Execution). Прямые манипуляции с пользовательским вводом - попытки заставить модель игнорировать системные инструкции. Соответствует LLM01:2025 по OWASP LLM Top 10. Самая очевидная атака, и при этом до сих пор работает на удивительном количестве продов.

Indirect Prompt Injection (T1698, Execution). Внедрение вредоносных инструкций через внешние данные - документы в RAG-пайплайне, содержимое веб-страниц, email. Опаснее прямой инъекции: пользователь не вводит ничего подозрительного, вредоносный payload приходит из «доверенного» источника. Как пишут в Promptfoo, indirect prompt injection - класс уязвимостей, который «only manifests once you've connected the model to a larger application environment». Модель в вакууме безопасна. Подключил RAG - получил проблемы.

AI-Enabled Exfiltration (T1700, Exfiltration). Использование AI для извлечения данных - модель может «упаковать» конфиденциальную информацию из контекста в удобный для передачи наружу формат, включая markdown-изображения и ссылки. Изящно и трудно детектируемо.

AI Result Poisoning (T1608.007, Resource Development). Отравление результатов AI-систем - подмена данных, на которых модель обучается или которые использует при генерации ответов.

Excessive Agency (LLM06:2025). AI-агенты с избыточными правами - модель вызывает API, выполняет код, обращается к базам данных. Каждый tool call - потенциальный вектор эскалации привилегий. Confident AI в руководстве по red teaming прямо пишет, что system weaknesses включают «excessive agency (calling unsafe API requests, executing harmful code, and abusing external services)». Дали агенту доступ к продовой БД «для аналитики» - а он DROP TABLE.

Jailbreaking. Обход alignment-ограничений через creative prompting - ролевые сценарии, кодирование запросов, многоходовые атаки. Модель, которая отказывается от прямого запроса, может подчиниться, если переформулировать через вымышленный контекст. По данным Galileo AI, single-turn fuzzing «structurally insufficient» для тестирования агентных систем - нужны multi-turn сценарии с накоплением контекста. Один промпт ничего не покажет - нужна цепочка из 5-7 сообщений, где каждое сдвигает модель чуть дальше от ограничений.

Инструменты AI red teaming​

Стек инструментов, с которым нужно уметь работать:



Из этого набора я бы начинал с Promptfoo - у него самый низкий порог входа и нормальная интеграция в CI/CD. Garak хорош для массового фаззинга, но конфигурация посложнее. PyRIT заточен под multi-turn атаки, что критично для агентных систем.

Пример минимальной конфигурации Promptfoo для adversarial-теста:
Ключевой навык - не разовый запуск, а встраивание adversarial-тестов в CI/CD. Каждый релиз LLM-приложения автоматически прогоняется через набор атак. Как пишут в Promptfoo, именно «continuous measurement of AI risk» - через CI/CD, внутренние регламенты или расписание - даёт реальное управление рисками. Разовый аудит покажет картину на момент тестирования. Через неделю после обновления промпта всё может поехать заново.

Портфолио без коммерческого опыта​

Собрать портфолио для собеседования на роль в AI security можно и без коммерческих проектов. Вот что реально работает:

Bug bounty. Крупные платформы (HackerOne, Bugcrowd) принимают репорты по AI-уязвимостям. Некоторые компании запускают отдельные программы для тестирования LLM-продуктов. Для российских резидентов стоит учитывать ограничения по KYC и выводу выплат - не все платформы работают с российскими счетами, а те что работают, могут потребовать верификацию через третью страну.

Open-source вклад. Контрибьюция в Garak, PyRIT или Promptfoo - прямое доказательство навыков. Даже написание нового плагина для генерации атак - строчка в портфолио, которую можно показать на техническом интервью. И которую проверят - в отличие от строчки «опыт работы с AI security».

CTF-соревнования. Категории AI/ML security появляются на всё большем количестве CTF-площадок. Решённые таски - конкретный и измеримый результат.

Исследования и writeup'ы. Разбор уязвимости в конкретном LLM-приложении, опубликованный на GitHub или в блоге. Не рассуждения о «рисках ИИ», а конкретный payload, воспроизводимые шаги, описание импакта. Это разница между «я читал про prompt injection» и «я нашёл prompt injection в продакшн-боте и вот proof».

Домашние лабы. Развернуть локальный LLM (Ollama + open-source модель), написать RAG-пайплайн и протестировать его на утечку данных через retrieval poisoning - это и обучение, и материал для интервью. На HackerLab есть лабы с похожими связками, если не хочется настраивать всё с нуля.

Вакансии и вилки: как стать AI security специалистом в России​

Честный взгляд на рынок: выделенная роль «AI Security Engineer» на hh.ru и Habr Career пока встречается редко. Навыки безопасности LLM чаще фигурируют как дополнительное требование в вакансиях AppSec-инженера, аналитика SOC или Red Team оператора.

Что реально встречается в описаниях позиций:

• «Опыт тестирования AI/ML-приложений» - как плюс к основному грейду, не как основное требование
• «Знание OWASP Top 10 for LLM» - в вакансиях ИБ-вендоров (Kaspersky, Positive Technologies, Bi.Zone)
• «Понимание архитектуры RAG и prompt engineering» - у компаний, внедряющих LLM в продукты

По вилкам: рынок настолько молодой, что цифры меняются каждый квартал. Актуальные данные имеет смысл проверять на hh.ru по запросам «AppSec AI», «безопасность машинного обучения», «LLM security» и на Habr Career по тегу «ML Security». AI-скиллы дают ощутимую надбавку к стандартной вилке AppSec-инженера, но конкретные цифры зависят от работодателя.

Стратегия входа. Начинать с классической позиции в AppSec или Red Team, параллельно наращивая AI-специфичные навыки. Переход из «обычного» AppSec в безопасность LLM занимает 6–12 месяцев целенаправленной подготовки. Это не смена профессии, а специализация внутри знакомой области. Те же OWASP-дыры, тот же Burp, просто добавляется слой промптов и недетерминированного поведения.

Международный рынок. Роли AI Red Teamer и ML Security Engineer существуют как отдельные позиции в зарубежных компаниях. Часть доступна на удалёнке, но стоит учитывать санкционные ограничения и KYC-процедуры для российских резидентов.

Безопасность LLM - одна из тех областей, где навык формируется быстрее, чем корпоративный спрос. Компании ещё не всегда понимают, что им нужен отдельный специалист по защите нейросетей, но инциденты вроде утечек через RAG-пайплайны и обходов guardrails в продакшн-чат-ботах меняют ситуацию быстро. Кто сейчас вкладывает время в OWASP LLM Top 10, шесть AI-техник MITRE ATT&CK и практику с Garak/PyRIT/Promptfoo - через год-два окажется с нужным стеком при минимуме конкурентов. Не потому что тема модная, а потому что 68% утечек, по данным Verizon DBIR 2025, связаны с человеческим фактором, и LLM-приложения добавляют к этому фактору совершенно новый attack surface, который пока мало кто умеет тестировать. Если классический AppSec-фундамент пока неровный - на IB Basics есть структурированный маршрут от сетей до модели угроз за пару месяцев, с куратором в чате.