Суть
Три класса отказа, которые регулярно называют одним словом «модель сглючила», имеют разные причины и разные меры:
| Класс | Что происходит | Чем лечится |
|---|---|---|
| Внедрение инструкций | Недоверенный контент подменяет инструкции, политику или логику выбора инструмента | Жёсткая граница между инструкциями и данными (Prompt Injection, Trust Boundary Agent) |
| Jailbreak | Обход встроенного слоя безопасности самой модели | Шлюз модели, политика, проверки безопасности (Jailbreak Attacks) |
| Галлюцинация действия | Система считает, что основание для действия есть, хотя его не было | Детерминированные правила подтверждения, проверка возможностей, след аудита |
На примере агента поддержки различие бытовое. Письмо клиента пытается переписать системные правила — это внедрение инструкций. Модель начинает обходить базовые ограничения — это ближе к jailbreak. Агент «понял», что пользователь дал согласие на чувствительное действие, хотя никакого подтверждения не было, — это галлюцинация действия.
Почему это самостоятельный класс
Первые два предполагают противника. Третий возникает без всякой атаки: достаточно, чтобы формулировка пользователя выглядела как согласие, или чтобы в контексте оказался фрагмент прошлой сессии, где согласие действительно было.
Именно поэтому меры защиты от инъекций здесь не работают. Фильтр на входе не поймает ничего подозрительного — вход чист. Иерархия инструкций тоже не поможет: система не путает источник инструкции, она неверно заключает о факте.
Самостоятельность класса видна и по устройству стандарта: галлюцинация содержания лечится там оценкой уверенности ответа и порогом отсечения (AISVS C7.2.1, C7.2.2), а основание для действия живёт в совершенно другой главе — среди требований к подтверждению высокорисковых операций. Два разных раздела, две разные меры; попытка закрыть второе средствами первого промахивается мимо предмета.
Практическое правило
Решения с высокой ставкой не должны оставаться на свободном вероятностном суждении модели. Финальное право на действие живёт в слое политики и пути подтверждения (Agent Control Plane, Approval Path).
Разворачивается это в три конкретных требования:
- Подтверждение — состояние, а не вывод из текста. Признак «подтверждено» устанавливается путём подтверждения и хранится как поле запуска, а не выводится моделью из разговора. Стандарт формулирует это как «получено и проверено» — рантайм блокирует исполнение, пока подтверждение не получено и не верифицировано (AISVS C9.2.1), а на высоком уровне требует криптографической привязки подтверждения к параметрам действия, личности запросившего, контексту исполнения и одноразовому значению (C9.2.8). Одноразовость закрывает ровно тот случай, с которого начинается эта заметка: согласие из прошлой сессии, всплывшее в контексте, вторым разом не работает.
- Право проверяется на исполнении, а не на решении. Даже если модель уверена, что действие разрешено, шлюз проверяет это заново (Tool Gateway).
- След должен показывать основание. В трассе видно, откуда взялось право: какое решение политики, какая запись подтверждения (Agent Audit Log).
Связано с
Overreliance — соседняя ложь: не «сделал», а «предпосылка верна»
Prompt Injection — соседний класс, где противник подменяет инструкции
Jailbreak Attacks — соседний класс, где обходится защита модели
Approval Path — подтверждение как хранимое состояние
Agent Control Plane — где живёт право на действие
Tool Gateway — повторная проверка права на исполнении
Agent Failure Modes — каталог отказов, невидимых для мониторинга
Deterministic Veto — проверка оснований кодом, а не моделью