Гардрейлы для AI-агентов: как настроить подтверждения и бюджеты

Гардрейлы для AI-агентов - это бэкенд-контроли, которые ограничивают доступ, выполнение действий и траты агента, даже если его модель выдает небезопасные инструкции. Для приложения на Lovable начните с узких прав на инструменты (tools), точечных согласований действий, логов аудита и жестких лимитов расходов. В этом руководстве эти правила превращаются в конкретную архитектуру агента поддержки - с готовым промптом для сборки и чек-листом для запуска.

Что должны контролировать гардрейлы AI-агентов

Модель предлагает действие. Ваше приложение решает, разрешено ли оно. Эту границу нарушать нельзя.

Для приложения, выходящего в октябре 2026 года, важный вопрос заключается не в том, умеет ли модель вызывать tools. Вопрос в том, сможет ли ошибочный вызов пересечь границу клиента (tenant), перевести деньги или сжечь бюджет.

Возьмем агента техподдержки, который читает тикеты, готовит черновики ответов и предлагает возвраты. Чтение разрешенного тикета - низкий риск. Отправка ответа влечет внешние последствия. Оформление возврата переводит деньги. У этих действий не должно быть одной общей политики разрешений.

| Действие | Политика по умолчанию | Проверка на бэкенде | | --- | --- | --- | | Чтение тикета | Разрешено в рамках тенанта | Проверка авторизованного членства и принадлежности тикета | | Создание черновика ответа | Разрешено без отправки | Сохранение черновика без доступа к email-ключам | | Отправка ответа | Сначала требует согласования | Согласование точного получателя, текста и вложений | | Оформление возврата | Требует авторизованного согласования | Проверка исходного платежа, суммы, валюты и доступного остатка для возврата | | Удаление записей | Запрещено в первом релизе | Не предоставлять инструмент удаления |

Это продуктовые правила, а не универсальные стандарты. Для медицинских процессов нужны одни правила, для суммаризатора внутренних встреч - совершенно другие.

Используйте пять уровней контроля:

1. Identity (Идентичность): Какой пользователь и тенант запустили этот прогон?
2. Scope (Область действия): К каким записям и инструментам есть доступ?
3. Authority (Полномочия): Какие действия требуют подтверждения другим человеком?
4. Budget (Бюджет): Сколько вызовов и долларов можно потратить?
5. Evidence (След): Что произошло и можно ли восстановить ход событий?

Валидаторы вывода и детекторы инъекций полезны, но они не заменяют базовый контроль. Идеально сформированный запрос на возврат средств все еще может быть нацелен на чужой платеж.

Если вы еще выбираете сценарий, изучите наши AI agent guides. Начните с одного полезного инструмента, а не с универсального агента с неограниченным доступом к HTTP.

Создание флоу согласования в Lovable

Используйте Lovable для интерфейса оператора и каркаса приложения. Авторизацию, валидацию согласований и выполнение tools вынесите в серверные функции или worker. Реализация на базе Supabase - лишь один из вариантов, та же логика применима к любой транзакционной базе данных.

Заложите около 6-12 инженерных часов на компактный прототип с одним инструментом чтения и одним инструментом записи, требующим одобрения. Это оценка для планирования, а не гарантия того, что сгенерированный код сразу готов к проду. Интеграция платежей и аудит безопасности потребуют отдельного времени.

1. Создайте минимальную модель данных

Создайте следующие таблицы:

• `agent_runs`: тенант, инициатор, статус, версия политики, лимиты и счетчики затрат.
• `agent_actions`: прогон (run), типизированное имя инструмента, канонические аргументы, хеш аргументов, срок действия и статус выполнения.
• `agent_approvals`: действие, аппрувер, хеш одобренных аргументов, решение и срок действия.
• `agent_events`: прогон, действие, таймстемп, тип события, актор и очищенные метаданные.
• `agent_usage`: резервирование, ID запроса к провайдеру, расчетная стоимость, фактическая стоимость и статус сверки (reconciliation).

Добавьте `tenant_id` в каждую связанную запись. Включите row-level security (RLS) для таблиц, доступных из браузера. Бэкенд все равно обязан проверять принадлежность к тенанту даже при использовании сервисных ключей с повышенными правами, так как эти ключи могут обходить RLS.

Браузер может запросить запуск или отправить решение по согласованию. Он ни в коем случае не должен напрямую менять статус выполнения, бюджеты или записи аудита.

2. Предоставляйте строго ограниченные инструменты

Лучше использовать `get_ticket(ticket_id)` и `propose_refund(payment_id, amount_minor, currency, reason)`, чем `fetch_url(url)` или `execute_sql(query)`.

Валидируйте аргументы по строгой схеме, отклоняйте неизвестные поля и загружайте целевой ресурс только внутри авторизованного тенанта. Берите ID тенанта из авторизованного запроса, а не из аргументов, сгенерированных моделью.

Для прототипа ограничьте предлагаемые возвраты 5000 минимальными единицами валюты (центами для USD, то есть $50). Не считайте, что у каждой валюты два знака после запятой. Запрос выше лимита должен отклоняться или уходить в отдельный ручной процесс.

