Agentiska stacken har fyra lager. De flesta distributioner saknar tre

Identitet, rykte, mandat och betalning måste finnas på kedjan. I många produktionsdistributioner gör de det fortfarande inte, och det är ett arkitekturproblem, inte en eftertanke för efterlevnad.

Jag spenderar mycket tid på att titta på hur produktionsagentdistributioner faktiskt är kopplade ihop, och mönstret är ofta detsamma: modellen är kapabel, och orkestreringsramverket är rimligt, men autentiseringslagret är fortfarande en delad API-nyckel som inte har roterats på månader.

Den autonoma agentinfrastrukturen har inte hållit jämna steg med modellerna som körs ovanpå den. Den agentiska stacken har fyra komponenter som måste vara inhemska på kedjan: identitet, rykte, mandat och betalning. I de flesta produktionsdistributioner jag ser är de fortfarande eftermonterade, om de ens finns.

Och detta är viktigare i reglerad finans än någon annanstans. En agent som kan transagera med tokeniserade värdepapper, godkänna treasury‑åtgärder eller allokera över positioner måste kunna visa vad den var auktoriserad att göra, vem som auktoriserade den, inom vilka gränser och var den on‑chain‑registreringen av den auktoriteten finns. De flesta distributioner kan inte svara på det tydligt idag. Utan den registreringen är själva agenten en revisions- och efterlevnadsrisk.

Varför delade API-nycklar är fel primitiv

Autentiseringsmodellen som de flesta agentdistributioner ärver från SaaS är en delad hemlighet som skickas i ett header. Den autentiserar den anropande tjänsten men säger inget om den specifika agenten som gör anropet, eller vad den agenten får göra, och den lämnar ingen registrering som överlever revision i en form som en regulator kan granska. Varje agentåtgärd kan endast hänföras till den som innehar nyckeln, vilket i praktiken betyder att attributionen kollapsar när du har mer än en agent eller mer än en operatör.

Alternativet är signaturbaserad per‑förfrågan‑avveckling. Varje förfrågan signeras av agentens egen plånbok och avvecklas kryptografiskt vid anropstillfället. Detta är vad x402 är byggt för, med autentisering och betalning hanterade tillsammans. Det ger institutioner en registrering av vilken plånbok som agerade, när den agerade och vad den betalade för, en huvudbok som kan överleva revisionsgranskning.

Identitetsgapet

ERC-8004 fastställer on‑chain‑identitet för förtroendelösa agenter: ett register där en agent registreras med en styrande plånbok, en tjänste‑endpoint och en modellreferens. Just nu är den agenten bara en ogenomskinlig process som körs inom en leverantörs infrastruktur. Registerposten gör den till en förstaklassig on‑chain‑aktör med en verifierbar ursprung — något som ett smart kontrakt eller en efterlevnads‑dashboard kan kontrollera direkt, utan att lita på en mellanhand.

Rykte‑lagret bygger på detta. Återkopplingssignaler skrivna i ERC-8004‑registret är oföränderliga, tidsstämplade och hänförliga. Alla system som vill fatta förtroendebeslut om en agent kan läsa registret direkt. Till skillnad från ett leverantörshanterat betyg eller en Discord‑rating är förtroendet här en egenskap hos nätverket snarare än hos den som kontrollerar databasen.

Båda lagren kan implementeras idag utan exotisk ingenjörskonst. De flesta distributioner har dem inte eftersom den enklaste implementationsvägen fortfarande är att behandla agenter som tjänstekonton snarare än som förstaklassiga aktörer. Ett rimligt genväg i ett prototyp blir arkitektonisk skuld som växer i produktion.

Mandatproblemet är där reglerad finans avviker från allt annat

Identitet och rykte berättar vem en agent är och hur den har agerat. De fastställer inte vad agenten är auktoriserad att göra. I många agent‑användningsfall kan kontroll på applikationsnivå täcka det gapet. För agenter som opererar med reglerade tillgångar blir auktoriseringsfrågan en juridisk fråga. Svaret måste finnas i en form som kan tillfredsställa en regulator.

