De Agentische Stack Heeft Vier Lagen. De Meeste Implementaties Missen Drie

Identiteit, reputatie, mandaat en betaling moeten on-chain bestaan. In veel productie-implementaties is dat nog steeds niet het geval, en dat is een architecturaal probleem, geen nalevingsbijzaak.

Ik besteed veel tijd aan het bekijken hoe productie‑agentimplementaties daadwerkelijk zijn verbonden, en het patroon is vaak hetzelfde: het model is capabel, en het orkestratiekader is redelijk, maar de authenticatielaag is nog steeds een gedeelde API‑sleutel die al maanden niet is geroteerd.

De infrastructuur voor autonome agenten heeft de modellen die erop draaien niet kunnen bijhouden. De agentische stack heeft vier componenten die native op de chain moeten zijn: identiteit, reputatie, mandaat en betaling. In de meeste productie‑implementaties die ik zie, worden ze nog steeds achteraf toegevoegd, als ze al bestaan.

En dit is belangrijker in gereguleerde financiën dan ergens anders. Een agent die kan handelen in getokeniseerde effecten, schatkistacties kan goedkeuren, of posities kan toewijzen, moet kunnen aantonen wat hij gemachtigd is te doen, wie het heeft gemachtigd, binnen welke limieten, en waar het on-chain record van die autoriteit zich bevindt. De meeste implementaties kunnen dat vandaag niet duidelijk beantwoorden. Zonder dat record is de agent zelf het audit‑ en nalevingsrisico.

Waarom gedeelde API‑sleutels het verkeerde primitive zijn

Het authenticatiemodel dat de meeste agent‑implementaties van SaaS overnemen, is een gedeeld geheim dat in een header wordt meegegeven. Het authenticeert de aanroepende service, maar zegt niets over de specifieke agent die de oproep doet, of wat die agent mag doen, en het laat geen record achter dat een audit overleeft in een vorm die een toezichthouder kan inspecteren. Elke agentactie is alleen toerekenbaar aan degene die de sleutel bezit, wat in de praktijk betekent dat toerekening instort zodra je meer dan één agent of meer dan één operator hebt.

Het alternatief is handtekening‑gebaseerde per‑request afwikkeling. Elke aanvraag wordt ondertekend door de eigen wallet van de agent en cryptografisch afgehandeld op het moment van de oproep. Dit is waar x402 voor is gebouwd, met authenticatie en betaling gecombineerd. Dat geeft instellingen een record van welke wallet handelde, wanneer het handelde, en waarvoor het betaalde, een grootboek dat een audit‑onderzoek kan doorstaan.

De identiteitskloof

ERC-8004 definieert on-chain identiteit voor trustless agents: een register waarin een agent wordt geregistreerd met een controlerende wallet, een service‑endpoint en een modelreferentie. Op dit moment is die agent slechts een ondoorzichtig proces dat draait binnen de infrastructuur van een leverancier. Het registeritem maakt het een eersteklas on-chain actor met een verifieerbare oorsprong — iets dat een smart contract of compliance‑dashboard direct kan controleren, zonder een tussenpersoon te vertrouwen.

De reputatielaag bouwt hierop voort. Feedbacksignalen die in het ERC-8004 register worden geschreven, zijn onveranderlijk, voorzien van een tijdstempel en toerekenbaar. Elk systeem dat vertrouwensbeslissingen over een agent wil nemen, kan dat register direct lezen. In tegenstelling tot een door de leverancier beheerde score of een Discord‑beoordeling, is vertrouwen hier een eigenschap van het netwerk in plaats van van degene die de database beheert.

Beide lagen zijn vandaag nog implementeerbaar zonder exotische engineering. De meeste implementaties hebben ze niet, omdat de pad van minste weerstand nog steeds is om agenten te behandelen als service‑accounts in plaats van als eersteklas actoren. Een redelijke snelkoppeling in een prototype wordt een architecturale schuld die zich in productie opstapelt.

Het mandaatprobleem is waar gereguleerde financiën afwijken van alles andere

Identiteit en reputatie vertellen je wie een agent is en hoe hij zich heeft gedragen. Ze stellen niet vast wat de agent gemachtigd is te doen. In veel agent‑use‑cases kunnen controles op toepassingslaag die kloof overbruggen. Voor agenten die opereren met gereguleerde activa wordt de autorisatievraag een juridische vraag. Het antwoord moet bestaan in een vorm die een toezichthouder kan tevredenstellen.

