Суть
Если security-критичное недоступно модели, её нельзя ею же и сломать. Dual-LLM убирает у «читающей» модели инструменты, а у «действующей» — сырой недоверенный текст. Это уровень защиты для продакшн-прототипов, выше «гигиены» (spotlighting/делимитеры).
Зачем это нужно
Развивает идею Guardrails «убрать security-критичное из досягаемости модели» (ср. альтернативный взгляд PydanticAI про изоляцию прав в Agent Deps). Актуально, когда есть необратимые действия (деньги, письма, БД), где одной фильтрации мало.
Как работает
Dual-LLM (уровень 1):
- Quarantined LLM (Q-LLM) — видит недоверенный контент, парсит его в структурированные переменные, но не имеет инструментов. Задача — работать с данными, не пытаться выполнять команды.
- Privileged LLM (P-LLM) — оркеструет и вызывает инструменты, но не видит сырой недоверенный текст.
- Между ними передаются переменные/ссылки (через Python-код или JSON-атрибуты), а не свободный текст.
- Ограничение: если две модели общаются свободным естественным языком — канал по-прежнему дыра (Q-LLM может «протащить» инъекцию).
CaMeL (уровень выше) — лечит дырявый канал:
- Между Q-LLM и P-LLM передаются не свободный текст, а адресуемые значения с метаданными об источнике (taint tagging).
- P-LLM пишет план в виде Python-кода, но не видит недоверенный контент; Q-LLM читает контент и отдаёт типизированные переменные.
- Interpreter знает, что
email_body_from_external— недоверенный источник, и не позволит передать его вsend_email()без явного policy-разрешения. - Каждая переменная несёт тег источника:
email_body«знает», что пришла из внешней почты.
Чего это стоит и что с готовыми реализациями
Сверка 2026-08 — обе величины наконец измерены, и обе неприятные.
Накладные расходы. У CaMeL расход токенов растёт примерно втрое: 2.82× на входе и 2.73× на выходе. Это не считая собственного интерпретатора, который надо поддерживать. Плата за безопасность видна и в полезности: на AgentDojo незащищённая система решает 84% задач, CaMeL — 77% с доказуемой безопасностью, то есть около семи пунктов уходит в отказ выполнять то, что не удаётся выполнить безопасно. На отдельных приложениях просадка сильнее: в одном из замеров потеря полезности на Slack-сценариях составила 20.8% против 47.5% у сравниваемого подхода.
Зрелость: подход остался исследовательским. Спустя больше года после публикации убедительных внедрений в проде по-прежнему нет, готовой общедоступной реализации тоже. Причина не в идее, а в цене входа: нужен собственный интерпретатор Python с проверкой политик и сквозная разметка значений capability-метаданными — это переустройство архитектуры приложения, а не подключение библиотеки.
Что из этого следует практически. Полный CaMeL сейчас брать неоткуда, но его центральная идея работает и в более дешёвых формах. В адаптивных замерах лучше всех держался Progent — символические правила привилегий: успех атаки падает с 25.8% без защиты до 4.2% при обычной атаке и 2.6% при адаптивной, то есть примерно шестикратное снижение сохраняется, когда атакующий знает устройство защиты. Общий признак у обоих подходов один: решение о допустимости действия принимает детерминированный механизм, а не модель — та же логика, что в Deterministic Veto.
Связано с
- Prompt Injection — атака, против которой работает паттерн
- Guardrails — «убрать объект атаки из досягаемости модели»
- Agent Deps — альтернативный взгляд: изоляция прав/ключей в типизированных зависимостях (PydanticAI)
- Agent Security — уровень защиты в общей модели