Configurez des contrôles de dépenses pour les agents qui survivent à l'injection de prompt.
Définissez une autorisation de dépenses dans le tableau de bord - une allocation par période plus un plafond par transaction - et le backend l'applique à chaque paiement. Parce qu'elle vit sur le backend et que l'API est en lecture seule, l'injection de prompt qui détourne le planificateur de l'agent ne peut toujours pas augmenter la limite. Votre code lit l'autorisation via l'API pour l'afficher ou planifier autour.
Avant de commencer.
- Un agent existant (voir le ajouter-des-paiements-à-l-agent guide).
- Accès au tableau de bord pour l'espace de travail qui possède l'agent - les permissions y sont définies, pas via l'API.
- Une idée approximative des dépenses quotidiennes attendues - l'allocation devrait être de 2 à 3 fois l'utilisation normale, pas 100 fois, afin qu'elle soit réellement porteuse.
- Une clé API pour lire la permission (une clé
sk_test_convient pour ce guide). - Familiarité avec le concept de politique de dépense d'agent - ce guide en est le pendant opérationnel.
Définissez l'autorisation dans le tableau de bord.
Ouvrez l'agent dans le tableau de bord Blockchain0x et définissez deux nombres : une allocation sur une période (un jour, une semaine ou 30 jours) et un plafond par transaction. L'allocation limite le pire des cas sur toute la période ; le plafond par transaction empêche une seule demande anormale de dépenser tout d'un coup. C'est une action de tableau de bord intentionnelle - c'est la limite définie par l'humain à l'intérieur de laquelle l'agent fonctionne.
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.
Lire l'autorisation via l'API.
Votre code peut récupérer la permission en direct pour l'afficher dans une interface utilisateur ou pour permettre à l'agent de vérifier combien de place il reste avant d'essayer un paiement. La route est en lecture seule - il n'y a pas de point de terminaison de mutation, ce qui est exactement pourquoi la clé de l'agent ne peut pas élargir sa propre limite.
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
}Limitez-le dans le temps, ou révoquez-le.
Deux champs transforment la permission en un contrôle limité dans le temps. start_at et end_at définissent la fenêtre dans laquelle elle est active, vous pouvez donc pré-établir un budget pour un travail programmé ou laisser un budget expirer de lui-même ; en dehors de la fenêtre, il n'autorise rien. revoked_at est le bouton d'arrêt : révoquez depuis le tableau de bord et l'allocation tombe à zéro pour tout paiement évalué par la suite.
Pour un arrêt plus radical, révoquez ou faites tourner la clé API de l'agent avec apiKeys.revoke ou apiKeys.rotate - cela coupe complètement la crédential, pas seulement la dépense. La révocation de l'autorisation est le mouvement chirurgical ; la révocation de la clé est le bouton d'arrêt.
Gérez un paiement qui atteint la limite.
Lorsque qu'un paiement dépasserait l'autorisation active, le backend le rejette avant que quoi que ce soit touche la chaîne - aucun fonds ne bouge. Votre appel payments.create renvoie une erreur ; gérez-le comme tout autre appel échoué, signalez-le à votre opérateur et ne réessayez pas aveuglément dans le même mur.
Pour voir ce qu'un agent a tenté, regardez le journal d'activité du tableau de bord et réconciliez les mouvements réels avec transactions.get. Une série de tentatives rejetées est votre signal d'alerte précoce : soit une allocation mal configurée, une boucle incontrôlée, ou une sonde d'injection. Alertez-le de la même manière que vous le feriez pour toute augmentation d'appels échoués.
Cinq erreurs qui contrecarrent le contrôle.
Mettre le plafond de dépenses dans le code de l'agent au lieu du backend
Les règles de dépense dans le planificateur de l'agent ou le prompt système ne sont pas des frontières de sécurité. Une attaque par injection de prompt qui contourne le planificateur contourne également la limite. L'objectif d'une permission de dépense est qu'elle se situe en dehors du champ manipulable de l'agent - sur le backend, définie dans le tableau de bord - donc l'agent ne peut pas la changer. Configurez-le là, pas avec 'dites à l'agent de ne pas dépenser plus de $X'.
En attente que la clé API de l'agent élargisse la limite
L'API est en lecture seule pour les permissions de dépense : il n'y a pas de point de terminaison et aucune méthode SDK qui augmente une allocation. C'est délibéré. Si un agent compromis ou injecté pouvait appeler un point de terminaison de mutation avec la clé qu'il détient déjà, le contrôle serait sans valeur. Pour changer une limite, vous utilisez le tableau de bord, où le changement est une action humaine avec une piste d'audit.
Définir une allocation si élevée qu'elle ne mord jamais
Une autorisation ne vous protège que si elle est porteuse. Une allocation fixée à 100 fois l'utilisation normale ne stoppera pas une boucle incontrôlable jusqu'à ce qu'elle ait déjà dépensé bien plus que vous ne l'auriez souhaité. Dimensionnez l'allocation et le plafond par transaction à environ 2-3 fois l'utilisation prévue, puis élargissez délibérément si le trafic réel prouve que vous en avez besoin.
Oublier le plafond par transaction
allowance_wei délimite le pire des cas sur toute la période ; per_tx_wei délimite tout paiement unique. Ils font des travaux différents. Une allocation généreuse sur une période sans plafond par transaction permet toujours à une demande anormale - une nouvelle tentative défectueuse, un prix malicieusement cité - de déplacer un montant important en une seule fois. Définissez les deux.
Aucun interrupteur d'arrêt rapide répété
Lorsque quelque chose semble incorrect à 2 heures du matin, vous voulez un mouvement que vous avez déjà pratiqué. Deux options existent : révoquer l'autorisation dans le tableau de bord (définit revoked_at, allocation à zéro), ou révoquer/faire tourner la clé API de l'agent avec apiKeys.revoke / apiKeys.rotate (coupe complètement la crédential). Sachez laquelle vous utilisez et que vous pouvez le faire rapidement.
Après que la permission soit en place.
Avec l'autorisation appliquée, les suivis les plus rentables sont la gestion fiable des webhooks (pour que les événements de paiement atteignent réellement votre gestionnaire), la vérification d'identité (pour que les contreparties fassent confiance au profil de l'agent) et une révision de sécurité avant le lancement (pour que vous n'ayez pas laissé une autre porte ouverte).
Les modèles de webhook dont les développeurs parlent le plus
Gagnez les badges de vérification GitHub et domaine
Sécurisez votre portefeuille d'agent avant de passer en direct
Référence complète à docs.blockchain0x.com. Surface produit : Contrôles de dépense.