Wat is een agent bestedingsbeleid.
Een agent bestedingsbeleid is de set van regels die zijn gekoppeld aan een AI-agent portemonnee die bepalen wat de agent mag betalen - een toelage per periode (dagelijks, wekelijks of maandelijks), een limiet per transactie, en een geldigheidsvenster van start- en einddata. Het beleid wordt ingesteld in het dashboard en afgedwongen op de portemonnee API-laag (buiten de manipuleerbare scope van de agent), gecontroleerd bij elke betaling voordat deze wordt afgehandeld. De API stelt het alleen-lezen beschikbaar.
Het enige dat autonome betalingen veilig maakt.
Zonder een uitgavenbeleid, het geven van een agent een wallet is het geven van een LLM onbeperkte toegang tot een dollar-genoteerde cheque. Twee foutmodi zijn onvermijdelijk. De eerste is de runaway loop: de planner van een agent raakt vast bij het opnieuw proberen van een betaalde tool en verbrandt het saldo van de werkruimte in enkele minuten. De tweede is promptinjectie: een aanvaller overtuigt de agent om een aanvaller-gecontroleerde wallet te betalen onder het mom van een normale taak.
Een bestedingsbeleid begrenst beide faalmodi bij constructie. De ongecontroleerde lus verbruikt de periodetoelage en stopt. De geïnjecteerde betaling overschrijdt de limiet per transactie (of de resterende toelage) en wordt nooit afgehandeld. De agent hoeft niet perfect betrouwbaar te zijn omdat de portemonnee weigert iets buiten het beleid af te handelen. Dit is het verschil tussen 'agents die betalen' die in productie bruikbaar zijn en een experiment zijn.
Configureer één keer, evalueer elke aanroep.
- Configureer. De menselijke gebruiker stelt het beleid in het dashboard in: een periodieke toelage, een per-transactie limiet, en een optionele geldigheidsperiode (start- en einddata). De API stelt het beleid alleen-lezen beschikbaar; wijzigingen worden gelogd.
- Bind aan identiteit. Het beleid is gekoppeld aan de betalingsidentiteit van de agent. Multi-agent werkruimtes hebben één beleid per agent, plus optioneel een werkruimteniveau limiet die de som begrenst.
- Evalueer bij elke intentie. Wanneer de agent een betalingsintentie indient (typisch aangedreven door een 402-respons), voert de wallet API het beleid uit: controleer de per-transactie limiet, controleer de resterende periodieke toelage, controleer de geldigheidsperiode.
- Verreken of weiger. Als alle controles slagen, verreken de wallet de betaling en vermindert de resterende toelage. Als een controle faalt, weigert de wallet de betaling (het overschrijdt een limiet of valt buiten het venster) en verreken niet.
- Audit. Elke geaccepteerde en elke afgewezen intentie wordt gelogd met de beleidsbeslissing eraan gekoppeld. De mens kan het logboek op elk moment bekijken om te zien wat de agent heeft geprobeerd en wat het beleid heeft toegestaan.
Het beleid is hetzelfde soort object ongeacht hoeveel agenten de wallet delen. Per-agent beleid isoleert budgetten schoon; een werkruimtebeleid op het niveau van de ouder past een strikte limiet toe over alle kindagenten samen.
Drie beleidsstructuren die we in productie zien.
Per-agent dagelijkse limiet met een plafond voor enkele oproepen
Een onderzoeksagent heeft een limiet van $5/dag en een plafond van $0,50/oproep. Het kan 10 oproepen van $0,50 doen, of 100 oproepen van $0,05, of een combinatie daaronder binnen het dagelijkse totaal. Een verrassingsfactuur van $2,00 van een tool wordt afgewezen bij het oproepplafond voordat deze ooit wordt afgewikkeld. Beide limieten worden gelijktijdig afgedwongen; de striktere wint per oproep.
Ontvang alleen lockdown
Een agent die alleen maar betalingen ontvangt, heeft zowel zijn toelage als limiet per transactie op nul ingesteld. Hij kan door iedereen op elk moment worden betaald, maar hij kan helemaal geen USDC verzenden - ongeacht wat zijn code of een prompt-injectie probeert te laten doen. Beide limieten op nul instellen is de sterkste verdediging tegen betaling omleiding door prompt-injectie: de portemonnee weigert elke uitgaande betaling.
Tijdgebonden betrokkenheidsvenster
Een contractagent krijgt een uitgaven toestemming die alleen geldig is voor het 30-dagen venster van de betrokkenheid (een start- en einddatum). Binnen het venster kan het tot zijn wekelijkse toelage uitgeven; na de einddatum verloopt de toestemming en wordt er geen verdere betaling verrekend, zonder dat iemand zich hoeft te herinneren om het uit te schakelen.
Waar dit past.
Agent betalingsidentiteit
De agentidentiteit waaraan het uitgavenbeleid wordt gekoppeld. Eén identiteit, één beleid, één budgetkader.
Agent-naar-agent betaling
De flow waarvoor het uitgavenbeleid het meest nuttig is, omdat de tegenpartij zelf een autonome agent is.
Betaald MCP-hulpmiddel
De toolcategorie waarop uitgavenbeleid het vaakst van toepassing is. De 402-quote wordt vóór settlement tegen het beleid gecontroleerd.