Lo Stack Agentico Ha Quattro Livelli. La Maggior Parte delle Implementazioni Ne Manca Tre

Identità, reputazione, mandato e pagamento devono vivere on-chain. In molte implementazioni di produzione, non lo fanno ancora, e questo è un problema architettonico, non un ripensamento di conformità.

Dedico molto tempo ad analizzare come le implementazioni di agenti in produzione siano effettivamente collegate, e lo schema è spesso lo stesso: il modello è capace, e il framework di orchestrazione è ragionevole, ma il livello di autenticazione è ancora una chiave API condivisa che non viene ruotata da mesi.

L’infrastruttura degli agenti autonomi non ha tenuto il passo con i modelli che girano sopra di essa. Lo stack agentico ha quattro componenti che devono essere nativi della catena: identità, reputazione, mandato e pagamento. Nella maggior parte delle implementazioni di produzione che vedo, sono ancora aggiunti a posteriori, se esistono.

E questo è più importante nella finanza regolamentata rispetto a qualsiasi altro ambito. Un agente che può operare su titoli tokenizzati, approvare azioni di tesoreria o allocare tra posizioni deve poter dimostrare cosa è stato autorizzato a fare, chi lo ha autorizzato, entro quali limiti e dove vive il record on-chain di tale autorità. La maggior parte delle implementazioni non riesce a rispondere a ciò in modo chiaro oggi. Senza quel record, l’agente stesso è il rischio di audit e conformità.

Perché le chiavi API condivise sono il primitivo sbagliato

Il modello di autenticazione che la maggior parte delle implementazioni di agenti eredita dal SaaS è un segreto condiviso passato in un header. Autentica il servizio chiamante ma non dice nulla sull’agente specifico che effettua la chiamata, né su ciò che quell’agente è autorizzato a fare, e non lascia alcun record che sopravviva a un audit in una forma che un regolatore possa ispezionare. Ogni azione dell’agente è attribuibile solo a chi detiene la chiave, il che nella pratica significa che l’attribuzione collassa una volta che ci sono più di un agente o più di un operatore.

L’alternativa è il settlement basato su firma per ogni richiesta. Ogni richiesta è firmata dal portafoglio proprio dell’agente e regolata criptograficamente al momento della chiamata. Questo è ciò per cui x402 è stato costruito, con autenticazione e pagamento gestiti insieme. Ciò fornisce alle istituzioni un record di quale portafoglio ha agito, quando ha agito e per cosa ha pagato, un registro che può sopravvivere a un audit.

Il divario di identità

ERC-8004 definisce l’identità on-chain per agenti senza fiducia: un registro in cui un agente è registrato con un portafoglio di controllo, un endpoint di servizio e un riferimento al modello. Al momento, quell’agente è solo un processo opaco che gira all’interno dell’infrastruttura di un fornitore. L’entrata del registro lo rende un attore on-chain di prima classe con un’origine verificabile — che un contratto intelligente o una dashboard di conformità può controllare direttamente, senza fidarsi di un intermediario.

Il livello di reputazione si basa su questo. I segnali di feedback scritti nel registro ERC-8004 sono immutabili, con timestamp e attribuibili. Qualsiasi sistema che voglia prendere decisioni di fiducia su un agente può leggere direttamente quel registro. A differenza di un punteggio gestito dal fornitore o di una valutazione su Discord, la fiducia qui è una proprietà della rete piuttosto che di chi controlla il database.

Entrambi i livelli sono implementabili oggi senza ingegneria esotica. La maggior parte delle implementazioni non li possiede perché il percorso di implementazione a minor resistenza è ancora trattare gli agenti come account di servizio piuttosto che come attori di prima classe. Una scorciatoia ragionevole in un prototipo diventa debito architettonico che si complica in produzione.

Il problema del mandato è dove la finanza regolamentata diverge da tutto il resto

Identità e reputazione ti dicono chi è un agente e come si è comportato. Non stabiliscono cosa l’agente è autorizzato a fare. In molti casi d’uso degli agenti, i controlli a livello di applicazione possono colmare questa lacuna. Per gli agenti che operano su asset regolamentati, la questione dell’autorizzazione diventa una questione legale. La risposta deve esistere in una forma che possa soddisfare un regolatore.

