Guardrails — это не один фильтр вокруг LLM, а набор технических ограничений, которые не позволяют агенту выходить за разрешённые действия, данные и ресурсы. Для production-систем особенно важно отделять рассуждение модели от фактического права выполнить tool call или изменить внешнее состояние.
Какие риски закрывают guardrails
Вызов запрещённого или слишком мощного инструмента.
Отправка некорректных параметров во внешний API.
Утечка секретов и чувствительных данных в model context или logs.
Повтор side-effect действия после retry.
Следование вредоносной инструкции из документа, сайта или сообщения.
Policy layer перед tool execution
Каждый tool call должен проходить отдельный policy layer. Он проверяет identity пользователя, разрешённые tools, scope ресурсов, риск операции и текущий state. Модель может предложить действие, но окончательное разрешение выдаёт детерминированная политика.
Allowlist действий и ресурсов
Разрешайте конкретные действия вместо общего доступа к API.
Ограничивайте домены, репозитории, папки, таблицы и аккаунты.
Разделяйте read и write permissions.
Для shell/code execution используйте отдельный sandbox и запрет опасных системных операций.
Не разрешайте модели самостоятельно расширять scope.
Строгие схемы параметров
Tool arguments должны валидироваться по строгой схеме до исполнения. Проверяйте типы, enum, диапазоны, обязательные поля и semantic constraints. Для денежных сумм, email-адресов, идентификаторов и путей полезны дополнительные доменные проверки, которые невозможно надёжно заменить промптом.
Human approval для критичных действий
Запрашивайте подтверждение перед оплатой, удалением, публикацией и отправкой сообщений.
Показывайте точные параметры будущего действия.
Привязывайте approval к конкретному action ID и состоянию.
Не переиспользуйте подтверждение после изменения параметров.
После approval повторно запускайте policy check.
Rate limits и resource budgets
Агенту нужны ограничения не только по API, но и по времени, количеству шагов, токенам, стоимости и параллельным операциям. Бюджет run должен быть известен заранее, а превышение лимита переводить процесс в безопасное состояние вместо бесконечного loop.
Защита от prompt injection
Внешний контент считается недоверенным. Текст страницы, PDF, email или issue не должен иметь права менять system policy. Полезно маркировать происхождение данных, разделять instructions и content, запрещать динамическое создание новых permissions и проверять каждое действие независимо от текста, который увидела модель.
Проверка результата
Определяйте observable success condition для каждого side effect.
После write выполняйте независимый read-back.
Проверяйте, что изменился именно ожидаемый объект.
Для критичных операций сохраняйте audit trail.
Если результат неоднозначен, не переходите к следующему необратимому шагу.
Логи и observability
Логируйте run ID, step ID, tool, policy decision и outcome.
Отдельно считайте denied actions, retries и approval rate.
Не сохраняйте passwords, raw tokens и секретные form values.
Добавляйте reason code для каждого policy deny.
Отслеживайте стоимость и длительность run.
Guardrails не заменяют sandbox
Guardrails определяют, что агенту разрешено делать, а sandbox ограничивает последствия выполнения кода и системных операций. В production нужны оба слоя: policy перед действием и техническая изоляция среды во время выполнения.
Production checklist
Есть явный allowlist tools и ресурсов.
Все аргументы проходят schema и semantic validation.
Критичные действия требуют fresh approval.
Retries идемпотентны или защищены deduplication.
Внешний контент не может изменить permissions.
Есть quotas, audit trail и проверка результата.