Prompt Injection неизбежен там, где нет контура

(почему агенты ломаются не из-за “злого ИИ”, а из-за архитектуры)

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

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

На самом деле prompt injection не является проблемой интеллекта. Это проблема архитектуры.

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

Это не автономность. Это хаос, оформленный в виде диалога.

Современный рынок агентов во многом построен именно на этой ошибке. Берётся языковая модель, к ней добавляется роль, добавляется файл “agent.md”, добавляется несколько правил поведения, и дальше агент выпускается в среду. Предполагается, что он будет “умным”, что он “поймёт”, что он “не станет”. Но это магическое мышление, а не инженерия. Роль не является состоянием. Текст не является контуром. А поведение модели не является протоколом исполнения.

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

Prompt injection опасен только в одном случае: когда модель отвечает вне состояния.

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

Отсюда следует простой, но непривычный вывод: защищать нужно не модель. Защищать нужно контур.

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

Это не “человек в контуре”. Это система в контуре.

И здесь важно подчеркнуть ещё одну вещь, которую рынок постоянно путает. Большие языковые модели не являются субъектами. Они не обладают ответственностью, намерением или моралью. Они являются оптимизаторами текста в рамках заданного контекста. Их задача не “быть правильными”. Их задача быть вероятностно согласованными с запросом. Поэтому любые попытки построить безопасность через “личность”, “роль” или “психологию агента” обречены. Личность без архитектуры ничего не значит. Роль без состояния не создаёт устойчивости.

Система должна быть сильнее модели.

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

Если выпускать генератор текста в среду без протокола исполнения, он будет вести себя как генератор текста в среде. Никакой мистики.

Настоящая автономность начинается там, где появляется слой исполнения: workflow, состояния, проверки, запрет самодеятельности, восстановление после сбоя. Там модель становится компонентом, а не хозяином. Там prompt injection превращается не в угрозу, а в шум, который система отфильтровывает так же, как бизнес отфильтровывает ошибки исполнения через регламент.

Поэтому главный вопрос будущего не в том, насколько умной станет модель. Главный вопрос в том, насколько инженерно будут построены контуры вокруг неё.

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

Это и есть следующая инженерная граница: контур исполнения, в котором агент перестаёт быть “агентом” и становится частью системы.