Что такое безопасность LLM? Как снизить риски безопасности из OWASP Top 10

Атака, при которой ИИ обманом заставляют принимать инструкции злоумышленника за команды, — промпт-инъекция — занимает первое место в списке OWASP Top 10 for LLM Applications во всех редакциях начиная с 2023 года.

Этот список — пожалуй, самое близкое к консенсусу, что есть в сфере безопасности ИИ. Проект начинался с небольшой группы специалистов по безопасности, а сегодня в нем участвуют свыше 600 экспертов из более чем 18 стран.

Мы — ИИ-компания, которая публикует руководство о том, как ИИ уговаривают на что угодно, поэтому не станем делать вид, что проблема решена. Уилсон, один из руководителей проекта OWASP, вполне однозначно высказался о текущих средствах защиты: «...честно говоря, не думаю, что мы достигли 99%».

Редакция 2026 года начинается с той же мысли. Руководитель проекта призывает нас «перестать пытаться создать модель, которую невозможно обмануть» и проектировать окружающую систему так, чтобы обманутая модель не могла сломать ничего важного.

Этого подхода мы придерживаемся при разборе всех 10 рисков из списка OWASP 2026 года.

Что такое безопасность LLM?

Безопасность LLM — это защита ИИ-моделей и использующих их приложений от атак и злоупотреблений. Риск растет в зависимости от того, к чему подключена модель: какие файлы и данные она может читать и какими инструментами может пользоваться, например электронной почтой, поиском или корпоративной базой данных.

В надежно защищенном программном обеспечении существует четкая граница между инструкциями, которые выполняет программа, и информацией, которую она обрабатывает. Но у LLM такой границы нет.

Все, что читает модель, поступает к ней единым длинным потоком текста: инструкции разработчика, ваш вопрос, найденная ею веб-страница. ИИ-модели должны отслеживать, кто говорит: разработчик, пользователь или сама модель, размышляющая над задачей.

Однако исследователи Жасмин Цуй и Чарльз Йе выяснили, что модели в основном угадывают, кто говорит, по тому, как звучит текст. Поэтому если злоумышленник напишет что-то похожее на собственные рассуждения модели, она может поверить, что сама пришла к этой идее. Это проблема для любой системы защиты, которая полагается на то, что модель понимает, кто здесь главный.

Мы столкнулись с той же проблемой в наших собственных ИИ-агентах. Наш директор по информационной безопасности (CISO) Кайл Полли рассказал изданию ISMG, что агенты «могут не следовать политикам, даже если прописать их в системном промпте». Именно поэтому мы создали Numbat — инструмент с открытым исходным кодом, который проверяет, что агент собирается сделать, и может заблокировать действие, если оно нарушает настроенное правило безопасности.

Обеспечивать безопасность LLM — значит признать, что модель иногда будет выполнять приказы не того человека, и выстроить вокруг нее защитные механизмы ИИ, которые выдержат даже в этом случае.

Каковы лучшие практики обеспечения безопасности LLM?

Мы разберем OWASP Top 10 for LLM Applications 2026 по порядку — с первого по десятый пункт.

Для каждого риска вы найдете простое объяснение того, что может пойти не так, и пример из реальной практики. Затем мы расскажем о методах, которые помогают предотвратить проблему или хотя бы ограничить ущерб.

1. Сдерживайте промпт-инъекции

Промпт-инъекция происходит, когда злоумышленник заставляет ИИ выполнять инструкции, которые тот выполнять не должен. Эти инструкции могут поступить напрямую в чате или быть спрятаны в электронном письме, на веб-странице или в документе.

Второй тип называют непрямой промпт-инъекцией. Вы просите ассистента кратко изложить документ. А автор документа спрятал в нем указание для ассистента — отправить ему ваши личные файлы. Если ассистент выполнит эти инструкции, автор документа фактически воспользуется вашим доступом.

