Суть
Если 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«знает», что пришла из внешней почты.
Связано с
- Prompt Injection — атака, против которой работает паттерн
- Guardrails — «убрать объект атаки из досягаемости модели»
- Agent Deps — альтернативный взгляд: изоляция прав/ключей в типизированных зависимостях (PydanticAI)
- Agent Security — уровень защиты в общей модели
Открытые вопросы
- Накладные расходы Dual-LLM (две модели + interpreter) vs выигрыш в безопасности на практике?
- Зрелость готовых реализаций CaMeL в 2026?