Den agentbaserte stakken har fire lag. De fleste implementeringer mangler tre

Identitet, omdømme, mandat og betaling må eksistere on-chain. I mange produksjonsdistribusjoner gjør de det fortsatt ikke, og det er et arkitektonisk problem, ikke en ettertanke for samsvar.

Jeg bruker mye tid på å se på hvordan produksjons‑agent‑distribusjoner faktisk er koblet sammen, og mønsteret er ofte det samme: modellen er kapabel, og orkestreringsrammeverket er rimelig, men autentiseringslaget er fortsatt en delt API‑nøkkel som ikke har blitt rotert på måneder.

Autonom agent‑infrastruktur har ikke holdt tritt med modellene som kjører på toppen av den. Den agentbaserte stakken har fire komponenter som må være native på kjeden: identitet, omdømme, mandat og betaling. I de fleste produksjonsdistribusjoner jeg ser, er de fortsatt påmontert i etterkant, hvis de i det hele tatt finnes.

Og dette er viktigere i regulert finans enn noe annet sted. En agent som kan handle med tokeniserte verdipapirer, godkjenne treasury‑handlinger eller allokere på tvers av posisjoner, må kunne vise hva den var autorisert til å gjøre, hvem som autoriserte den, innen hvilke grenser, og hvor den on-chain‑registreringen av den autoriteten befinner seg. De fleste distribusjoner kan ikke svare på dette tydelig i dag. Uten den registreringen er selve agenten en revisjons‑ og samsvarsrisiko.

Hvorfor delte API‑nøkler er feil primitive

Autentiseringsmodellen de fleste agent‑distribusjoner arver fra SaaS er en delt hemmelighet som sendes i en header. Den autentiserer den påkallende tjenesten, men sier ingenting om den spesifikke agenten som gjør kallet, eller hva den agenten har lov til å gjøre, og den etterlater ingen registrering som overleverer revisjon i en form en regulator kan inspisere. Hver agenthandling kan kun tilskrives den som har nøkkelen, noe som i praksis betyr at tilskrivning kollapser så snart du har mer enn én agent eller mer enn én operatør.

Alternativet er signaturbasert per‑forespørsel‑oppgjør. Hver forespørsel signeres av agentens egen lommebok og oppgjøres kryptografisk på tidspunktet for kallet. Dette er hva x402 er bygget for, med autentisering og betaling håndtert sammen. Det gir institusjoner en registrering av hvilken lommebok som handlet, når den handlet, og hva den betalte for, en hovedbok som kan overleve revisjonsgranskning.

Identitetsgapet

ERC-8004 fastsetter on-chain identitet for tillitsløse agenter: et register hvor en agent er registrert med en kontrollerende lommebok, et tjeneste‑endepunkt og en modellreferanse. Akkurat nå er den agenten bare en ugjennomsiktig prosess som kjører inne i en leverandørs infrastruktur. Registeroppføringen gjør den til en førsteklasses on-chain‑aktør med en verifiserbar opprinnelse — en som en smart kontrakt eller samsvars‑dashbord kan sjekke direkte, uten å stole på en mellommann.

Omdømmelagget bygger på dette. Tilbakemeldingssignaler skrevet inn i ERC-8004‑registeret er uforanderlige, tidsstemplet og tilskrivbare. Ethvert system som ønsker å ta tillitsbeslutninger om en agent kan lese dette registeret direkte. I motsetning til en leverandørstyrt poengsum eller en Discord‑vurdering, er tillit her en egenskap ved nettverket snarere enn av den som kontrollerer databasen.

Begge lagene kan implementeres i dag uten eksotisk ingeniørkunst. De fleste distribusjoner har dem ikke fordi den minst motstandsfulle implementasjonsveien fortsatt er å behandle agenter som tjenestekontoer snarere enn som førsteklasses aktører. En rimelig snarvei i en prototype blir arkitektonisk gjeld som vokser i produksjon.

Mandatproblemet er hvor regulert finans avviker fra alt annet

Identitet og omdømme forteller deg hvem en agent er og hvordan den har oppført seg. De fastsetter ikke hva agenten er autorisert til å gjøre. I mange agent‑brukstilfeller kan applikasjonslagkontroller dekke dette gapet. For agenter som opererer med regulerte eiendeler, blir autorisasjonsspørsmålet et juridisk spørsmål. Svaret må eksistere i en form som kan tilfredsstille en regulator.