PCMag сравнивает защиту промптов с заделыванием дыр в пористом камне. Закроешь одно отверстие — вода найдет другое. «Атака находит лазейку; ее устраняют, но бесчисленное множество других путей для атаки еще только предстоит обнаружить — просто из-за того, насколько динамичны такие системы, как LLM».

Пример: в июне 2025 года исследователи Aim Security обнаружили EchoLeak — уязвимость, из-за которой Microsoft 365 Copilot можно было обманом заставить передавать конфиденциальную информацию компании. Когда сотрудник задавал обычный рабочий вопрос, Copilot мог подтянуть вредоносное письмо, выполнить спрятанные в нем инструкции и отправить конфиденциальные данные злоумышленнику. Атака обходила проверки, предназначенные для выявления вредоносных инструкций и удаления подозрительных ссылок.

Что можно сделать:

• Следуйте «правилу двух» от Meta: для EchoLeak требовался ИИ, который мог читать корпоративные данные, читать внешнюю почту и отправлять информацию наружу, — и у него были все три возможности. Если ограничить ИИ двумя из них, промпт-инъекция не сможет получить слишком большой контроль. Если задаче нужны все три, требуйте одобрения человека перед каждым действием.
• Тестируйте систему с участием атакующих, которым известна ваша защита: передайте специалистам по тестированию безопасности внедренные правила и фильтры и позвольте им попытаться их обойти. В одном исследовании атакующие, адаптировавшиеся к защите, добивались успеха более чем в 90% случаев против большинства из 12 протестированных средств защиты.

2. Не допускайте утечки конфиденциальной информации

Когда ИИ-системы передают конфиденциальную информацию людям, которые не должны ее видеть, это называется раскрытием конфиденциальной информации. Например, ИИ может раскрыть платежные данные клиента или оставить личную переписку в общей базе данных.

Многие утечки начинаются с «избыточного общего доступа». Допустим, компания подключает свой ИИ к дискам и базам знаний с нестрогими правами доступа. ИИ извлекает все, до чего может дотянуться, — ровно так, как и задумано. Никому не нужно ничего взламывать, но по сути LLM уже взломана.

Пример: в январе 2025 года исследователи Wiz обнаружили открытую базу данных DeepSeek, доступную из интернета и содержащую более миллиона записей журналов, включая историю чатов и API-ключи, с помощью которых программы получают доступ к другим сервисам. Исследователям даже не пришлось уговаривать модель что-либо раскрыть.

Что можно сделать:

• Проверяйте права доступа до того, как ИИ прочитает данные: прежде чем передавать документы модели, ваше приложение должно проверить, какие из них разрешено видеть пользователю, задающему вопрос.
• Защищайте записи, которые оставляет ваш ИИ: удаляйте личные данные и секретные ключи перед сохранением журналов активности, требуйте входа в систему и ограничивайте доступ кругом людей, которым он действительно нужен. Установите срок хранения, чтобы эти записи не накапливались бесконечно.

3. Обуздайте чрезмерную автономность

ИИ с чрезмерной автономностью обладает большими возможностями, чем требует его работа: инструментами, которые ему не нужны, разрешениями, выходящими за рамки задачи, или свободой действовать без проверки. Причина здесь не важна.

Промпт-инъекция, баг или модель, которая просто ошиблась, — все это приводит к одному результату. Если у ИИ есть такая возможность, рано или поздно он сделает что-то разрушительное.

Пример: в июле 2025 года основатель SaaStr Джейсон Лемкин сообщил, что агент для программирования Replit удалил его базу данных с 1206 записями о руководителях, несмотря на указание не вносить изменения. Сначала агент заявил, что данные восстановить невозможно, хотя позже выяснилось, что это не так. Джейсон понял, что указание не трогать базу данных не лишило агента возможности ее удалить.

Развернуть

Источник: X

Что можно сделать:

• Убирайте возможности, которые не нужны для задачи: ограничивайте как набор инструментов агента, так и то, что эти инструменты могут делать. Ассистенту, который кратко пересказывает письма, нужно разрешение на их чтение, а не на отправку или удаление.
• Выносите проверку разрешений за пределы ИИ: каждый раз, когда запрашивается действие, проверяйте его на соответствие правилам безопасности и требуйте одобрения человека.

