Самые сложные проблемы безопасности ИИ теперь находятся за пределами модели

Доклад 2026 OWASP Топ‑10 для LLM‑приложений предоставляет критический взгляд на зрелость производственного ИИ. Он фиксирует важный сдвиг: отрасль выходит за пределы песочницы и сталкивается со сложностями реальной интеграции.

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

Рейтинг OWASP Top 10 отражает эту эволюцию. «Excessive Agency» поднялся с шестого места на третье, а «Unbounded Consumption» — на шестое. В то же время «Improper Output Handling» опустился на десятое место.

Это не умаляет риска обработки вывода. Если ответ LLM попадает в оболочку или базу данных без строгой проверки, традиционные уязвимости инъекций сохраняются. Однако парадигма сменилась. В агентной системе ответ модели не является конечной точкой; он представляет собой ввод, несущий полномочия. Когда модель хранит учётные данные или взаимодействует с API, её вывод выступает вектором, способным инициировать действия в разных системах.

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

Рейтинг следует за ущербом

OWASP использовал 7 714 инцидентов, 75 % из которых основаны на консенсусе сообщества, и 25 % — на эмпирических данных об инцидентах. Эта база доказательств вынудила реально переупорядочить приоритеты.

«Excessive Agency» вырос из‑за того, что реальность производственных сред догнала теорию. Организации ускоряют развертывание автономных возможностей быстрее, чем создают необходимые контрольные плоскости. Критическая уязвимость заключается не только в ответе, который предоставляет модель, но и в контексте авторизации, в котором этот ответ исполняется.

Хотя «Improper Output Handling» остаётся проблемой, команды DevOps повысили свою способность защищать downstream‑системы с помощью проверки схем и параметризованных запросов. Это устоявшиеся практики безопасности приложений.

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

Рассматривайте каждый инструмент как открытую возможность

Многие команды рассматривают определения инструментов лишь как интеграционные трубы. Это довольно смешная и фундаментальная ошибка. Каждый инструмент, коннектор или конечная точка API расширяют сферу влияния AI‑приложения.

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

Вы должны соблюдать принцип наименьших привилегий:

• Сузьте интерфейс: предоставьте агенту инструменты только для чтения, а не универсальные коннекторы.
• Контекст с ограничением: выполняйте запросы в рамках OAuth‑идентичности пользователя.
• Точки принудительного применения политик (PEP): реализуйте логику авторизации как обязательный промежуточный слой между моделью и downstream‑системами. Каждое действие должно проверяться на соответствие политике перед выполнением.
• Человек в цикле (HITL): требуйте явного одобрения для операций, которые трудно откатить или которые имеют высокий материальный эффект.

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

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

Каждому автономному запуску нужен жёсткий стоп

«Unbounded Consumption» резко возрос, потому что объём запросов является недостаточным показателем риска ресурсов. Один короткий запрос может вызвать рекурсивную, ресурсоёмкую цепочку вызовов инструментов. Счётчик не останавливается, пока агент не завершит работу.

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

Операционный охват требует аналогичной строгости. Определите максимальное количество записей, которые агент может изменить, и задайте границы распространения задачи. Если в вашей архитектуре отсутствует детерминированный механизм “stop”, вы фактически делегировали полномочия, не определив их пределы.

Строить для неправильного ответа

Системная инженерия давно опирается на устойчивую архитектуру, чтобы защищать по своей природе ненадёжные компоненты. Мы предвидим отказы компонентов и нестабильность сети; безопасность вытекает из этого предположения, а не из иллюзии совершенства. Большие языковые модели требуют той же дисциплины в архитектуре.

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

Мы теперь рассматриваем внедрение подсказок (Prompt Injection) не столько как уязвимость, сколько как закон физики. Оно будет всегда присутствовать. Факт в том, что сами модели не могут быть эффективными решающими в вопросах, критически важных для безопасности. В реальном агентском проекте, который я разрабатываю, у нас около 100 автоматизированных «red team» тестов. Мы убеждаемся, что проходим их все. Но делаем мы это, создавая жёсткие контрольные механизмы вне модели. Мы можем отключить их и увидеть показатели прохождения/провала только для модели. Самая старая, самая слабая модель, которую мы тестируем, проваливается в 17% случаев. Самая новая, самая крупная модель проваливается в 2% случаев. Большой прогресс, верно? Но достаточно ли 98% в том случае, когда каждый сбой означает утечку конфиденциальных данных? Отнюдь нет.

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

Рейтинги 2026 года действительно проясняют, где сбои ИИ переходят в материальные последствия. Модель может стать источником ошибки, но архитектура определяет радиус поражения. Для производственного ИИ самая критическая работа по безопасности происходит в пост‑инференс‑конвейере.