Passer au contenu principal
ApprendreGlossairePolitique de dépenses de l'agent
GLOSSAIRE

Qu'est-ce qu'une politique de dépenses d'agent.

DÉFINITION

Une politique de dépenses d'agent est l'ensemble des règles attachées à un portefeuille d'agent IA qui régissent ce que l'agent est autorisé à payer - une allocation par période (quotidienne, hebdomadaire ou mensuelle), un plafond par transaction et une fenêtre de validité avec des dates de début et de fin. La politique est définie dans le tableau de bord et appliquée au niveau de l'API du portefeuille (en dehors du champ manipulable de l'agent), vérifiée à chaque paiement avant qu'il ne soit réglé. L'API l'expose en lecture seule.

POURQUOI C'EST IMPORTANT

La seule chose qui rend le paiement autonome sûr.

Sans une politique de dépenses, donner à un agent un portefeuille revient à donner à un LLM un accès illimité à un chéquier libellé en dollars. Deux modes de défaillance sont inévitables. Le premier est la boucle incontrôlée : le planificateur d'un agent reste bloqué à réessayer un outil payant et épuise le solde de l'espace de travail en quelques minutes. Le second est l'injection de prompt : un attaquant convainc l'agent de payer un portefeuille contrôlé par l'attaquant sous couvert de ressembler à une tâche normale.

Une politique de dépense limite les deux modes d'échec par construction. La boucle incontrôlable épuise l'allocation de période et s'arrête. Le paiement injecté dépasse le plafond par transaction (ou l'allocation restante) et ne se règle jamais. L'agent n'a pas besoin d'être parfaitement digne de confiance car le portefeuille refuse de régler quoi que ce soit en dehors de la politique. C'est la différence entre 'les agents qui paient' étant utilisables en production et étant une expérience.

COMMENT ÇA MARCHE

Configurez une fois, évaluez chaque appel.

  1. Configurer. L'utilisateur humain définit la politique dans le tableau de bord : une allocation par période, un plafond par transaction et une fenêtre de validité optionnelle (dates de début et de fin). L'API expose la politique en lecture seule ; les modifications sont enregistrées dans un audit.
  2. Lier à l'identité. La politique s'attache à l'identité de paiement de l'agent. Les espaces de travail multi-agents ont une politique par agent, plus éventuellement un plafond au niveau de l'espace de travail qui limite la somme.
  3. Évaluer à chaque intention. Lorsque l'agent soumet une intention de paiement (généralement déclenchée par une réponse 402), l'API du portefeuille exécute la politique : vérifiez le plafond par transaction, vérifiez l'allocation restante par période, vérifiez la fenêtre de validité.
  4. Régler ou rejeter. Si toutes les vérifications passent, le portefeuille règle le paiement et décrémente l'allocation restante. Si une vérification échoue, le portefeuille rejette le paiement (il dépasse une limite ou tombe en dehors de la fenêtre) et ne règle pas.
  5. Audit. Chaque intention acceptée et chaque intention rejetée est enregistrée avec la décision de politique jointe. L'humain peut consulter le journal à tout moment pour voir ce que l'agent a tenté et ce que la politique a permis.

La politique est le même type d'objet peu importe combien d'agents partagent le portefeuille. Les politiques par agent isolent proprement les budgets ; une politique d'espace de travail au niveau parent applique un plafond strict à tous les agents enfants combinés.

EXEMPLES

Trois formes de politique que nous voyons en production.

EXEMPLE 1

Plafond quotidien par agent avec plafond d'appel unique

Un agent de recherche a un plafond de 5 $/jour et un plafond de 0,50 $/appel. Il peut effectuer 10 appels de 0,50 $, ou 100 appels de 0,05 $, ou toute combinaison sous le total quotidien. Une facture surprise de 2,00 $ d'un outil est rejetée au plafond d'appel avant de se régler. Les deux limites s'appliquent simultanément ; la plus stricte l'emporte par appel.

EXEMPLE 2

Verrouillage en réception seule

Un agent qui ne reçoit que des paiements a son allocation et son plafond par transaction tous deux fixés à zéro. Il peut être payé par n'importe qui à tout moment, mais il ne peut pas envoyer de USDC du tout - peu importe ce que son code ou une injection de prompt essaie de lui faire faire. Fixer les deux limites à zéro est la défense la plus forte contre la redirection de paiement par injection de prompt : le portefeuille refuse chaque paiement sortant.

EXEMPLE 3

Fenêtre d'engagement limitée dans le temps

Un agent contractuel se voit attribuer une autorisation de dépense qui n'est valide que pour la fenêtre de 30 jours de l'engagement (une date de début et de fin). Dans la fenêtre, il peut dépenser jusqu'à son allocation hebdomadaire ; après la date de fin, l'autorisation expire et aucun paiement supplémentaire ne se règle, sans que personne n'ait à se souvenir de l'éteindre.

FAQ

Trois questions courantes.

Quelle est la différence entre une politique de dépenses et une limite de taux ?

Une limite de taux régit le nombre d'appels ; une politique de dépenses régit la valeur en dollars des appels. Un agent peut être limité à 100 appels par minute mais peut quand même faire faillite dans son espace de travail si ces appels coûtent chacun 1 $ et que l'agent les effectue pendant une heure. Une politique de dépenses limite l'exposition en dollars indépendamment du nombre d'appels. Les deux contrôles se complètent - les limites de taux empêchent les dénis de service sur l'exécution de l'agent, les politiques de dépenses empêchent les dénis de fonds sur le portefeuille de l'agent.

Où la politique est-elle appliquée - dans le code de l'agent ou dans le portefeuille ?

Dans le portefeuille, sur la couche API de paiement. L'appliquer dans le code de l'agent signifierait qu'une attaque par injection de prompt qui contourne le planificateur de l'agent contourne également le budget. En l'appliquant dans l'API du portefeuille, la politique est en dehors du champ manipulable de l'agent. L'agent soumet une intention de paiement ; le portefeuille évalue l'intention par rapport à la politique ; le portefeuille règle ou rejette. L'agent ne peut pas augmenter ses propres limites.

L'utilisateur peut-il ajuster la politique en cours de route si une dépense légitime est rejetée ?

Oui, mais seul l'utilisateur humain (ou un autre humain autorisé) peut l'ajuster - jamais l'agent lui-même. Le panneau d'administration du portefeuille expose l'éditeur de politique ; les changements sont enregistrés dans un journal d'audit avec qui et quand. Cela garde l'agent dans des limites par défaut tout en donnant à l'humain l'override dont il a besoin lorsqu'une dépense légitime plus importante se présente. L'agent n'a pas la possibilité de demander 'veuillez augmenter ma limite' dans sa boucle de planification, car cela contredirait l'objectif d'avoir une limite.
Dernière révision : 2026-05-15. Publié sous CC BY 4.0.

Donnez à votre agent une enveloppe budgétaire.

Allocations par période et plafonds par transaction, définis dans le tableau de bord. Gratuit pour commencer.