ERC-8226, de Regulated Agent Mandate Standard (RAMS), is ontworpen om deze kloof te dichten. RAMS definieert een compliance‑delegatielaag die zich bevindt tussen agentidentiteit en token‑niveau compliance‑kaders. Een KYC‑geverifieerde principaal verleent een agent een mandaat met een gedefinieerde scope, jurisdictie, waardelimieten en vervaldatum. In de praktijk werkt het als een on-chain volmacht die vóór afwikkeling kan worden gecontroleerd. Het gereguleerde tokencontract verifieert vervolgens dat mandaat atomisch binnen zijn pre‑transfer compliance‑hook voordat enige afwikkeling plaatsvindt.

Twee interfaces dragen het ontwerp. `ComplianceProvider` wordt geïmplementeerd door elke KYC‑ of attestatie‑operator en garandeert de geschiktheid van de principaal voor een bepaalde scope. `IAgentMandate` is het register dat toekenningen, verlengingen, intrekkingen, uitvoeringen en regulator‑tier bevriezingen vastlegt. De handhaving gebeurt via `recordExecution`, die de limieten van het actieve mandaat controleert op het moment van transfer en terugdraait als de transactie deze zou overschrijden.

Deze architectuur zit tussen ERC-8004 identiteit en token‑compliance‑kaders zoals ERC-7943 in plaats van een van beide te vervangen. Identiteit zegt dat de agent bestaat en verifieerbaar is; token‑compliance, dat de principaal in aanmerking komt om dit specifieke asset te houden. RAMS voegt het deel toe dat geen van beide dekt: autoriteit van deze principaal, voor deze scope, binnen deze limieten, tot deze datum. De juridisch afdwingbare delegatielaag die momenteel alleen in PDF’s en back‑office spreadsheets bestaat, wordt on-chain verplaatst, waar hij daadwerkelijk kan worden afgedwongen op het moment van transfer.

De scheiding tussen voorbereiden en uitvoeren is geen frictie

Een ontwerpbeslissing verdient een directe verdediging: het scheiden van transactie‑voorbereiding van ondertekening en uitzending. Het wordt weggelaten in veel systemen die agents soepeler willen laten aanvoelen.

De instinct is om deze samen te voegen tot één stap omdat het efficiënter lijkt. Maar de kloof tussen voorbereiding en uitzending is precies waar institutioneel toezicht hoort. Het is waar een compliance‑officier beoordeelt wat een agent op het punt staat te doen voordat de chain erover wordt geïnformeerd, waar een RAMS‑mandaatcontrole de voorbereide payload valideert tegen de actieve scope, waardelimieten en jurisdictie voordat een handtekening wordt geproduceerd, en waar een CFO een schatkistactie goedkeurt die een agent heeft voorbereid maar nog niet heeft bevestigd.

Veel instellingen die autonome agenten op betekenisvolle schaal inzetten, herbouwen uiteindelijk deze scheiding wanneer ze ontdekken dat deze ontbreekt. Het inbouwen als een bewuste architecturale primitive in plaats van een retrofit die een systeem door zijn eerste compliance‑review draagt.

Hoe de stack eruitziet wanneer hij compleet is

Wanneer alle vier lagen aanwezig zijn, vormen ze een schone compositie. ERC-8004 verankert agentidentiteit en on-chain reputatie, en ERC-8226 voegt de mandaatlaag toe die begrenst wat elke agent kan doen namens wie. x402 behandelt afwikkeling, ondertekent elke aanvraag zodat elke actie toerekenbaar en controleerbaar is. Daaronder handhaven gereguleerde asset‑kaders zoals ERC-7943 compliance op het moment van transfer tegen zowel de geschiktheid van de principaal als het actieve mandaat van de agent.

Deze onderdelen bevinden zich op verschillende volwassenheidsniveaus, maar geen van hen is puur theoretisch. ERC-8004 is een Draft Standards Track ERC met inzetbare identiteit‑ en reputatie‑primitieven. ERC-7943 is een definitieve Ethereum‑standaard. ERC-8226 bevindt zich op het standards‑track, en de kern‑interfaces zijn stabiel genoeg voor vroege implementatiewerkzaamheden. x402 is live en al ontworpen rond programmeerbare HTTP‑betalingen voor mensen en agenten.

De teams die dit goed doen, kunnen nu al naar deze stack bouwen of wachten tot audit‑ en compliance‑druk de retrofit afdwingt. De instellingen die dit goed doen, zullen degenen zijn die de mandaat‑ en identiteitslagen vanaf dag één behandelen als infrastructuurvereisten, op dezelfde manier als ze KYC en bewaring behandelen. Regelgevers hebben mogelijk nog niet expliciet elk onderdeel vereist. Teams die productie‑systemen in dit domein bouwen, weten al hoe duur het is om deze controles achteraf toe te voegen.