Агент никогда не должен получать секретные ключи платежных шлюзов. Он также не должен иметь возможности придумать нового получателя для возврата: платежный сервис сам определяет, куда возвращаются деньги.

3. Согласовывайте конкретное действие, а не весь диалог

Подтверждение вида "Разрешить агенту продолжить" слишком размыто.

Показывайте оператору клиента, исходный платеж, сумму, валюту, причину и связанный тикет. Сохраняйте одобрение, привязывая его к хешу канонического пейлоада действия, включая имя инструмента, тенант, идентификаторы ресурсов и аргументы.

В первой версии сделайте предложения неизменяемыми (immutable). Изменение суммы создает новое предложение и требует нового согласования. Установите срок действия подтверждения в 15 минут в качестве базовой настройки, затем адаптируйте под рабочий процесс.

Перед выполнением проверьте:

• У аппрувера есть нужная роль в этом тенанте.
• Срок действия согласования не истек, а хеш совпадает с сохраненным действием.
• Действие все еще в статусе ожидания и не было выполнено ранее.
• Исходный платеж все еще доступен для возврата на указанную сумму.
• Прогон не отменен, и на него хватает бюджета.

Проверяйте права еще раз непосредственно в момент выполнения. Пользователь мог потерять финансовую роль уже после того, как нажал кнопку подтверждения.

4. Захватывайте действие на выполнение только один раз

Используйте атомарный переход состояния в базе данных, чтобы захватить одобренное действие. Два воркера не должны одновременно перевести статус из `approved` в `executing`.

Затем вызовите API провайдера со стабильным ключом идемпотентности, сформированным из ID действия (если провайдер это поддерживает). Повторный запрос обязан использовать тот же самый ключ.

База данных и внешний API не находятся в одной транзакции. Если запрос на платеж завершился по таймауту, его результат неизвестен, а не обязательно ошибочен. Запросите статус у провайдера или сверьте данные по правилам идемпотентности перед повторной отправкой. Никогда не создавайте новую платежную операцию только потому, что потерялся ответ на первый запрос.

Страница подтверждения должна отображать эту неопределенность. Статус "Проверяем ответ провайдера" честнее, чем зеленый бейдж успеха или ложное сообщение об ошибке.

Бюджеты и логи аудита

Контроль бюджета должен блокировать следующий вызов, а не просто констатировать вчерашние траты.

Для прототипа агента поддержки используйте следующие начальные параметры:

| Лимит | Начальное значение | Назначение | | --- | --- | --- | | Вызовов модели на прогон | 8 | Остановка бесконечных циклов рассуждений | | Вызовов tools на прогон | 12 | Ограничение внешней активности | | Время активного выполнения | 120 секунд | Запрет на планирование новых задач после дедлайна | | Бюджет на модель и tools | $0.25 на прогон | Ограничение расчетных операционных расходов | | Дневной бюджет тенанта | $10 | Защита от перерасхода при частых запусках | | Лимит повторов | 2 повтора на операцию | Предотвращение бесконечных попыток восстановления |

Время ожидания подтверждения человеком не должно занимать работающий воркер. Сохраните предложение в БД, приостановите прогон и возобновите его отдельной задачей после аппрува. Отдельно определите, сколько времени приостановленный прогон остается валидным.

Таймаут также не отменяет уже отправленное внешнее действие. Отмените будущие задачи, а затем проведите сверку зависших запросов.

Резервируйте средства до отправки запроса

Допустим, при заданных лимитах токенов ввода и вывода вызов может стоить максимум $0.04. Зарезервируйте эту сумму перед отправкой. После выполнения зафиксируйте реальные расходы и освободите остаток резерва.

Правило проверки:

```text settled_cost + active_reservations + next_reservation <= budget ```

Проверяйте и резервируйте средства атомарно - как для отдельного прогона, так и для суточного лимита тенанта. Логика "сначала прочитать, потом записать" приведет к перерасходу, если параллельные воркеры увидят один и тот же остаток.

Используйте целочисленные микродоллары или числовые типы фиксированной точности в БД для учета. Считайте повторные попытки и включайте отдельно тарифицируемые инструменты, если они есть. Не снимайте резерв только из-за таймаута: сначала выясните, обработал ли провайдер этот запрос.

Оценка резерва гарантирует потолок трат только тогда, когда можно ограничить каждое списание. Если инструмент тарифицируется непредсказуемо, ограничьте его использование, заложите консервативный запас в резерв или исключите из автоматического флоу. Лимиты расходов на стороне самого провайдера тоже служат хорошей страховкой.

Вот наглядный пример расчета (не оферта провайдера): при условных тарифах $1 за миллион входных токенов и $5 за миллион выходных вызов с 6000 входных и 1000 выходных токенов стоит $0.011. Восемь таких вызовов обойдутся в $0.088 без учета внешних инструментов и инфраструктуры. Последующие вызовы обычно содержат больше контекста, поэтому рассчитывайте резервы для каждого конкретного запроса, а не просто умножайте стоимость первого.

