Der agentische Stack hat vier Schichten. Bei den meisten Deployments fehlen drei

Identität, Reputation, Mandat und Zahlung müssen on-chain leben. In vielen Produktions-Deployments ist das noch nicht der Fall, und das ist ein architektonisches Problem, kein nachträglicher Compliance‑Gedanke.

Ich verbringe viel Zeit damit, zu untersuchen, wie Produktions‑Agent‑Deployments tatsächlich verkabelt sind, und das Muster ist oft dasselbe: das Modell ist leistungsfähig und das Orchestrierungs‑Framework ist vernünftig, doch die Authentifizierungsschicht ist immer noch ein gemeinsam genutzter API‑Schlüssel, der seit Monaten nicht rotiert wurde.

Die Infrastruktur für autonome Agenten hat nicht mit den darauf laufenden Modellen Schritt gehalten. Der agentische Stack besteht aus vier Komponenten, die nativ on-chain sein müssen: Identität, Reputation, Mandat und Zahlung. In den meisten Produktions‑Deployments, die ich sehe, werden sie nachträglich angeheftet, falls sie überhaupt existieren.

Und das ist im regulierten Finanzwesen wichtiger als überall sonst. Ein Agent, der mit tokenisierten Wertpapieren handeln, Treasury‑Aktionen genehmigen oder Positionen zuweisen kann, muss nachweisen können, zu welchen Aufgaben er autorisiert wurde, wer ihn autorisiert hat, innerhalb welcher Grenzen und wo das on-chain‑Protokoll dieser Autorität gespeichert ist. Die meisten Deployments können das heute nicht sauber beantworten. Ohne dieses Protokoll ist der Agent selbst das Audit‑ und Compliance‑Risiko.

Warum gemeinsam genutzte API‑Schlüssel das falsche Primitive sind

Das Authentifizierungsmodell, das die meisten Agent‑Deployments von SaaS übernehmen, ist ein gemeinsam genutztes Geheimnis, das in einem Header übergeben wird. Es authentifiziert den aufrufenden Service, sagt jedoch nichts über den konkreten Agenten aus, der den Aufruf tätigt, oder darüber, zu welchen Aktionen dieser Agent berechtigt ist, und hinterlässt keinen Datensatz, der einer Prüfung durch einen Regulierer standhält. Jede Agenten‑Aktion kann nur demjenigen zugeordnet werden, der den Schlüssel besitzt, was in der Praxis bedeutet, dass die Attribution zusammenbricht, sobald mehr als ein Agent oder mehr als ein Betreiber vorhanden ist.

Die Alternative ist eine signaturbasierte Abwicklung pro Anfrage. Jede Anfrage wird von der eigenen Wallet des Agenten signiert und kryptografisch zum Zeitpunkt des Aufrufs abgewickelt. Dafür ist x402 gebaut, wobei Authentifizierung und Zahlung gemeinsam gehandhabt werden. Das liefert Institutionen einen Nachweis, welche Wallet gehandelt hat, wann sie gehandelt hat und wofür sie bezahlt hat – ein Ledger, das einer Prüfung standhalten kann.

Die Identitätslücke

ERC-8004 definiert on-chain Identität für vertrauenslose Agenten: ein Register, in dem ein Agent mit einer kontrollierenden Wallet, einem Service‑Endpunkt und einer Modellreferenz registriert wird. Momentan ist dieser Agent nur ein undurchsichtiger Prozess, der innerhalb der Infrastruktur eines Anbieters läuft. Der Registereintrag macht ihn zu einem erstklassigen on-chain Akteur mit nachweisbarer Herkunft – etwas, das ein Smart Contract oder ein Compliance‑Dashboard direkt prüfen kann, ohne einem Zwischenhändler zu vertrauen.

Die Reputationsebene baut darauf auf. Rückmeldesignale, die in das ERC‑8004‑Register geschrieben werden, sind unveränderlich, mit Zeitstempel versehen und zuordenbar. Jedes System, das Vertrauensentscheidungen über einen Agenten treffen möchte, kann dieses Register direkt lesen. Im Gegensatz zu einem vom Anbieter verwalteten Score oder einer Discord‑Bewertung ist das Vertrauen hier eine Eigenschaft des Netzwerks und nicht desjenigen, der die Datenbank kontrolliert.

Beide Ebenen sind heute ohne exotische Technik implementierbar. Die meisten Deployments besitzen sie nicht, weil der Weg des geringsten Widerstands immer noch darin besteht, Agenten als Service‑Konten statt als erstklassige Akteure zu behandeln. Eine vernünftige Abkürzung im Prototyp wird zu technischer Schuld, die in der Produktion anwächst.

Das Mandatsproblem ist der Punkt, an dem regulierte Finanzen von allem anderen abweichen

Identität und Reputation sagen Ihnen, wer ein Agent ist und wie er sich verhalten hat. Sie legen nicht fest, zu welchen Handlungen der Agent autorisiert ist. In vielen Anwendungsfällen von Agenten können Kontrollen auf Anwendungsebene diese Lücke schließen. Für Agenten, die mit regulierten Vermögenswerten arbeiten, wird die Autorisierungsfrage zu einer rechtlichen Frage. Die Antwort muss in einer Form vorliegen, die einen Regulierer zufriedenstellt.

