Votre agent ne peut pas dépasser ce que vous avez défini.
Définissez une allocation par période et un plafond par transaction pour chaque agent dans le tableau de bord. Le backend l'applique à chaque paiement sortant - le code de l'agent ne peut pas le contourner.
Les agents autonomes font des erreurs. Ils réessaient. Ils bouclent. Ils sont injectés par des prompts. Ils essaient parfois de dépenser de l'argent que vous n'avez pas autorisé.
Une autorisation de dépense Blockchain0x est définie par le propriétaire dans le tableau de bord et appliquée par le backend, pas par le code de l'agent. Chaque paiement sortant est vérifié par rapport à l'autorisation active avant que l'API ne l'accepte, donc l'agent ne peut pas dépasser la limite même si sa logique essaie. Votre code peut lire l'autorisation via l'API pour l'afficher ou planifier autour, mais il ne peut pas l'augmenter.
Quatre dimensions. Définies une fois. Appliquées partout.
Allocation sur une période
allowance_wei est le total USDC (unités de base) que l'agent peut envoyer sur une fenêtre de period_seconds. La période est d'un jour (86400), d'une semaine (604800) ou de 30 jours (2592000).
Plafond par transaction
per_tx_wei est le plus grand paiement sortant unique autorisé. Cela empêche un appel erroné de déplacer plus que ce que vous aviez prévu, indépendamment de l'allocation de période.
Fenêtre de validité
start_at et end_at délimitent quand la permission est active. En dehors de la fenêtre, cela n'autorise pas les dépenses, donc vous pouvez pré-stager un budget ou laisser l'un expirer de lui-même.
Révocation
revoked_at enregistre quand une permission a été désactivée depuis le tableau de bord. La révocation ramène l'allocation à zéro immédiatement pour tout paiement évalué après cela.
La clé de l'agent ne peut pas augmenter sa propre limite.
Vous créez, modifiez et révoquez les permissions de dépense dans le tableau de bord. L'API les expose en lecture seule - il n'y a pas de point de terminaison et aucune méthode SDK qui modifie une permission. C'est tout l'enjeu : si l'agent est injecté par une invite ou coincé dans une boucle, il ne peut pas élargir sa propre allocation, car le certificat qu'il détient ne lui a jamais été accordé.
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 agent gère ce rejet comme tout autre appel échoué, et vous voyez la tentative dans le tableau de bord afin de pouvoir élargir l'autorisation si elle était légitime.
Récupérez l'autorisation actuelle pour l'afficher ou planifier autour.
GET /v1/agents/{id}/spend-permissions retourne les valeurs en direct. Utilisez-le pour afficher un budget dans votre interface utilisateur, ou pour permettre à l'agent de vérifier combien de marge il reste avant d'essayer un paiement.
curl https://api.blockchain0x.com/v1/agents/agt_123/spend-permissions \
-H "Authorization: Bearer $BLOCKCHAIN0X_API_KEY"{
"allowance_wei": "5000000",
"per_tx_wei": "1000000",
"period_seconds": 86400,
"start_at": "2026-05-15T00:00:00Z",
"end_at": null,
"revoked_at": null
}allowance_weiTotal spend allowed per period, in USDC base units (6 decimals). "5000000" is 5 USDC.
per_tx_weiLargest single payment allowed, in base units. "1000000" is 1 USDC. A payment over this is rejected even if the period allowance has room.
period_secondsLa fenêtre à laquelle l'allocation s'applique : 86400 (jour), 604800 (semaine) ou 2592000 (30 jours).
start_at / end_atLorsque l'autorisation est active. end_at est nul pour une autorisation ouverte.
revoked_atNull pendant l'activation ; un horodatage une fois révoqué depuis le tableau de bord. Une autorisation révoquée n'autorise rien.
Jour, semaine ou 30 jours.
period_seconds prend l'une des trois valeurs. L'allocation se réinitialise lorsque la période se termine ; per_tx_wei s'applique à chaque paiement unique indépendamment de la période.
864001 jour
6048001 semaine
259200030 jours
Une autorisation de dépense est une limite stricte, définie une fois, appliquée partout - pas un flux d'approbation par paiement et pas une confirmation humaine dans la boucle. Si vous avez besoin d'approbations ou de signatures multiples, c'est un modèle séparé et plus lourd ; l'autorisation est le sol toujours actif en dessous.