Кредиты на генерацию в Lovable не связаны с расходами на AI при работе готового приложения. Используйте наш Lovable pricing guide, чтобы рассчитать стоимость подписки на конструктор, а runtime-сервисы оценивайте отдельно.

Логируйте решения без утечки данных клиентов

Записывайте ID прогона и действия, имя инструмента, версию политики, решение по авторизации, ссылку на подтверждение, задержку, количество повторов, стоимость и ID запроса к провайдеру.

Не сбрасывайте токены доступа, полные платежные реквизиты или весь текст приватных тикетов в общий поток событий. Храните сокращенные выжимки и ссылки. Если сохранение чувствительных данных необходимо, настройте для них отдельный контроль доступа и политику удаления.

Сделайте таблицу событий доступной только для добавления (append-only) для ролей приложения. Это повышает прозрачность, но не защищает от правок со стороны администраторов БД. Для строгих требований комплаенса может потребоваться отдельное неизменяемое хранилище.

Логируйте отказы и события сверки так же тщательно, как и успешные операции. Иначе дашборд скроет именно те кейсы, которые требуют расследования.

Готовый промпт и чек-лист для запуска

Вставьте этот текст в Lovable после подключения бэкенда. Попросите его сначала объяснить миграцию и архитектуру серверной авторизации, прежде чем применять изменения. В нашей prompt library есть и другие паттерны для точечных правок.

```text Build a guarded support-agent prototype with a Supabase backend.

Scope:

• Read tenant-authorized tickets.
• Draft replies without sending.
• Propose USD refunds up to 5000 cents.
• Use a mock payment adapter first. No live refunds.

Create agent_runs, agent_actions, agent_approvals, agent_events, and agent_usage tables with tenant isolation. Use integer microdollars for cost accounting.

Security:

• Derive user and tenant authorization server-side.
• Never expose provider or service-role secrets in browser code.
• Reject unknown tool names and invalid argument fields.
• Browser clients cannot modify execution state or cost counters.
• Elevated backend credentials require explicit tenant checks.

Approvals:

• Show the exact payment, amount, currency, and reason.
• Store immutable proposals and hash canonical action payloads.
• Require a finance-role approval with a 15-minute expiry.
• Recheck role, hash, expiry, payment eligibility, and run state.
• Atomically claim actions before execution.
• Reuse one provider idempotency key per action.
• Reconcile unknown provider outcomes before retrying.

Budgets:

• Maximum 8 model calls and 12 tool calls per run.
• $0.25 run budget and $10 tenant daily budget.
• Atomically reserve bounded costs before dispatch.
• Settle actual usage and retain unresolved reservations.
• Suspend workers while awaiting approval.

UI:

• Run list, approval inbox, action details, redacted event timeline.
• Cancel control that blocks future dispatches.
• Clearly label mock actions and unknown provider outcomes.

Add automated tests for cross-tenant access, expired approvals, changed payloads, concurrent execution, budget races, and timeouts. Explain deployment requirements and any unimplemented controls. ```

Перед подключением реального инструмента записи проверьте:

• [ ] Пользователь тенанта A не может прочитать или согласовать действие тенанта B.
• [ ] Вредоносный тикет не может вызвать незарегистрированный инструмент.
• [ ] Изменение аргументов аннулирует согласование.
• [ ] Пользователь с истекшими или отозванными правами не может подтвердить выполнение.
• [ ] Параллельные воркеры выполняют только одну внешнюю операцию.
• [ ] Одновременные резервирования не могут превысить установленный лимит.
• [ ] При таймауте запускается процесс сверки, а не слепая повторная отправка.
• [ ] Отмена прогона предотвращает отправку новых запросов.
• [ ] Логи не содержат учетных данных или лишней конфиденциальной информации.

Внедряйте в три этапа: моковые действия, затем реальное чтение с предложениями записи, затем один реальный инструмент записи для внутренних операторов. Расширяйте функционал только после анализа реальных отказов, затрат и спорных ситуаций.

Может ли системный промпт предотвратить prompt injection?

Нет. Системный промпт задает направление, но непроверенные тикеты, документы и веб-страницы все равно могут повлиять на модель. Относитесь к вызовам tools от модели как к ненадежным запросам. Права на бэкенде, строгие схемы данных, разграничение доступа и подтверждения действий локализуют ущерб, если инструкции модели будут нарушены.

Требует ли каждое действие агента подтверждения человеком?

Нет. Разрешенное чтение и обратимые черновики обычно могут выполняться автоматически. Начните с обязательного согласования для денежных операций, внешних сообщений, деструктивных действий и изменений прав доступа. Любое автоматическое исключение должно быть узким, измеримым и контролироваться за пределами самой модели.

Сколько стоят гардрейлы для AI-агентов?

При планировании закладывайте 6-12 инженерных часов на описанный базовый мок-прототип, плюс дополнительное время на реальные интеграции и аудит безопасности. Небольшое дев-окружение может требовать от $25 до $75 в месяц на бэкенд и воркеры, не считая Lovable, вызовов моделей и платных API. Сверяйтесь с актуальными тарифами провайдеров: основная статья расходов на раннем этапе - это разработка и тестирование, а не экран согласования.