ERC-8226, Regulated Agent Mandate Standard (RAMS), är utformad för att stänga detta gap. RAMS definierar ett efterlevnads‑delegationslager som sitter mellan agentens identitet och token‑nivå‑efterlevnadsramverk. En KYC‑verifierad huvudman beviljar en agent ett mandat med ett definierat omfång, jurisdiktion, värdegränser och utgångsdatum. I praktiken fungerar det som en on‑chain fullmakt som kan kontrolleras innan avveckling. Det reglerade token‑kontraktet verifierar sedan mandatet atomärt i sin för‑överförings‑efterlevnadshook innan någon avveckling sker.

Två gränssnitt bär designen. `ComplianceProvider` implementeras av någon KYC‑ eller attestationsoperatör och intygar huvudmannens behörighet för ett givet omfång. `IAgentMandate` är registret som registrerar beviljanden, förlängningar, återkallelser, verkställanden och regulator‑nivå‑frysningar. Verkställandet sker via `recordExecution`, som kontrollerar de aktiva mandatens gränser vid överföringstid och återkallar om transaktionen skulle överskrida dem.

Denna arkitektur sitter mellan ERC-8004‑identitet och token‑efterlevnadsramverk som ERC-7943 snarare än att ersätta någon av dem. Identitet säger att agenten existerar och är verifierbar; token‑efterlevnad säger att huvudmannen är berättigad att inneha denna specifika tillgång. RAMS lägger till den del som ingen av dem täcker: auktoritet från denna huvudman, för detta omfång, inom dessa gränser, tills detta datum. Det juridiskt verkställbara delegationslagret som för närvarande bara finns i PDF‑dokument och back‑office‑kalkylblad flyttas on‑chain, där det faktiskt kan verkställas vid överföringstid.

Förbered‑och‑utför‑separationen är inte friktion

Ett designbeslut förtjänar ett direkt försvar: att separera transaktionsförberedelse från signering och sändning. Det tas bort i många system som försöker få agenter att kännas mer sömlösa.

Instinktet är att slå ihop dessa till ett enda steg eftersom det känns mer effektivt. Men gapet mellan förberedelse och sändning är exakt där institutionell tillsyn hör hemma. Det är där en compliance‑officer granskar vad en agent är på väg att göra innan kedjan får reda på det, där en RAMS‑mandatkontroll validerar den förberedda nyttolasten mot aktivt omfång, värdegränser och jurisdiktion innan någon signatur produceras, och där en CFO godkänner en treasury‑åtgärd som en agent har förberett men ännu inte utfört.

Många institutioner som distribuerar autonoma agenter i betydande skala återuppbygger så småningom denna separation när de upptäcker att den saknas. Att bygga in den som en medveten arkitektur‑primitiv snarare än en eftermontering som bär ett system genom sin första efterlevnadsgranskning.

Hur stacken ser ut när den är komplett

När alla fyra lager är på plats, samverkar de smidigt. ERC-8004 förankrar agentens identitet och on‑chain‑rykte, och ERC-8226 lägger till mandatlagret som begränsar vad varje agent kan göra och för vem. x402 hanterar avveckling, signerar varje förfrågan så varje åtgärd är hänförlig och auditabel. Underliggande, reglerade tillgångsramverk som ERC-7943 verkställer efterlevnad vid överföringstid mot både huvudmannens behörighet och agentens aktiva mandat.

Dessa komponenter befinner sig på olika mognadsnivåer, men ingen av dem är rent teoretiska. ERC-8004 är ett Draft Standards Track ERC med implementerbara identitets‑ och rykte‑primitiver. ERC-7943 är en färdig Ethereum‑standard. ERC-8226 är på standards‑spåret, och kärn‑gränssnitten är tillräckligt stabila för tidig implementeringsarbete. x402 är live och redan designat kring programmatisk HTTP‑betalning för människor och agenter.

De team som får detta rätt kan bygga mot denna stack nu eller vänta tills revisions‑ och efterlevnadstryck tvingar eftermonteringen. De institutioner som får detta rätt kommer att vara de som behandlar mandat‑ och identitetslagren som infrastrukturkrav från dag ett, på samma sätt som de behandlar KYC och förvaring. Regulatorer har kanske ännu inte uttryckligen krävt varje del av det. Team som bygger produktionssystem i detta område vet redan hur dyrt det är att lägga till dessa kontroller i efterhand.