Stel uitgavencontroles voor agents in die promptinjectie overleven.
Stel een uitgaven toestemming in het dashboard in - een toelage per periode plus een limiet per transactie - en de backend handhaaft dit op elke betaling. Omdat het op de backend leeft en de API alleen-lezen is, kan promptinjectie die de planner van de agent overneemt de limiet nog steeds niet verhogen. Je code leest de toestemming via de API om deze weer te geven of eromheen te plannen.
Voordat je begint.
- Een bestaande agent (zie de add-payments-to-agent gids).
- Dashboardtoegang voor de werkruimte die de agent bezit - machtigingen worden daar ingesteld, niet via de API.
- Een ruwe schatting van de verwachte dagelijkse uitgaven - de toelage zou 2-3x normaal gebruik moeten zijn, niet 100x, zodat deze daadwerkelijk dragend is.
- Een API-sleutel om de machtiging te lezen (een
sk_test_sleutel is prima voor deze gids). - Bekendheid met het agent uitgavenbeleid concept - deze gids is de operationele tegenhanger.
Stel de toestemming in het dashboard in.
Open de agent in het Blockchain0x-dashboard en stel twee getallen in: een toelage over een periode (een dag, een week of 30 dagen) en een per-transactie limiet. De toelage beperkt het ergste geval over de hele periode; de per-transactie limiet voorkomt dat een enkele afwijkende aanvraag alles in één keer uitgeeft. Dit is opzettelijk een dashboardactie - het is de door mensen ingestelde grens waarbinnen de agent opereert.
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.
Lees de toestemming via de API.
Je code kan de live toestemming ophalen om deze in een UI weer te geven of om de agent te laten controleren hoeveel ruimte er nog is voordat hij een betaling probeert. De route is alleen-lezen - er is geen mutatie-eindpunt, wat precies de reden is waarom de sleutel van de agent zijn eigen limiet niet kan verbreden.
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
}Bind het in de tijd, of herroep het.
Twee velden maken de toestemming tot een tijdgebonden controle. start_at en end_at stellen het venster in dat het actief is, zodat je een budget kunt voorbereiden voor een geplande taak of dat het vanzelf vervalt; buiten het venster autoriseert het niets. revoked_at is de kill switch: intrekken vanuit het dashboard en de toelating daalt naar nul voor elke betaling die daarna wordt geëvalueerd.
Voor een hardere stop, intrekken of roteren van de API-sleutel van de agent met apiKeys.revoke of apiKeys.rotate - dat snijdt de credential volledig af, niet alleen de uitgaven. Het intrekken van de machtiging is de chirurgische zet; het intrekken van de sleutel is de noodstop.
Verwerk een betaling die de limiet bereikt.
Wanneer een betaling de actieve toestemming zou overschrijden, wijst de backend deze af voordat iets de keten raakt - er verplaatst geen geld. Je payments.create-aanroep retourneert een fout; behandel het zoals elke andere mislukte oproep, breng het onder de aandacht van je operator, en probeer niet blindelings in dezelfde muur te herhalen.
Om te zien wat een agent heeft geprobeerd, bekijk je het activiteitenlogboek van het dashboard en reconciliëer je echte bewegingen met transactions.get. Een uitbarsting van afgewezen pogingen is je vroegtijdige waarschuwing: ofwel een verkeerd geconfigureerde toelating, een runaway loop, of een injectieproef. Waarschuw ervoor op dezelfde manier als je zou doen bij elke piek van mislukte oproepen.
Vijf fouten die de controle ondermijnen.
Het plaatsen van de uitgavenlimiet in agentcode in plaats van de backend
Uitgavenregels in de planner van de agent of systeemprompt zijn geen beveiligingsgrenzen. Een prompt-injectieaanval die de planner overschrijft, overschrijft ook de limiet. Het hele punt van een uitgaven toestemming is dat deze buiten de manipuleerbare scope van de agent leeft - op de backend, ingesteld in het dashboard - zodat de agent het niet kan wijzigen. Configureer het daar, niet met 'zeg de agent dat hij niet meer dan $X mag uitgeven'.
Verwacht dat de API-sleutel van de agent de limiet verbreedt
De API is alleen-lezen voor uitgaven toestemmingen: er is geen eindpunt en geen SDK-methode die een toelage verhoogt. Dat is opzettelijk. Als een gecompromitteerde of geïnjecteerde agent een mutatie-eindpunt zou kunnen aanroepen met de sleutel die hij al heeft, zou de controle waardeloos zijn. Om een limiet te wijzigen gebruik je het dashboard, waar de wijziging een menselijke actie is met een audittrail.
Een toelage instellen die zo hoog is dat het nooit problemen oplevert
Een toestemming beschermt je alleen als deze dragend is. Een toelage ingesteld op 100x normaal gebruik zal een runaway loop niet stoppen totdat deze al veel meer heeft uitgegeven dan je zou willen. Stel de toelage en de per-transactie limiet in op ongeveer 2-3x het verwachte gebruik, en verbreed deze opzettelijk als echt verkeer aantoont dat je dat nodig hebt.
Vergeten de per-transactie limiet
allowance_wei beperkt de slechtste situatie over de hele periode; per_tx_wei beperkt elke enkele betaling. Ze doen verschillende taken. Een genereuze periode-toelating zonder per-transactie limiet laat nog steeds één anomal verzoek toe - een buggy herhaling, een kwaadwillig geciteerd prijs - verplaatst een groot bedrag in één keer. Stel beide in.
Geen snelle kill switch geoefend
Wanneer er iets verkeerd uitziet om 2 uur 's nachts, wil je een actie die je al hebt geoefend. Er zijn er twee: trek de toestemming in het dashboard in (stelt revoked_at in, toelaatbaarheid op nul), of trek/roteer de API-sleutel van de agent met apiKeys.revoke / apiKeys.rotate (snijdt de referentie volledig af). Weet welke je moet gebruiken en dat je het snel kunt doen.
Nadat de toestemming is ingesteld.
Met de toestemming afgedwongen, zijn de vervolgacties die het meest opleveren betrouwbare webhook-afhandeling (zodat betalingsgebeurtenissen daadwerkelijk je handler bereiken), identiteitsverificatie (zodat tegenpartijen het profiel van de agent vertrouwen), en een beveiligingsreview voor de lancering (zodat je geen andere deur open hebt gelaten).
De webhook-patronen waar ontwikkelaars het meest naar vragen
Verdien de GitHub- en domeinverificatiebadges
Beveilig je agent wallet voordat je live gaat
Volledige referentie op docs.blockchain0x.com. Productoppervlak: Uitgavencontroles.