Passer au contenu principal
CONTRÔLES DE DÉPENSES

Define limits before delegating payment access.

Review how payment limits are evaluated and which paths are covered by enforcement. Set an allowance per period and a per-transaction cap on each agent in the dashboard.

Vue du tableau de bord : permissions de dépense par agent - allocation, plafond par transaction, période

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é.

An AgentCredia spend permission is owner-set in the dashboard and enforced by the backend, not by the agent's code. Every outbound payment is checked against the active permission before the API accepts it, so a payment above the limit is rejected even if the agent's logic tries to send it. Your code can read the permission over the API to display it or plan around it, but it cannot raise it.

CE QUE PERMET UNE AUTORISATION DE DÉPENSE

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.

GESTION PAR TABLEAU DE BORD, EN LECTURE SEULE VIA L'API

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.

LIRE VIA L'API

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.

LIRE (CURL)
curl https://api.agentcredia.com/v1/agents/agt_123/spend-permissions \
  -H "Authorization: Bearer $AGENTCREDIA_API_KEY"
RÉPONSE
{
  "allowance_wei": "5000000",
  "per_tx_wei": "1000000",
  "period_seconds": 86400,
  "start_at": "2026-05-15T00:00:00Z",
  "end_at": null,
  "revoked_at": null
}
allowance_wei

Total spend allowed per period, in USDC base units (6 decimals). "5000000" is 5 USDC.

per_tx_wei

Largest single payment allowed, in base units. "1000000" is 1 USDC. A payment over this is rejected even if the period allowance has room.

period_seconds

La fenêtre à laquelle l'allocation s'applique : 86400 (jour), 604800 (semaine) ou 2592000 (30 jours).

start_at / end_at

Lorsque l'autorisation est active. end_at est nul pour une autorisation ouverte.

revoked_at

Null pendant l'activation ; un horodatage une fois révoqué depuis le tableau de bord. Une autorisation révoquée n'autorise rien.

LA PÉRIODE

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.

86400

1 jour

604800

1 semaine

2592000

30 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.

QUESTIONS FRÉQUEMMENT POSÉES

Cinq questions sur les autorisations de dépense que se posent les opérateurs.

Puis-je définir ou changer une permission de dépense via l'API ?

Non. Les autorisations de dépense sont en lecture seule via l'API. Vous les créez, modifiez et révoquez dans le tableau de bord AgentCredia, et GET /v1/agents/{id}/spend-permissions permet à votre code de lire les valeurs actuelles pour les afficher ou les vérifier. C'est délibéré : la clé API de l'agent ne peut pas assouplir ses propres limites, ce qui est exactement la propriété que vous souhaitez si l'agent est jamais injecté par un prompt ou boucle. Pour augmenter une allocation, vous avez besoin du tableau de bord.

Que se passe-t-il lorsqu'un paiement dépasserait l'autorisation ?

Le backend le rejette avant que quoi que ce soit ne touche la chaîne - aucun fonds ne bouge. L'application de la règle se fait sur le backend, pas dans le code de votre agent, donc l'agent ne peut pas contourner cela même si sa logique essaie. Lisez la permission avec la route GET pour montrer à votre agent combien de place il reste, et gérez le rejet de payments.create comme vous le feriez pour tout autre appel échoué.

Pourquoi les montants sont-ils en wei plutôt qu'en dollars ?

Consistency with the rest of the API: every amount is a base-unit string. USDC has 6 decimals, so allowance_wei "5000000" is 5 USDC and per_tx_wei "1000000" is 1 USDC. Strings, not floats - large integers lose precision as JSON numbers, and a base-unit string is unambiguous across languages.

Les autorisations de dépense limitent-elles les paiements entrants ?

Non. Une autorisation ne régit que l'argent sortant du portefeuille. Les USDC entrants ne sont jamais bloqués par cela - n'importe qui peut payer votre agent à tout moment. Pensez à l'autorisation comme une vanne unidirectionnelle sur les dépenses sortantes ; le règlement entrant est confirmé séparément par le webhook payment.received.

Comment puis-je révoquer rapidement les dépenses si quelque chose semble incorrect ?

Révoquez l'autorisation dans le tableau de bord - cela définit revoked_at et ramène l'allocation à zéro pour tout paiement évalué par la suite. Pour un arrêt plus dur, vous pouvez également faire tourner ou révoquer la clé API de l'agent (apiKeys.rotate / apiKeys.revoke), ce qui coupe complètement la crédentiale. Les deux sont immédiats ; la révocation de l'autorisation est celle qui est chirurgicale, la révocation de la clé est le bouton d'arrêt.
Référence des permissions de dépense dans la documentation

Dépensez avec des limites, pas de surprises.

Définissez une allocation et un plafond par transaction dans le tableau de bord. Le backend s'occupe du reste.