Den agentbaserede stak har fire lag. De fleste implementeringer mangler tre

Identitet, omdømme, mandat og betaling skal leve on-chain. I mange produktionsimplementeringer gør de det stadig ikke, og det er et arkitektonisk problem, ikke en eftertanke om overholdelse.

Jeg bruger meget tid på at undersøge, hvordan produktions‑agent‑implementeringer faktisk er koblet sammen, og mønsteret er ofte det samme: modellen er kapabel, og orkestreringsrammen er rimelig, men autentificeringslaget er stadig en delt API‑nøgle, der ikke er roteret i måneder.

Den autonome agent‑infrastruktur har ikke holdt trit med modellerne, der kører ovenpå den. Den agentbaserede stak har fire komponenter, der skal være native på kæden: identitet, omdømme, mandat og betaling. I de fleste produktionsimplementeringer, jeg ser, er de stadig eftermonteret, hvis de overhovedet findes.

Og dette er vigtigere i reguleret finans end andre steder. En agent, der kan handle med tokeniserede værdipapirer, godkende treasury‑handlinger eller allokere på tværs af positioner, skal kunne vise, hvad den var autoriseret til at gøre, hvem der autoriserede den, inden for hvilke grænser, og hvor den on-chain‑record af den autoritet findes. De fleste implementeringer kan i dag ikke besvare det klart. Uden den record er selve agenten en revisions‑ og overholdelsesrisiko.

Hvorfor delte API‑nøgler er den forkerte primitive

Autentificeringsmodellen, som de fleste agent‑implementeringer arver fra SaaS, er en delt hemmelighed, der sendes i en header. Den autentificerer den kaldende tjeneste, men siger intet om den specifikke agent, der foretager kaldet, eller hvad den agent har tilladelse til at gøre, og den efterlader ingen record, der overleverer revision i en form, som en regulator kan inspicere. Hver agent‑handling kan kun tilskrives den, der har nøglen, hvilket i praksis betyder, at attributionen kollapser, så snart du har mere end én agent eller mere end én operatør.

Alternativet er signatur‑baseret per‑request afregning. Hvert request signeres af agentens egen wallet og afregnes kryptografisk på tidspunktet for kaldet. Det er, hvad x402 er bygget til, med autentificering og betaling håndteret sammen. Det giver institutioner en record over, hvilken wallet der handlede, hvornår den handlede, og hvad den betalte for, en hovedbog der kan overleve revisionsgennemgang.

Identitetskløften

ERC-8004 fastlægger on-chain identitet for tillidsløse agenter: et register, hvor en agent registreres med en kontrollerende wallet, et service‑endpoint og en modelreference. Lige nu er den agent blot en uigennemsigtig proces, der kører inden for en leverandørs infrastruktur. Registerposten gør den til en førsteklasses on-chain aktør med en verificerbar oprindelse — en, som en smart contract eller compliance‑dashboard kan tjekke direkte, uden at stole på en mellemmand.

Omdømmeslaget bygger oven på dette. Feedback‑signaler, der skrives ind i ERC-8004‑registeret, er uforanderlige, tidsstemplet og tilskrivelige. Ethvert system, der ønsker at træffe tillidsbeslutninger om en agent, kan læse dette register direkte. I modsætning til en leverandør‑styrt score eller en Discord‑vurdering er tilliden her en egenskab ved netværket snarere end af den, der kontrollerer databasen.

Begge lag kan implementeres i dag uden eksotisk ingeniørarbejde. De fleste implementeringer har dem ikke, fordi den mindst modstandsfyldte implementeringsvej stadig er at behandle agenter som service‑konti snarere end som førsteklasses aktører. En rimelig genvej i en prototype bliver til arkitektonisk gæld, der forstærkes i produktion.

Mandat‑problemet er hvor reguleret finans afviger fra alt andet

Identitet og omdømme fortæller dig, hvem en agent er, og hvordan den har opført sig. De fastlægger ikke, hvad agenten er autoriseret til at gøre. I mange agent‑brugsscenarier kan applikations‑lag kontrol dække dette hul. For agenter, der opererer med regulerede aktiver, bliver autorisationsspørgsmålet et juridisk spørgsmål. Svaret skal eksistere i en form, der kan tilfredsstille en regulator.

