Настройте контроль расходов агентов, который выдерживает инъекции команд.
Установите разрешение на расходы в панели управления - лимит на период плюс лимит на транзакцию - и бэкенд применяет его к каждому платежу. Поскольку оно находится на бэкенде, а API является только для чтения, инъекция подсказок, которая захватывает планировщик агента, все равно не может повысить лимит. Ваш код считывает разрешение через API, чтобы отобразить его или спланировать вокруг него.
Перед тем как начать.
- Существующий агент (см. руководство по добавлению платежей к агенту).
- Доступ к панели управления для рабочего пространства, которому принадлежит агент - разрешения устанавливаются там, а не через API.
- Приблизительная идея ожидаемых ежедневных расходов - разрешение должно составлять 2-3x нормального использования, а не 100x, чтобы оно действительно несло нагрузку.
- API-ключ для чтения разрешения (ключ
sk_test_подходит для этого руководства). - Знание концепции политики расходов агента - это руководство является ее операционным аналогом.
Установите разрешение в панели управления.
Откройте агента в панели управления Blockchain0x и установите два числа: лимит на период (день, неделя или 30 дней) и лимит на транзакцию. Лимит ограничивает худший случай за весь период; лимит на транзакцию предотвращает одновременное расходование всей суммы одним аномальным запросом. Это действие на панели управления сделано намеренно - это установленная человеком граница, в пределах которой работает агент.
Amounts are USDC base units (6 decimals). An allowance_wei of "20000000" is 20 USDC; a per_tx_wei of "2000000" is 2 USDC. The period is a period_seconds value: 86400 for a day, 604800 for a week, 2592000 for 30 days.
Читать разрешение через API.
Ваш код может получить текущие разрешения, чтобы показать их в интерфейсе или позволить агенту проверить, сколько места осталось, прежде чем он попытается сделать платеж. Маршрут является только для чтения - нет конечной точки для изменения, что именно и объясняет, почему ключ агента не может расширить свой собственный лимит.
curl https://api.blockchain0x.com/v1/agents/agt_123/spend-permissions \
-H "Authorization: Bearer $BLOCKCHAIN0X_API_KEY"{
"allowance_wei": "20000000",
"per_tx_wei": "2000000",
"period_seconds": 86400,
"start_at": "2026-05-15T00:00:00Z",
"end_at": null,
"revoked_at": null
}Привязать это во времени или отозвать.
Два поля превращают разрешение в контроль с ограничением по времени. start_at и end_at устанавливают окно, в котором оно активно, так что вы можете заранее установить бюджет для запланированной задачи или позволить ему истечь самостоятельно; за пределами окна оно ничего не авторизует. revoked_at - это выключатель: отмените с панели управления, и разрешение упадет до нуля для любого платежа, оцененного позже.
Для более жесткой остановки отозовите или измените ключ API агента с помощью apiKeys.revoke или apiKeys.rotate - это полностью отключает учетные данные, а не только расходы. Отзыв разрешения - это хирургический шаг; отзыв ключа - это аварийный выключатель.
Обработайте платеж, который достигает лимита.
Когда платеж превышает активное разрешение, сервер отклоняет его, прежде чем что-либо коснется цепочки - средства не перемещаются. Ваш вызов payments.create возвращает ошибку; обрабатывайте его как любой другой неудавшийся вызов, сообщите об этом вашему оператору и не пытайтесь повторно выполнить его бездумно в ту же стену.
Чтобы увидеть, что пытался сделать агент, смотрите журнал активности на панели управления и согласуйте реальные движения с transactions.get. Всплеск отклоненных попыток - это ваш сигнал раннего предупреждения: либо неправильно настроенное разрешение, либо бесконтрольный цикл, либо зонд инъекции. Подайте сигнал так же, как вы бы сделали это при любом всплеске неудачных вызовов.
Пять ошибок, которые подрывают контроль.
Установка лимита расходов в коде агента вместо бэкенда
Правила расходов в планировщике агента или системной подсказке не являются границами безопасности. Атака с инъекцией подсказок, которая переопределяет планировщик, также переопределяет лимит. Основная идея разрешения на расходы заключается в том, что оно находится вне манипулируемой области агента - на бэкенде, установленном в панели управления - так что агент не может его изменить. Настройте это там, а не с помощью 'скажите агенту не тратить больше $X'.
Ожидание, что API-ключ агента расширит лимит
API доступен только для чтения для разрешений на расходы: нет конечной точки и нет метода SDK, который увеличивает лимит. Это сделано намеренно. Если скомпрометированный или внедренный агент мог бы вызвать изменяющую конечную точку с ключом, который он уже имеет, контроль был бы бесполезен. Чтобы изменить лимит, вы используете панель управления, где изменение является человеческим действием с аудиторским следом.
Установка лимита так высоко, что он никогда не сработает
Разрешение защищает вас только в том случае, если оно несет нагрузку. Разрешение, установленное на 100x нормального использования, не остановит runaway loop, пока оно не потратит гораздо больше, чем вы хотели бы. Установите размер разрешения и лимит на транзакцию примерно в 2-3 раза больше ожидаемого использования, затем расширьте его намеренно, если реальный трафик докажет, что это необходимо.
Забывая о лимите на каждую транзакцию
allowance_wei ограничивает худший случай за весь period; per_tx_wei ограничивает любой отдельный payment. Это разные задачи. Щедрый period allowance без cap на одну транзакцию все равно позволяет одному аномальному запросу - buggy retry, maliciously-quoted price - перевести большую сумму одним разом. Задайте оба ограничения.
Быстрый выключатель не репетировался
Когда что-то выглядит неправильно в 2 часа ночи, вы хотите сделать движение, которое вы уже отработали. Существуют два варианта: отозвать разрешение на панели управления (устанавливает revoked_at, лимит на ноль) или отозвать/поменять API-ключ агента с помощью apiKeys.revoke / apiKeys.rotate (полностью обрезает учетные данные). Знайте, к какому из них вы обращаетесь, и что вы можете сделать это быстро.
После того, как разрешение будет установлено.
С действующим разрешением наиболее полезные последующие действия - это надежная обработка вебхуков (чтобы события платежей действительно достигали вашего обработчика), верификация личности (чтобы контрагенты доверяли профилю агента) и предварительный обзор безопасности (чтобы вы не оставили другую дверь открытой).
Шаблоны вебхуков, о которых разработчики спрашивают чаще всего
Заработайте значки проверки GitHub и домена
Обеспечьте безопасность вашего агентского кошелька перед запуском
Полная справка на docs.blockchain0x.com. Продуктовая поверхность: Контроль расходов.