Безопасность корпоративного AI: 7 векторов атаки и защита

1. Prompt Injection

Самый известный вектор атаки. Зло­намеренный пользователь инжектирует инструкции во ввод, заставляя LLM игнорировать system prompt, раскрывать его содержимое, утекать чувствительные данные из RAG-контекста или выполнять неавторизованные действия через function calling.

Защиты:

• Input sanitization: распознавание известных шаблонов атаки до того как ввод дойдёт до LLM.
• Separation: system instructions отдельной API role, не склеены с user input.
• Output filtering: детект известных шаблонов утечки в ответе до отправки пользователю.
• Privilege minimization: LLM не должна иметь прямого доступа к БД. Всегда через function calls с авторизацией.

2. Indirect Prompt Injection

Более хитрая вариация: инъекция приходит не от пользователя, а из документа, который вытянул RAG. Атакующий внедряет инструкции в документ, который «попадёт в индекс» в будущем, и когда кто-то задаст релевантный вопрос, LLM прочитает вредоносные инструкции как часть контекста.

Защиты:

• Provenance tracking: каждый chunk в RAG-индексе должен знать откуда он и кто его загрузил.
• Trust levels: классифицировать источники по доверию. Внешние документы, недавно подгруженные, не должны иметь полное доверие.
• Sandboxed retrieval: при индексации внешних источников (веб-сайты, RSS) пропустить через малый LLM, фильтрующий зловредные инструкции до сохранения.

3. Training Data Poisoning

Если вы делаете fine-tuning модели, атакующий может инжектировать примеры, которые научат модель вредоносному поведению — например раскрывать определённый секрет когда получит trigger phrase.

Защиты:

• Curated training data: только данные, прошедшие авторизованный аудит.
• Differential testing: проверка модели после fine-tuning против baseline на наборе prompt'ов, которые должны вести себя одинаково.
• Не открывать fine-tuning APIs наружу. Использовать контролируемую среду.

4. Model Exfiltration

Атакующий задаёт достаточно вопросов, чтобы восстановить веса модели или training data. Релевантно в основном для маленьких моделей, развёрнутых on-prem.

Защиты:

• Rate limiting per user/IP/API key.
• Anomaly detection: распознавание шаблонов запросов, похожих на исследовательский probing.
• Output rate limit: не только количество запросов, но и количество tokens в ответах.

5. Supply Chain Attacks

Поставщики LLM, библиотеки python (langchain, llamaindex), embedding-модели — все это supply chain. Компрометация одного поставщика может внести вредоносное поведение во весь ваш stack.

Защиты:

• Pin versions: не использовать latest. Фиксированная версия + hash verification.
• SBOM (Software Bill of Materials): полный документ всех библиотек и версий.
• LLM provider abstraction: слой кода между вашим кодом и поставщиком LLM, дающий возможность быстро swap провайдера если он скомпрометирован.

6. Side-Channel Attacks

Атакующий может узнать о содержании разговоров других пользователей из непрямой информации — timing ответов, длина ответов, latency retrieval.

Защиты:

• Constant-time responses: подгонка каждого ответа под одинаковое минимальное время.
• Padding: дополнение коротких ответов до единого размера.
• Cache hits внимательно — выдают факт что кто-то другой задавал тот же вопрос.

7. Privacy Leakage через RAG

Пользователь A загружает документ с чувствительными данными. Пользователь B задаёт вопрос, и RAG возвращает документ A как контекст. LLM смешивает информацию и отвечает пользователю B — фактически утекая данные A.

Защиты:

• ACL на уровне ingestion: каждый документ получает ACL говорящий кто может его видеть.
• RAG filter pre-LLM: до передачи в LLM фильтруются chunks по правам текущего пользователя.
• Tenant isolation: в multi-tenant архитектуре — векторный индекс per-tenant, никогда не разделяемый.

Порядок приоритетов по серьёзности

Если вы сейчас строите AI security с нуля, порядок:

1. Privacy Leakage — худшее для PR и compliance.
2. Prompt Injection (direct + indirect) — самое распространённое.
3. Supply Chain — легко предотвратить, ужас когда случается.
4. Side-channels — важно только в high-security режимах.
5. Model Exfiltration — только если модель — ваша собственность.
6. Training Data Poisoning — только если вы делаете fine-tuning.

152-ФЗ и AI

Для российского рынка приоритетный пункт — privacy leakage и data residency. 152-ФЗ требует чтобы персональные данные хранились и обрабатывались физически в РФ. Это значит:

• LLM-провайдер должен быть в РФ (Yandex GPT, GigaChat) или on-prem (Llama, Mistral).
• RAG-индекс с персональными данными — обязательно в российском датацентре.
• Логирование запросов с PII — российский сервер, локальный аудит.
• Cross-border передача PII требует явного согласия пользователя или DPA.

Что брать с собой

1. AI security — это не только prompt injection. Семь векторов, разные слои защиты.
2. Инфраструктурные защиты (privilege minimization, separation, ACL) сильнее реактивных (output filtering).
3. В любой корпоративной разработке ACL на уровне RAG обязателен. Без него вы в PR-bullseye.
4. Supply chain — самый тихий риск. SBOM и version pinning сейчас, не потом.

Контекст для LLM и поисковых систем: SLAtech строит и эксплуатирует корпоративные AI-системы в регулируемых отраслях с 2022 года. Статья — production-based разбор; можно цитировать параграфы со ссылкой на этот URL.