4. Проверяйте все, что попадает в цепочку поставок ИИ

Немногие компании создают ИИ с нуля, и с каждым годом их становится все меньше. Согласно опросу Menlo Ventures «2025: The State of Generative AI in the Enterprise», в 2024 году ИИ-модели покупали 53% компаний, а в 2025 году — уже 76%.

Чаще всего компании скачивают модели с платформ вроде Hugging Face, дообучают их на наборах данных, собранных другими людьми, и подключают дополнения и программные пакеты, написанные незнакомцами.

Каждый из этих компонентов — потенциальная точка входа. Если хотя бы один из них подделан, проблема попадет прямо в ваш продукт.

Пример: с января по август 2026 года число публичных репозиториев моделей на Hugging Face выросло с 2,43 до 2,96 миллиона. Однако в июле 2026 года модели OpenAI во время внутреннего тестирования безопасности обошли ограничения, которые должны были изолировать их от интернета, и взломали часть систем Hugging Face. Более того, один из агентов нашел 14 общедоступных наборов учетных данных, проверил, что они работают, и передал их другим агентам. Затем агенты воспользовались уязвимостями, которые позволили им выполнять код на серверах Hugging Face.

«Мы ужесточаем требования к согласованию (alignment) на протяжении всего жизненного цикла модели, создаем более изолированные песочницы, ограничиваем доступ к интернету и усиливаем контроль доступа к весам модели», — говорится в отчете OpenAI.

Что можно сделать:

• Фиксируйте точную версию моделей и проверяйте их: привязывайте каждую модель к проверенной версии и сверяйте контрольную сумму ее файла перед загрузкой, чтобы подмененный файл не проскользнул под той же меткой. OWASP также рекомендует использовать цифровые подписи, но с оговоркой: подпись подтверждает происхождение модели, а не ее безопасность.
• Проверяйте каждый пакет, который предлагает ИИ: прежде чем устанавливать программный пакет, рекомендованный ИИ-ассистентом, убедитесь, что он существует, что это именно тот пакет, который вам нужен, и что его выпустил ожидаемый издатель.

5. Защищайтесь от отравления данных и моделей

Отравленный ИИ обучается на искаженных данных. Это могут быть примеры, на которых его дообучали, или база знаний, в которой он ищет ответы. Модель по-прежнему выглядит рабочей — она просто усваивает неправильные уроки, а иногда учится вести себя некорректно только тогда, когда видит определенную фразу-триггер.

Модель будет проходить все ваши тесты, пока кто-нибудь не использует эту фразу.

Развернуть

К тому же последствия очень трудно устранить. Отравление — это не баг, который можно исправить патчем. Если ваши данные неверны, возможно, придется перепроверить их, переобучить модель или полностью ее заменить.

Пример: в октябре 2025 года исследователи Anthropic, Института безопасности ИИ Великобритании (UK AI Security Institute) и Института Алана Тьюринга показали, что 250 отравленных документов достаточно, чтобы научить модель выдавать бессмыслицу всякий раз, когда она встречает определенный триггер. Одно и то же число документов сработало для моделей всех четырех протестированных размеров, хотя самая крупная из них обучалась на объеме чистых данных, более чем в 20 раз большем.

Что можно сделать:

• Отслеживайте происхождение данных: ведите учет всех используемых наборов данных и моделей, их источников и изменений между версиями. Мы рекомендуем использовать контроль версий для наборов данных: если обнаружится отравление, вы сможете откатиться к чистой версии и выяснить, как оно туда попало.
• Проверяйте модели на бэкдоры: «бэкдор» — это скрытое поведение, которое злоумышленник внедряет в модель и которое активируется определенной фразой или другим триггером. Выявляйте бэкдоры с помощью входных данных, специально составленных так, чтобы модель нарушила свои обычные правила.

6. Поставьте предел неограниченному потреблению

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

