Сборщик промта как точка отказа: 20 проверок для безопасной LLM-системы

Когда речь заходит о безопасности приложений на базе больших языковых моделей, внимание обычно сосредоточено на самом промте — его формулировке, ограничениях и «строгости». Однако на практике вся защита проходит через один участок кода: сборщик промта (prompt builder), который формирует итоговый запрос к модели из системных инструкций, истории диалога и пользовательского ввода. Именно этот компонент становится точкой отказа, если разработчик не проверил, что и в каком порядке попадает в контекст модели. Автор материала на Хабре делится опытом собственного проекта и формулирует шпаргалку из 20 пунктов: что проверять в сборщике промта и почему это важно. Главная мысль — никакой системный промт не спасёт систему, если сборщик позволяет подменить роль, протащить невидимые символы или сфабриковать историю диалога.

Подробности

Ключевая проблема, которую подсвечивает автор, — доверие к структуре промта. Сборщик работает с несколькими источниками данных: системными инструкциями, предыдущими сообщениями, пользовательским вводом, результатами вызовов инструментов и внешним контентом. Если границы между ними не размечены явно, модель не отличает инструкцию от данных, и атакующий может внедрить собственные указания через любой из каналов. Среди рисков, которые перечисляет автор, — пропуск «чужой» роли в итоговом запросе, невидимые и управляющие символы, а также поддельная история: сконструированные сообщения, выдающие себя за предыдущие реплики системы или пользователя. Отдельно упоминается необходимость закладывать в сборщик проверки на будущее — шпаргалка дополнена пунктами, актуальными для 2026 года. Материал носит характер практического чек-листа, а не описания конкретной уязвимости: в исходной статье не приводятся CVE, названия затронутых продуктов или версий. Ценность публикации — в систематизации проверок, которые стоит пройти при ревью кода сборщика промта.

Что делать

Практические шаги, вытекающие из рекомендаций автора: — Проведите ревизию сборщика промта как отдельного компонента безопасности: определите все источники данных, которые попадают в итоговый запрос, и явно разметьте границы между инструкциями и данными. — Добавьте валидацию ролей: итоговый промт должен содержать только те роли и в том порядке, которые предусмотрены логикой приложения. — Фильтруйте невидимые и управляющие символы во всех пользовательских и внешних данных перед сборкой. — Не доверяйте истории диалога: проверяйте её происхождение и целостность, чтобы исключить подделку предыдущих сообщений. — Заложите проверки с прицелом на будущее: шпаргалка из 20 пунктов включает требования, которые станут критичными к 2026 году. — Относитесь к системному промту как к одному из слоёв защиты, а не как к основному барьеру: безопасность определяется кодом, который формирует контекст модели. Итог: сборщик промта — это граница доверия между приложением и LLM, и именно её нужно проверять в первую очередь. Чек-лист из 20 пунктов даёт командам готовую отправную точку для ревью такого кода.

Источник: Хабр — Информационная безопасность