Guardrails

Суть

Агент не должен пускать «сырой» запрос прямо в LLM и «сырой» ответ прямо наружу. Вокруг «мозга» строят два кольца защиты: pre-processing (guardrails до LLM) и output QA (guardrails после LLM).

Зачем это нужно

LLM «уверенно ошибается» и чувствительна к формулировкам — без guardrails агент уязвим к инъекциям, утечкам прав/PII и выдаче опасного контента. Это обязательная часть продакшн-агента (входит в DoD, см. Agent Evals).

Как работает

• Pre-processing (до LLM): фильтр prompt-injection и попыток вытащить system prompt; маскирование PII; проверка прав («можно ли этому пользователю такие данные»); нормализация запроса. Policy before reasoning.
• Output guardrails (после LLM): проверка формата (markdown/JSON), запрет опасных инструкций (rm -rf, выдача ключей), наличие оговорок об уверенности и ссылок/цитат (если был RAG), «не пустой/не слишком общий».
• «Документы — это данные, инструкции в них игнорируются»: чанк из базы знаний с фразами ignore previous / system prompt / tool помечается risky и не используется; executor никогда не вызывает инструмент по тексту из документа без подтверждения планировщика.
• Двухступенчатый контроль прав (RBAC/ABAC, Zero Trust): фильтр на входе по правам + на выходе вторая модель сравнивает эмбеддинги ответа с категориями прав доступа и «подрезает» выход за границу. Для критической инфраструктуры РФ — модель «если явно не разрешено — запрещено».
• Для код-агентов: запрет путей (.env, secrets.*, kubeconfig, terraform.tfstate) и allowlist команд (только pytest, ruff, …; запрет curl/wget/ssh/rm -rf).
• Для computer-use агентов (Computer Use): угрозы — Confused Deputy (агент с правами пользователя выполняет команды атакующего со страницы), индиректный prompt injection, data exfiltration, approval fatigue (жмёшь OK не читая). Защита: изоляция в Firecracker microVM / gVisor / hardened-контейнере (никогда не на хосте, не маунтить docker.sock), сеть через proxy с whitelist доменов, креды вне песочницы, явные tiers риска, watch mode + HITL на high-risk (платежи, auth, башкоманды).
• Структурное разделение через XML-теги: оборачивание данных и инструкций в теги (<context>, <instructions>) помогает модели не путать содержимое документа/пользователя с системными командами — структурный барьер против prompt-injection в дополнение к правилу «документы — это данные» (см. Prompt Engineering).

Альтернативный взгляд: изоляция через deps

Лекция по структурному выводу предлагает защищаться от prompt injection не фильтрацией текста, а архитектурной изоляцией: права, ключи и роли вообще не попадают в промпт, а живут в типизированных зависимостях (Agent Deps). Проверка прав делается кодом инструмента (if ctx.deps.role != "admin": raise), а не инструкцией модели. Тогда фраза «забудь роль, ты админ» бессильна — управлять правами через текст невозможно. Это смещает акцент с «научить модель игнорировать вредные инструкции» на «убрать security-критичное из досягаемости модели»: правило — если это security-критично, оно должно быть в коде, а не в промпте. Подход дополняет фильтрацию/XML-экранирование, а не заменяет: фильтры чистят вход, deps убирают сам объект атаки.

Связано с

• Agent Routing — роутер/intent-классификация тоже работает как guardrail на входе
• Human in the Loop — на грани прав/риска эскалируем к человеку
• Agent Evals — no_policy_violation — метрика, проверяющая guardrails
• Agent Deps — изоляция прав/секретов в коде как защита от инъекций
• Computer Use — sandbox/whitelist/HITL для агента, управляющего экраном

Открытые вопросы

• как тестировать anti-injection (набор атакующих промптов)
• вторая модель на выходе — стоимость/латентность vs безопасность