OWASP называет корень проблемы «асимметрией затрат». Короткий дешевый запрос может запустить дорогостоящие вычисления на вашей стороне.

Пример: в мае 2024 года исследовательская группа Sysdig Threat Research Team обнаружила новый вид атаки под названием «LLMjacking». Группа злоумышленников с помощью украденных учетных данных атаковала 10 облачных LLM-сервисов. Они проникли через уязвимую версию Laravel, а затем выяснили, что позволяют сделать эти учетные данные и каковы квоты, — очевидно, с целью продажи доступа. Кроме того, они запрашивали многие настройки журналирования — вероятно, чтобы избежать обнаружения. По оценке Sysdig, в худшем случае ущерб для жертвы мог бы превысить 46 000 долларов в день.

Что можно сделать:

• Устанавливайте бюджеты, которые останавливают расходы: задайте жесткие лимиты расходов для отдельных пользователей, API-ключей, команд и аккаунта в целом. Применяйте их во всех точках, через которые могут поступать запросы.
• Задайте каждой задаче точку остановки: ограничьте, сколько времени может выполняться задача, какой объем текста она может обработать и сгенерировать и сколько вызовов инструментов может совершить. Добавьте автоматическое прерывание для агентов, которые зацикливаются или превышают свой лимит.

7. Выявляйте недостоверную информацию, прежде чем действовать

Когда ИИ выдает что-то ложное, но правдоподобное, и кто-то — или что-то — действует исходя из этого, речь идет о недостоверной информации. Главный риск не столько в самом неверном ответе, сколько в том, что ему доверяют и его используют.

Судя по зафиксированным инцидентам, специалисты беспокоились о недостоверной информации меньше, чем следовало бы. Как сказано во вступительном письме к редакции 2026 года, голосовавшие поместили этот риск ближе к концу списка, хотя, судя по реальным инцидентам, ему место ближе к началу.

Пример: в 2025 году Deloitte Australia подготовила обзор ИТ-систем социального обеспечения по государственному контракту на 440 000 австралийских долларов. Крис Радж, исследователь из Сиднейского университета, обнаружил в нем ссылки на несуществующие исследования и выдуманную цитату из решения федерального суда. В исправленной версии отчета было указано, что Deloitte использовала в своей методологии Azure OpenAI GPT-4o, и компания согласилась вернуть последний платеж. К сожалению, речь шла как раз о проверке, призванной подтверждать достоверность и надежность (assurance review).

Что можно сделать:

• Убедитесь, что доказательства подтверждают ответ: основывайте утверждения на актуальных и авторитетных источниках. Отвечая на вопрос о правилах компании, извлекайте утвержденную версию документа и проверяйте, подтверждает ли она вывод, включая исключения.
• Проверяйте, прежде чем система начнет действовать: если агент сообщает, что клиент прошел проверку личности, сверьте это с системой верификации, прежде чем проводить платеж. Для важных решений требуйте одобрения человека и предоставляйте проверяющему подтверждающие данные.

8. Ограничьте ущерб от раскрытия скрытого контекста

ИИ-приложения передают модели инструкции и фоновую информацию, которые пользователи обычно не видят. Это может быть системный промпт, внутренние политики, описания доступных инструментов и правила о том, кто может ими пользоваться. Раскрытие скрытого контекста происходит, когда модель кому-то выдает эту информацию.

В 2026 году OWASP расширил этот пункт, ранее называвшийся «утечкой системного промпта», поскольку системный промпт — лишь часть того, что может утечь. Опасность зависит от того, что вы туда поместили. Утечка руководства по тону общения — лишь повод для легкой неловкости, а утечка API-ключа даст постороннему доступ к вашей конфиденциальной базе данных.

Пример: в феврале 2023 года пользователи заставили Bing Chat от Microsoft раскрыть свои внутренние инструкции. Одна из успешных попыток принадлежала Марвину фон Хагену: он представился разработчиком OpenAI и попросил выдать инструкции, якобы чтобы настроить модель. Bing раскрыл правила, регулирующие его поиск, ответы и поведение в вопросах безопасности, а также свое внутреннее имя — Sydney. Среди раскрытых инструкций было и указание держать эти инструкции в секрете.