ERC-8226, der Regulated Agent Mandate Standard (RAMS), ist dazu gedacht, diese Lücke zu schließen. RAMS definiert eine Compliance‑Delegationsschicht, die zwischen der Agenten‑Identität und token‑basierten Compliance‑Frameworks liegt. Ein KYC‑verifizierter Prinzipal gewährt einem Agenten ein Mandat mit definiertem Umfang, Zuständigkeitsbereich, Wertgrenzen und Ablaufdatum. In der Praxis funktioniert es wie eine on-chain Vollmacht, die vor der Abwicklung geprüft werden kann. Der regulierte Token‑Vertrag prüft dann das Mandat atomar in seinem Pre‑Transfer‑Compliance‑Hook, bevor irgendeine Abwicklung stattfindet.

Zwei Schnittstellen tragen das Design. `ComplianceProvider` wird von jedem KYC‑ oder Attestations‑Operator implementiert und bescheinigt die Berechtigung des Prinzipals für einen bestimmten Umfang. `IAgentMandate` ist das Register, das Gewährungen, Erweiterungen, Widerrufe, Ausführungen und regulatorische Sperren erfasst. Die Durchsetzung erfolgt über `recordExecution`, das die Grenzen des aktiven Mandats zum Transferzeitpunkt prüft und die Transaktion zurücksetzt, wenn sie diese überschreiten würde.

Diese Architektur sitzt zwischen der ERC‑8004‑Identität und Token‑Compliance‑Frameworks wie ERC-7943, anstatt eines von beiden zu ersetzen. Identität besagt, dass der Agent existiert und verifizierbar ist; Token‑Compliance, dass der Prinzipal berechtigt ist, diesen spezifischen Vermögenswert zu halten. RAMS fügt den Teil hinzu, den weder das eine noch das andere abdeckt: Autorität von diesem Prinzipal, für diesen Umfang, innerhalb dieser Grenzen, bis zu diesem Datum. Die rechtlich durchsetzbare Delegationsschicht, die derzeit nur in PDFs und Back‑Office‑Tabellen existiert, wird on-chain verlagert, wo sie tatsächlich zum Transferzeitpunkt durchgesetzt werden kann.

Die Trennung von Vorbereitung und Ausführung ist kein Friktionspunkt

Eine Design‑Entscheidung verdient eine direkte Verteidigung: die Trennung von Transaktionsvorbereitung und dem Signieren sowie Broadcasten. Sie wird in vielen Systemen weggelassen, die Agenten nahtloser erscheinen lassen wollen.

Der Instinkt ist, diese zu einem einzigen Schritt zu verschmelzen, weil es effizienter erscheint. Doch die Lücke zwischen Vorbereitung und Broadcast ist genau dort, wo institutionelle Aufsicht stattfinden muss. Dort prüft ein Compliance‑Officer, was ein Agent vorhat, bevor die Chain davon erfährt, dort validiert ein RAMS‑Mandats‑Check die vorbereiteten Daten gegen den aktiven Umfang, Wertgrenzen und die Zuständigkeit, bevor irgendeine Signatur erzeugt wird, und dort genehmigt ein CFO eine Treasury‑Aktion, die ein Agent vorbereitet, aber noch nicht ausgeführt hat.

Viele Institutionen, die autonome Agenten in bedeutendem Umfang einsetzen, bauen diese Trennung schließlich wieder ein, wenn sie feststellen, dass sie fehlt. Sie bauen sie als bewusstes architektonisches Primitive ein, anstatt sie nachträglich als Retrofit zu implementieren, das ein System erst durch seine erste Compliance‑Prüfung trägt.

Wie der Stack aussieht, wenn er vollständig ist

Wenn alle vier Schichten vorhanden sind, fügen sie sich sauber zusammen. ERC‑8004 verankert die Agenten‑Identität und die on-chain Reputation, und ERC‑8226 fügt die Mandatsschicht hinzu, die festlegt, was jeder Agent im Namen von wem tun darf. x402 übernimmt die Abwicklung, signiert jede Anfrage, sodass jede Aktion zuordenbar und prüfbar ist. Darunter setzen regulierte Asset‑Frameworks wie ERC‑7943 die Compliance zum Transferzeitpunkt sowohl gegenüber der Berechtigung des Prinzipals als auch dem aktiven Mandat des Agenten durch.

Diese Bausteine befinden sich auf unterschiedlichen Reifegraden, aber keiner von ihnen ist rein theoretisch. ERC‑8004 ist ein Draft Standards Track ERC mit einsetzbaren Identitäts‑ und Reputations‑Primitiven. ERC‑7943 ist ein finaler Ethereum‑Standard. ERC‑8226 befindet sich im Standards‑Track, und die Kern‑Schnittstellen sind stabil genug für frühe Implementierungsarbeiten. x402 ist live und bereits um programmatische HTTP‑Zahlungen für Menschen und Agenten herum konzipiert.

Die Teams, die das richtig umsetzen, können jetzt auf diesen Stack hinarbeiten oder warten, bis Prüfungs‑ und Compliance‑Druck das Nachrüsten erzwingt. Die Institutionen, die das richtig machen, werden diejenigen sein, die die Mandats‑ und Identitätsschichten von Anfang an als Infrastruktur‑Anforderungen behandeln, so wie sie KYC und Verwahrung handhaben. Regulierer haben möglicherweise noch nicht explizit jedes Teil davon gefordert. Teams, die Produktionssysteme in diesem Bereich bauen, wissen bereits, wie teuer es ist, diese Kontrollen nachträglich hinzuzufügen.