Imposta controlli di spesa per agenti che sopravvivono all'iniezione di prompt.
Imposta un permesso di spesa nel dashboard - un'indennità per periodo più un limite per transazione - e il backend lo applica su ogni pagamento. Poiché vive nel backend e l'API è di sola lettura, l'iniezione di prompt che hijacks il pianificatore dell'agente non può comunque aumentare il limite. Il tuo codice legge il permesso tramite l'API per visualizzarlo o pianificare attorno ad esso.
Prima di iniziare.
- Un agente esistente (vedi la guida-add-payments-to-agent).
- Accesso al dashboard per lo spazio di lavoro che possiede l'agente - i permessi sono impostati lì, non tramite l'API.
- Un'idea approssimativa della spesa giornaliera prevista - l'assegnazione dovrebbe essere 2-3 volte l'uso normale, non 100 volte, quindi è effettivamente portante.
- Una chiave API per leggere il permesso (una chiave
sk_test_va bene per questa guida). - Familiarità con il concetto di politica di spesa dell'agente - questa guida è il suo corrispondente operativo.
Imposta il permesso nel dashboard.
Apri l'agente nel dashboard di Blockchain0x e imposta due numeri: un'indennità su un periodo (un giorno, una settimana o 30 giorni) e un limite per transazione. L'indennità limita il peggior caso su tutto il periodo; il limite per transazione impedisce a una singola richiesta anomala di spendere tutto in una volta. Questa è un'azione del dashboard per scelta - è il confine impostato dall'uomo all'interno del quale l'agente opera.
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.
Leggi il permesso tramite l'API.
Il tuo codice può recuperare il permesso attivo per mostrarlo in un'interfaccia utente o per consentire all'agente di controllare quanto spazio è rimasto prima di provare un pagamento. La rotta è in sola lettura - non esiste un endpoint di modifica, ed è esattamente per questo che la chiave dell'agente non può ampliare il proprio limite.
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
}Vincolalo nel tempo, o revocalo.
Due campi trasformano il permesso in un controllo limitato nel tempo. start_at e end_at impostano la finestra in cui è attivo, quindi puoi preimpostare un budget per un lavoro programmato o lasciare che uno scada da solo; al di fuori della finestra non autorizza nulla. revoked_at è l'interruttore di emergenza: revoca dalla dashboard e l'assegnazione scende a zero per qualsiasi pagamento valutato successivamente.
Per una fermata più decisa, revoca o ruota la chiave API dell'agente con apiKeys.revoke o apiKeys.rotate - questo taglia completamente la credenziale, non solo la spesa. La revoca del permesso è la mossa chirurgica; la revoca della chiave è l'interruttore di emergenza.
Gestisci un pagamento che raggiunge il limite.
Quando un pagamento supererebbe il permesso attivo, il backend lo rifiuta prima che qualcosa tocchi la catena - nessun fondo si muove. La tua chiamata payments.create restituisce un errore; gestiscilo come qualsiasi altra chiamata fallita, portalo all'attenzione del tuo operatore e non riprovare ciecamente contro lo stesso muro.
Per vedere cosa ha tentato un agente, controlla il registro delle attività della dashboard e riconcilia i movimenti reali con transactions.get. Un'esplosione di tentativi rifiutati è il tuo segnale di allerta precoce: o un'assegnazione mal configurata, un ciclo infinito o una sonda di iniezione. Allerta allo stesso modo in cui faresti per qualsiasi picco di chiamate fallite.
Cinque errori che annullano il controllo.
Mettere il limite di spesa nel codice dell'agente invece che nel backend
Le regole di spesa nel pianificatore dell'agente o nel prompt di sistema non sono confini di sicurezza. Un attacco di iniezione di prompt che sovrascrive il pianificatore sovrascrive anche il limite. Il punto principale di un permesso di spesa è che vive al di fuori dell'ambito manipolabile dell'agente - nel backend, impostato nel dashboard - quindi l'agente non può cambiarlo. Configuralo lì, non con 'dici all'agente di non spendere più di $X'.
Aspettando che la chiave API dell'agente allarghi il limite
L'API è di sola lettura per i permessi di spesa: non esiste un endpoint e nessun metodo SDK che aumenti un'indennità. Questo è deliberato. Se un agente compromesso o iniettato potesse chiamare un endpoint di mutazione con la chiave che già possiede, il controllo sarebbe inutile. Per cambiare un limite utilizzi il dashboard, dove la modifica è un'azione umana con una traccia di audit.
Impostare un'indennità così alta che non morde mai
Un permesso ti protegge solo se è portante. Un'assegnazione impostata a 100 volte l'uso normale non fermerà un ciclo incontrollato finché non ha già speso molto più di quanto avresti voluto. Dimensiona l'assegnazione e il limite per transazione a circa 2-3 volte l'uso previsto, quindi allarga deliberatamente se il traffico reale dimostra che ne hai bisogno.
Dimenticando il limite per transazione
allowance_wei limita il peggior caso su tutto il periodo; per_tx_wei limita qualsiasi pagamento singolo. Svolgono lavori diversi. Un'assegnazione periodica generosa senza limite per transazione consente comunque a una richiesta anomala - un tentativo difettoso, un prezzo citato in modo malevolo - di muovere una grande quantità in un colpo solo. Imposta entrambi.
Nessun kill switch veloce provato
Quando qualcosa sembra sbagliato alle 2 del mattino, vuoi un'azione che hai già praticato. Ne esistono due: revocare il permesso nel dashboard (imposta revoked_at, allowance a zero), oppure revocare ruotare la chiave API dell'agente con apiKeys.revoke / apiKeys.rotate (taglia completamente la credenziale). Sappi quale scegliere e che puoi farlo rapidamente.
Dopo che il permesso è stato concesso.
Con il permesso applicato, i seguiti che rendono di più sono la gestione affidabile dei webhook (così gli eventi di pagamento raggiungono effettivamente il tuo gestore), la verifica dell'identità (così le controparti si fidano del profilo dell'agente) e una revisione della sicurezza pre-lancio (così non hai lasciato un'altra porta aperta).
I modelli di webhook di cui i programmatori chiedono di più
Guadagna i badge di verifica di GitHub e del dominio
Metti in sicurezza il tuo portafoglio agente prima di andare live
Riferimento completo su docs.blockchain0x.com. Superficie di prodotto: Controlli di spesa.