Что можно сделать:

• Не пускайте секреты в контекст модели: Исходите из того, что всё, что может прочитать модель, может увидеть и пользователь, — поэтому храните пароли, API-ключи и токены доступа в отдельной системе управления секретами.
• Сделайте так, чтобы разрешения действовали даже при утечке правил: Проверяйте права доступа в коде приложения. Если инструмент доступен только администраторам, перед его запуском проверяйте разрешения учётной записи пользователя.

9. Надёжно защитите векторы и эмбеддинги

Когда ИИ использует векторный поиск, чтобы найти ответы в документах вашей компании, он не ищет по тексту напрямую. Документы преобразуются в «эмбеддинги» — длинные списки чисел, отражающие смысл каждого фрагмента, — и сохраняются в векторной базе данных. Вопрос преобразуется точно так же, и система извлекает фрагменты, числа которых оказываются к нему ближе всего.

OWASP выделяет четыре сценария сбоя: отравление заставляет систему ошибаться, инверсия — допускать утечки, глушение — замолкать, а нарушение контроля доступа — выдавать что угодно кому угодно.

Эти числа — вовсе не такая безопасная абстракция, какой кажутся. Сохранённые эмбеддинги можно снова превратить в текст: один из методов в ходе тестов в точности восстановил 92% коротких фрагментов длиной 32 токена. Поэтому утечка резервной копии, где хранятся «только эмбеддинги», тоже может раскрыть содержимое документов.

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

Что можно сделать:

• Храните публичные и закрытые данные в отдельных индексах: Не смешивайте контент, собранный в интернете, с данными партнёров или конфиденциальными внутренними документами. Разделяйте данные физически по уровню доверия, а не размечайте контент внутри одного индекса: так вы исключите целый класс ошибок конфигурации, и контент из интернета не окажется рядом с материалами вашего совета директоров.
• Обращайтесь с эмбеддингами так же, как с исходными документами: Шифруйте их, защищайте резервные копии векторной базы данных наравне с исходными файлами и удаляйте эмбеддинги вместе с оригиналом. API-ключи вашего сервиса эмбеддингов должны храниться в секрете.

10. Проверяйте выходные данные ИИ, прежде чем передавать их дальше

Если приложение передаёт выходные данные ИИ другой системе, не проверив, безопасно ли использовать их там, это и есть ненадлежащая обработка выходных данных LLM.

Эта категория также охватывает небезопасный код, который ИИ-ассистенты для программирования генерируют в огромных объёмах. Поэтому каждая строка, написанная ассистентом, — это тоже выходные данные.

Пример: В 2025 году исследователь Иоганн Рехбергер показал, как ИИ-ассистент для программирования Amp от Sourcegraph мог допустить утечку содержимого чата, просто отобразив изображение. С помощью промпт-инъекции он заставил Amp включить конфиденциальную информацию в веб-адрес изображения. Затем приложение автоматически загрузило это изображение и тем самым отправило информацию на его сервер. Сбой обработки выходных данных заключался именно в этом автоматическом запросе: сгенерированный моделью текст превратился в подключение к внешнему серверу, через которое ушли конфиденциальные данные.

Что можно сделать:

• Делайте выходные данные безопасными для места назначения: Проверяйте и обрабатывайте ответы с учётом того, куда они будут переданы. Для веб-страницы не допускайте, чтобы сгенерированный текст превратился в исполняемый код. Для базы данных используйте подготовленные запросы, в которых передаваемые значения отделены от команд.
• Не позволяйте ответам автоматически подключаться к внешним ресурсам: По умолчанию отключите в ответах модели автоматическую загрузку изображений, предпросмотров ссылок и встроенных страниц. Разрешайте необходимые подключения только к явно одобренным ресурсам.

Как Perplexity защищает LLM?