ERC-8226, Regulated Agent Mandate Standard (RAMS), er designet til at lukke dette hul. RAMS definerer et compliance‑delegationslag, der sidder mellem agentens identitet og token‑niveau compliance‑rammer. En KYC‑verificeret principal tildeler en agent et mandat med et defineret omfang, jurisdiktion, værdigrænser og udløbsdato. I praksis fungerer det som en on-chain fuldmagt, der kan kontrolleres før afregning. Den regulerede token‑kontrakt verificerer derefter mandatet atomisk i sin pre‑transfer compliance‑hook, før nogen afregning finder sted.

To interfaces bærer designet. `ComplianceProvider` implementeres af enhver KYC‑ eller attestationsoperatør og garanterer principalens berettigelse til et givet omfang. `IAgentMandate` er registret, der registrerer tildelinger, forlængelser, tilbagekaldelser, udførelser og regulator‑niveau frysninger. Håndhævelsen sker gennem `recordExecution`, som tjekker de aktive mandat‑grænser ved overførselstidspunktet og ruller tilbage, hvis transaktionen ville overskride dem.

Denne arkitektur sidder mellem ERC-8004 identitet og token‑compliance‑rammer som ERC-7943 i stedet for at erstatte nogen af dem. Identitet siger, at agenten eksisterer og er verificerbar; token‑compliance siger, at principalen er berettiget til at holde dette specifikke aktiv. RAMS tilføjer den del, som ingen af dem dækker: autoritet fra denne principal, for dette omfang, inden for disse grænser, indtil denne dato. Det juridisk håndhævelige delegationslag, som i øjeblikket kun lever i PDF‑er og back‑office regneark, flyttes on-chain, hvor det faktisk kan håndhæves ved overførselstidspunktet.

Forbered‑og‑eksekver‑adskillelsen er ikke friktion

En designbeslutning fortjener en direkte forsvar: at adskille transaktionsforberedelse fra signering og broadcast. Det bliver fjernet i mange systemer, der forsøger at få agenter til at føles mere sømløse.

Instinktet er at sammenlægge disse til et enkelt trin, fordi det føles mere effektivt. Men hullet mellem forberedelse og broadcast er præcis, hvor institutionel tilsyn hører hjemme. Det er, hvor en compliance‑officer gennemgår, hvad en agent er ved at gøre, før kæden får kendskab til det, hvor en RAMS‑mandat‑kontrol validerer den forberedte payload mod aktivt omfang, værdigrænser og jurisdiktion, før nogen signatur produceres, og hvor en CFO godkender en treasury‑handling, som en agent har forberedt, men endnu ikke forpligtet.

Mange institutioner, der implementerer autonome agenter i betydelig skala, genopbygger til sidst denne adskillelse, når de opdager, at den mangler. At bygge den ind som en bevidst arkitektonisk primitive i stedet for en eftermontering, der bærer et system gennem sin første compliance‑gennemgang.

Hvordan stakken ser ud, når den er komplet

Når alle fire lag er på plads, komponerer de sig rent. ERC-8004 forankrer agentens identitet og on-chain omdømme, og ERC-8226 tilføjer mandatlaget, der begrænser, hvad hver agent kan gøre på hvem’s vegne. x402 håndterer afregning, signerer hver anmodning, så hver handling er tilskrivelig og auditérbar. Underliggende, regulerede aktiv‑rammer som ERC-7943 håndhæver compliance på overførselstidspunktet mod både principalens berettigelse og agentens aktive mandat.

Disse komponenter er på forskellige modenhedsniveauer, men ingen af dem er rent teoretiske. ERC-8004 er en Draft Standards Track ERC med deployerbare identitets‑ og omdømme‑primitive. ERC-7943 er en endelig Ethereum‑standard. ERC-8226 er på standards‑sporet, og kerne‑interfacene er stabile nok til tidlig implementeringsarbejde. x402 er live og allerede designet omkring programmatisk HTTP‑betalinger for mennesker og agenter.

De teams, der får dette rigtigt, kan bygge mod denne stak nu eller vente, indtil revisions‑ og compliance‑pres tvinger eftermonteringen. De institutioner, der får dette rigtigt, vil være dem, der behandler mandat‑ og identitetslagene som infrastrukturkrav fra dag ét, på samme måde som de behandler KYC og custody. Regulatorer har måske endnu ikke eksplicit krævet hver eneste del. Teams, der bygger produktionssystemer i dette område, ved allerede, hvor dyrt det er at tilføje disse kontroller efterfølgende.