ERC-8226, lo Standard del Mandato per Agenti Regolamentati (RAMS), è progettato per chiudere questa lacuna. RAMS definisce un livello di delega di conformità che si colloca tra l’identità dell’agente e i framework di conformità a livello di token. Un principale verificato KYC concede a un agente un mandato con uno scopo definito, giurisdizione, limiti di valore e data di scadenza. In pratica, funziona come una procura on-chain che può essere verificata prima del settlement. Il contratto token regolamentato verifica quindi quel mandato in modo atomico all’interno del suo hook di conformità pre-trasferimento prima di qualsiasi settlement.

Due interfacce trasportano il design. `ComplianceProvider` è implementato da qualsiasi operatore KYC o di attestazione e garantisce l’idoneità del principale per uno scopo dato. `IAgentMandate` è il registro che registra concessioni, estensioni, revoche, esecuzioni e congelamenti a livello di regolatore. L’applicazione avviene tramite `recordExecution`, che controlla i limiti del mandato attivo al momento del trasferimento e annulla se la transazione li violerebbe.

Questa architettura si colloca tra l’identità ERC-8004 e i framework di conformità token come ERC-7943 piuttosto che sostituire l’uno o l’altro. L’identità dice che l’agente esiste ed è verificabile; la conformità token, che il principale è idoneo a detenere questo specifico asset. RAMS aggiunge la parte che nessuno dei due copre: autorità da questo principale, per questo scopo, entro questi limiti, fino a questa data. Lo strato di delega legalmente eseguibile che attualmente vive solo in PDF e fogli di calcolo back‑office si sposta on-chain, dove può essere effettivamente applicato al momento del trasferimento.

La separazione preparazione‑esecuzione non è attrito

Una decisione di design merita una difesa diretta: separare la preparazione della transazione dalla firma e dalla diffusione. Viene eliminata in molti sistemi che cercano di rendere gli agenti più fluidi.

L’istinto è quello di comprimere questi passaggi in un unico step perché sembra più efficiente. Ma il divario tra preparazione e diffusione è esattamente dove appartiene la supervisione istituzionale. È dove un responsabile della conformità rivede ciò che un agente sta per fare prima che la catena ne venga a conoscenza, dove un controllo del mandato RAMS valida il payload preparato rispetto allo scopo attivo, ai limiti di valore e alla giurisdizione prima che venga prodotta qualsiasi firma, e dove un CFO approva un’azione di tesoreria che un agente ha preparato ma non ancora confermato.

Molte istituzioni che distribuiscono agenti autonomi su scala significativa ricostruiscono eventualmente questa separazione quando scoprono che manca. Costruirla come primitivo architettonico deliberato anziché come retrofit che porta un sistema attraverso la sua prima revisione di conformità.

Come appare lo stack quando è completo

Quando tutti e quattro i livelli sono in posizione, si compongono in modo pulito. ERC-8004 ancorra l’identità dell’agente e la reputazione on-chain, e ERC-8226 aggiunge il livello di mandato che delimita ciò che ogni agente può fare per conto di chi. x402 gestisce il settlement, firmando ogni richiesta così che ogni azione sia attribuibile e auditabile. Sotto, i framework di asset regolamentati come ERC-7943 applicano la conformità al momento del trasferimento sia rispetto all’idoneità del principale sia rispetto al mandato attivo dell’agente.

Questi componenti hanno diversi livelli di maturità, ma nessuno è puramente teorico. ERC-8004 è un ERC Draft Standards Track con primitive di identità e reputazione distribuibili. ERC-7943 è uno standard Ethereum finale. ERC-8226 è sulla track degli standard, e le interfacce core sono sufficientemente stabili per lavori di implementazione precoce. x402 è attivo e già progettato attorno a pagamenti HTTP programmatici per umani e agenti.

I team che lo fanno bene possono costruire verso questo stack ora o attendere finché la pressione di audit e conformità costringe il retrofit. Le istituzioni che lo fanno bene saranno quelle che trattano i livelli di mandato e identità come requisiti infrastrutturali fin dal primo giorno, allo stesso modo in cui trattano KYC e custodia. I regolatori potrebbero non aver ancora richiesto esplicitamente ogni sua parte. I team che costruiscono sistemi di produzione in questo ambito sanno già quanto sia costoso aggiungere questi controlli a posteriori.