Ho aperto il JSON della policy di esecuzione generata e la prima cosa che ho visto è stata il tipo di forma del permesso che sembra a posto con il 2% di dimensione di test e insensata non appena c'è vera liquidità dietro.
L'agente aveva risoluzione del percorso, stato del bridge, obiettivo del vault, percorso del firmatario e una policy di scrittura che fondamentalmente faceva finta che "contract_call" fosse un permesso normale. Non lo è. È il campo della permesso creep. Quello che inizia come test di deposito e poi diventa il luogo dove qualcuno dimentica di bloccare il selettore, allarga il ruolo IAM, aggiunge logica di retry, e all'improvviso un agente autonomo può fare più di quanto il percorso avesse mai bisogno.
Volevo solo che OctoClaw toccasse un solo asset bridgeato, un solo vault ERC 4626 approvato, un solo selettore di funzione, un solo importo limitato, con revisione manuale se il gas aumentava o la mappatura del token tornava strana. Non una chiamata generica del router. Non un ruolo di esecutore di strategia con un nome amichevole. Non accesso diretto del firmatario perché “il modello conosce già il percorso.”
Il selettore era tutta la lotta.
deposit() andava bene. In termini di politica grezza, ciò significava consentire solo 0xb6b55f25 e nient'altro. Non volevo withdraw(), redeem(), rebalance(), chiamate di aiuto, sweeping del vault, auto-exit, o qualche successiva routine di “sicurezza” che viene aggiunta perché uno sviluppatore pensa che l'agente debba recuperare da un riempimento negativo da solo. Se l'agente ha bisogno di qualsiasi cosa oltre a depositare per completare il percorso, voglio che fallisca rumorosamente prima che i fondi si spostino.
La prima politica era troppo permissiva attorno al confine del firmatario. Leggi i dati di mercato, leggi lo stato del bridge, leggi lo stato del vault, va bene. Scrivi solo attraverso l'involucro ristretto. L'involucro controlla APPROVED_ASSET, APPROVED_VAULT, ALLOWED_SELECTOR, MAX_DEPOSIT, GAS_LIMIT_WEI e se AUTO_RETRY è falso prima che la chiamata arrivi in prossimità dell'esecuzione. Se qualcuno di questi è mancante, nullo, obsoleto o riempito dall'agente invece che dalla configurazione, la chiamata muore.
Ho dovuto fissarlo più a lungo di quanto mi aspettassi perché il percorso stesso sembrava corretto. EVM Bridge aveva l'asset che atterrava dove previsto, OctoClaw aveva il segnale, il vault accettava depositi e la simulazione tornava verde. Questo è esattamente il tipo di configurazione che porta le persone a allentare le autorizzazioni troppo presto. Tutto funziona, quindi il confine viene trattato come pulizia.
La mappatura del bridge è dove ho trovato più fastidio. Se l'identificatore dell'asset incapsulato non corrisponde al token approvato dopo il settlement del bridge, non mi interessa se la strategia è corretta. Bloccalo. Se l'indirizzo del vault si risolve ma l'ID della catena non è quello che ho fissato, bloccalo. Se la stima del gas aumenta dopo il settlement e l'agente vuole riprovare con un soffitto più ampio, bloccalo e fammi approvare manualmente il retry. Non voglio un percorso di recupero automatizzato che trasformi un piccolo fallimento del percorso in una manipolazione dello stato a livello wallet.
Il fatto che l'ERC 4626 venga standardizzato rende quasi tutto questo peggio perché ti inganna a pensare che la superficie del vault sia ordinata. L'interfaccia è ordinata. Le autorizzazioni non lo sono. Deposit e redeem seduti vicini l'uno all'altro nella stessa categoria mentale è come finire per dare a un agente di trading la capacità di uscire quando tutto ciò di cui avevi bisogno era un ingresso limitato.
La versione brutta che ho lasciato in giro è abbastanza semplice da auditare quando sono stanco. OctoClaw può leggere ampiamente, preparare il percorso e proporre il deposito, ma l'esecuzione è stupida e ristretta. L'asset deve corrispondere. Il vault deve corrispondere. Il selettore deve corrispondere. L'importo deve rimanere sotto il limite. Il gas deve rimanere sotto il soffitto. Il retry è manuale. Qualsiasi altra cosa viene rifiutata.
Non mi sento ancora completamente a mio agio con questo, il che è probabilmente lo stato corretto in cui trovarsi.
Il log che volevo vedere non era un successo. Era questo:
execution_rejected | reason=cap_exceeded | selector=0xb6b55f25 | vault=approved | asset=approved | auto_retry=false | manual_review=true
Lasciarlo in esecuzione durante la notte con quel confine sembra ancora stupido, ma meno stupido che lasciare un modello decidere cosa significhi “accesso al vault”.