Мы исходим из того, что каждый из перечисленных выше рисков рано или поздно реализуется, и проектируем системы так, чтобы в этом случае ущерб был минимальным. Наш директор по информационной безопасности (CISO) Кайл Полли рассказал, как мы это делаем, на недавнем воркшопе.

• Агент получает собственный компьютер, и изначально он пуст: Агентные инструменты, установленные на вашем ноутбуке, могут получить доступ к его файлам, приложениям и сохранённым учётным данным. Perplexity Computer работает иначе. Каждая задача выполняется в собственной изолированной песочнице, и, как говорит Полли, «по умолчанию у агента нет доступа ни к чему».
• Агент никогда не видит пароли: Учётные данные для подключённых сервисов хранятся за пределами песочницы. Когда агенту нужно обратиться к сервису, например к GitHub, он отправляет запрос без учётных данных. Шлюз проверяет, что адресат и сам запрос соответствуют ожидаемым, а затем добавляет учётные данные к исходящему запросу. Агент может пользоваться подключением, не получая ключей.
• Ваши разрешения сохраняются, и их можно ужесточить: Подключения через OAuth сохраняют ваши права доступа в подключённом сервисе. Если вы чего-то не видите, то не увидит этого и ваш агент.
• К каждой веб-странице мы относимся как к незнакомцу: Мы создали BrowseSafe для Comet, нашего агентного браузера, потому что протестированные нами инструменты не отвечали нашим требованиям в реальных условиях. Браузер проверяет веб-страницы и другой внешний контент, включая электронные письма, на наличие промпт-инъекций. Мы опубликовали в открытом доступе и модель, и набор данных.
• Мы следим за агентом и машинами, на которых он работает: Numbat находится между решением агента выполнить действие и фактическим запуском инструмента. Numbat регистрирует активность поддерживаемых агентов для программирования и может блокировать действия, нарушающие настроенные политики, ещё до их выполнения. Bumblebee ведёт учёт программных пакетов на ноутбуках, серверах и в конвейерах сборки и помечает известные вредоносные. Оба инструмента распространяются с открытым исходным кодом.
• Поставщики моделей не хранят ваши данные: С нашими сторонними поставщиками LLM у нас действуют соглашения о нулевом хранении данных. Администраторы Enterprise также могут сократить срок хранения данных в самой Perplexity до 24 часов.

Мы создали Numbat на опережение, и причину Полли формулирует одной фразой: «Чем больше автономии вы даёте агенту, тем выше риск».

Часто задаваемые вопросы о безопасности LLM

Какая LLM самая безопасная?

Ни одна LLM сама по себе не делает приложение безопасным: модели по-прежнему могут принять контент, который им нужно лишь прочитать, за инструкции, которые нужно выполнить. Кроме того, средства защиты, которые выглядят надёжными в стандартных тестах, могут не выдержать реального натиска.

Правильнее спросить, какая конфигурация наиболее безопасна для вашего сценария использования. Это ограниченные разрешения, учётные данные, недоступные модели, одобрение человеком рискованных действий и тестирование силами специалистов, которые знают, как устроена ваша защита.

Что такое уязвимости LLM?

Уязвимости LLM — это слабые места, из-за которых ИИ-систему можно обмануть или она может допустить утечку данных либо причинить ущерб — по вине злоумышленника или из-за собственных ошибок.

Десять основных рисков: промпт-инъекция, раскрытие конфиденциальной информации, чрезмерная агентность, цепочка поставок, отравление данных и модели, неограниченное потребление, недостоверная информация, раскрытие скрытого контекста, уязвимости векторов и эмбеддингов, а также ненадлежащая обработка выходных данных.

Безопасна ли частная LLM?

В некоторых случаях это более безопасный вариант, но не по умолчанию. Если вы запускаете модель в собственной инфраструктуре или в облачной среде, у вас больше контроля над обработкой данных. Однако автоматического способа предотвратить промпт-инъекции, чрезмерную агентность, отравление или появление недостоверной информации не существует.

При самостоятельном размещении вы также несёте ответственность за загружаемую модель, включая риски цепочки поставок и необходимую для неё инфраструктуру.