ERC-8226, Regulated Agent Mandate Standard (RAMS), er designet for å lukke dette gapet. RAMS definerer et samsvars‑delegasjonslag som sitter mellom agentidentitet og token‑nivå samsvarsrammeverk. En KYC‑verifisert hovedperson gir en agent et mandat med definert omfang, jurisdiksjon, verdigrenser og utløpsdato. I praksis fungerer det som en on-chain fullmakt som kan sjekkes før oppgjør. Den regulerte token‑kontrakten verifiserer deretter mandatet atomisk i sin pre‑transfer‑samsvars‑hook før noe oppgjør skjer.

To grensesnitt bærer designet. `ComplianceProvider` implementeres av enhver KYC‑ eller attestasjonsoperatør og garanterer hovedpersonens berettigelse for et gitt omfang. `IAgentMandate` er registeret som registrerer tildelinger, forlengelser, tilbakekallinger, utførelser og regulator‑nivå frysing. Håndhevelsen skjer gjennom `recordExecution`, som sjekker de aktive mandatets grenser ved overføringstidspunktet og avbryter hvis transaksjonen ville overskride dem.

Denne arkitekturen sitter mellom ERC-8004‑identitet og token‑samsvarsrammeverk som ERC-7943, i stedet for å erstatte noen av dem. Identitet sier at agenten eksisterer og er verifiserbar; token‑samsvar sier at hovedpersonen er berettiget til å holde dette spesifikke aktivumet. RAMS legger til den delen ingen av dem dekker: autoritet fra denne hovedpersonen, for dette omfanget, innenfor disse grensene, frem til denne datoen. Det juridisk håndhevbare delegasjonslaget som for øyeblikket kun lever i PDF‑er og back‑office‑regneark, flyttes on-chain, hvor det faktisk kan håndheves ved overføringstidspunktet.

Skille mellom forberedelse og utførelse er ikke friksjon

En designbeslutning fortjener en direkte begrunnelse: å skille transaksjonsforberedelse fra signering og kringkasting. Den blir fjernet i mange systemer som prøver å få agenter til å føles mer sømløse.

Instinktet er å slå disse sammen til ett enkelt steg fordi det føles mer effektivt. Men gapet mellom forberedelse og kringkasting er akkurat der institusjonell tilsyn hører hjemme. Det er der en samsvarsansvarlig gjennomgår hva en agent er i ferd med å gjøre før kjeden får vite om det, der en RAMS‑mandatkontroll validerer den forberedte nyttelasten mot aktivt omfang, verdigrenser og jurisdiksjon før noen signatur produseres, og der en CFO godkjenner en treasury‑handling som en agent har forberedt men ennå ikke forpliktet.

Mange institusjoner som distribuerer autonome agenter i betydelig skala, bygger etter hvert opp dette skillet når de oppdager at det mangler. Å bygge det inn som et bevisst arkitektonisk primitive i stedet for en ettermontering som får et system gjennom sin første samsvars‑gjennomgang.

Hvordan stakken ser ut når den er komplett

Når alle fire lag er på plass, komponerer de seg rent. ERC-8004 forankrer agentidentitet og on-chain omdømme, og ERC-8226 legger til mandatlaget som begrenser hva hver agent kan gjøre på vegne av hvem. x402 håndterer oppgjør, signerer hver forespørsel slik at hver handling er tilskrivbar og reviderbar. Under ligger regulerte aktivarammeverk som ERC-7943 som håndhever samsvar ved overføringstidspunktet mot både hovedpersonens berettigelse og agentens aktive mandat.

Disse komponentene er på ulike modenhetsnivåer, men ingen av dem er rent teoretiske. ERC-8004 er en Draft Standards Track ERC med distribuerbare identitets‑ og omdømme‑primitive. ERC-7943 er en endelig Ethereum‑standard. ERC-8226 er på standards‑sporet, og kjernegrensesnittene er stabile nok for tidlig implementasjonsarbeid. x402 er i drift og allerede designet rundt programmatisk HTTP‑betaling for mennesker og agenter.

Teamene som får dette riktig kan bygge mot denne stakken nå eller vente til revisjons‑ og samsvarspress tvinger ettermonteringen. Institusjonene som får dette riktig vil være de som behandler mandat‑ og identitetslagene som infrastrukturkrav fra dag én, på samme måte som de behandler KYC og oppbevaring. Regulatorer har kanskje ikke eksplisitt krevd hver del av det ennå. Team som bygger produksjonssystemer i dette rommet vet allerede hvor kostbart det er å legge til disse kontrollene i etterkant.