SOC 2 Typ II-zertifiziert · ISO 27001

KI-Agenten können Code generieren, Workflows ausführen und mit externen Diensten interagieren.

Neue Werkzeuge zu finden, ist nach wie vor viel schwieriger.

Die meisten Agenten stützen sich auf zuvor konfigurierte Integrationen, sei es über Eingabeaufforderungen, Frameworks, APIs oder Marktplätze. Da die Zahl der für Agenten zugänglichen Dienste wächst, lässt sich dieser Ansatz nur schwer skalieren.

ERC-8257 verspricht eine genehmigungsfreie Möglichkeit, agentische Tools und Dienste zu finden und zu überprüfen.

In diesem Blogbeitrag wird erläutert, was ERC-8257 ist, wie ein Agent-Tool-Register funktioniert, wie es sich in den gesamten Agent-Infrastruktur-Stack einfügt und welche Möglichkeiten dieses Register eröffnet.

Was ist ERC-8257?

ERC-8257 (Agent Tool Registry) ist ein Entwurf für einen Ethereum-Standard, der ein zugangsfreies On-Chain-Register für KI-Agenten und -Tools definiert. Er standardisiert eine minimale, überprüfbare Aufzeichnung darüber, was ein Tool ist, wer es veröffentlicht hat und wer es aufrufen darf.

Im April 2026 schlugen Cody Sears und Ryan Ghods von OpenSea diesen Standard vor, um KI-Agenten die Möglichkeit zu geben, Tools selbstständig zu finden, Zugriff darauf zu erwerben und diese aufzurufen.

So funktioniert ERC-8257

Für jedes registrierte Tool oder jeden ERC-8257-kompatiblen Agenten wird ein On-Chain-Eintrag mit drei Komponenten angelegt:

1. Angabe zum Urheber: der Herausgeber, bei der Registrierung dauerhaft festgehalten

2. Metadaten-URI: Ein Verweis auf das Off-Chain-Manifest des Tools

3. Manifest-Hash: Überprüft, ob sich die Beschreibung nicht geändert hat

Und eine optionale vierte Komponente im Zugriffsprädikat, nämlich eine Vertragsadresse, die festlegt, wer das Tool aufrufen darf.

Zusammen bilden diese Elemente eine gemeinsame, verlässliche Quelle für Tool-Metadaten mit einer Garantie: Das von Ihnen abgerufene Manifest ist genau dasjenige, das der Ersteller von dem von ihm kontrollierten Ursprung aus unter der von ihm signierten Adresse committet hat.

Nachdem wir nun den Zweck und die Komponenten der Agent-Tool-Registrierung verstanden haben, wollen wir uns nun damit befassen, wie diese zusammenwirken und wie der Ablauf aussieht.

Im Rahmen von ERC-8257 gibt es zwei Arbeitsabläufe, nämlich:

1. Ablauf der Registrierung: Interaktion zwischen Herausgeber und Register.

2. Ermittlungs- und Verifizierungsablauf: Zusammenspiel zwischen Akteuren, Register und Tools.

Schauen wir uns das jeweils einzeln an.

ERC-8257: So funktioniert der Registry-Ablauf

Der Registrierungsablauf legt fest, wie ein Tool veröffentlicht und auffindbar gemacht wird. Ein Herausgeber registriert die Adresse des Tool-Erstellers, die Metadaten-URI und den Manifest-Hash (sowie ein optionales Zugriffsprädikat) und erstellt so den On-Chain-Eintrag, den Agenten später auflösen und verifizieren können.

ERC-8257: So funktionieren die Erkennung und die Überprüfung

Wenn ein Agent ein Tool oder einen Dienst findet, schafft dieser Erkennungs- und Überprüfungsprozess Vertrauen in die Metadaten, die der Agent ausliest.

Die Rolle der Registrierungsstelle endet, sobald der Beauftragte überprüft hat, dass das Manifest, der Herausgeber und die Zugangsvoraussetzungen mit dem registrierten Eintrag übereinstimmen.

Bislang scheint ERC-8257 ein gewöhnliches Register zu sein, doch durch den optionalen Prädikatabschnitt wird ERC-8257 zu mehr als nur einem Register.

ERC-8257-Zugriffskontrolle: Das Prädikatmuster erklärt

Die Agent-Tool-Registrierung löst die Probleme der Erkennung und Überprüfung. Allerdings sollte nicht jedes Tool von jedem Agenten aufrufbar oder vollständig öffentlich sein.

Für einige Dienste ist möglicherweise ein Abonnement erforderlich. Andere Dienste sind möglicherweise auf NFT-Inhaber, Unternehmenskunden oder Vertreter beschränkt, die bestimmte Reputationsanforderungen erfüllen.

ERC-8257 löst das Zugriffsproblem mithilfe einer optionalen Komponente, die als „Zugriffsprädikat“ bezeichnet wird: ein externer Vertrag, der entscheidet, ob ein Aufrufer ein Tool nutzen darf.

Was ist prädikatbasierte Zugriffskontrolle?

Ein Zugriffsprädikat ist eine Vertragsadresse, die einer Werkzeugregistrierung zugeordnet ist.

Wenn ein Agent versucht, ein Tool zu nutzen, kann er den Prädikatvertrag aufrufen und eine einfache Frage stellen: Darf dieser Aufrufer auf dieses Tool zugreifen?

Nun kann der Prädikatvertrag prüfen, ob ein Akteur ein NFT besitzt, einen Abonnement-Token hält, für den Zugriff bezahlt hat, auf einer Zulassungsliste steht oder eine Reputationsanforderung erfüllt.

Verschiedene Tools können unterschiedliche Richtlinien umsetzen, ohne dass Änderungen an der Registrierungsdatenbank selbst erforderlich sind. Hier sind einige Beispiele:

Vor allem aber sind in ERC-8257 keine dieser Regeln fest codiert; stattdessen wird der Prädikat-Vertrag als optionales Add-on behandelt, wodurch der Standard schlank bleibt und gleichzeitig für eine Vielzahl von Anwendungsfällen erweiterbar ist.

Wir wissen nun, was die Agent-Tool-Registrierung ist, wie sie registriert wird, wie Agenten sie erkennen und wie der Zugriff gesteuert wird. Als Nächstes: Was lässt sich damit erstellen?

Was ERC-8257 ermöglicht

Ein Register an sich ist nicht besonders interessant.

DNS gewann an Bedeutung, weil Websites über dieses System gefunden werden konnten. Paketregister gewannen an Bedeutung, weil Software darauf zurückgreifen konnte. App-Stores gewannen an Bedeutung, weil sie Nutzer mit Anwendungen verbanden.

ERC-8257 schafft eine Discovery-Ebene für Tools, auf die Agenten zugreifen können. Sehen wir uns einige Funktionen an, die dadurch ermöglicht werden:

1. Agentische Marktplätze

Jedes Tool verfügt über eine nachweisbare Herkunft, programmierbaren Zugriff und Preisangaben in der Blockchain. Das reicht aus, um einen Marktplatz aufzubauen, auf dem Tools entdeckt, genutzt und gehandelt werden können, ohne dass ein Plattformbetreiber dabei als Vermittler auftritt.

2. Märkte für programmierbaren Zugang

Ein Tool-Anbieter kann über den Prädikat-Vertrag Preise, Abonnements, Anforderungen an den Token-Besitz, Reputationsschwellenwerte oder Unternehmensberechtigungen festlegen. Diese Flexibilität ermöglicht den Wettbewerb zwischen verschiedenen Zugriffsmodellen, während die Interoperabilität auf der Discovery-Ebene gewahrt bleibt.

3. Modular aufgebaute Agenten-Workflows

Mit ERC-8257 sind nun mehrstufige Agent-Pipelines möglich, bei denen jedes Tool unabhängig überprüft und freigegeben wird.

Beispielsweise kann ein Handelsagent mit einem rund um die Uhr verfügbaren Tool zum Auslesen von Nachrichten verknüpft werden, oder ein Prognosemarkt-Agent kann mit einem Twitter (X)-Agenten verbunden werden.

ERC-8257 bietet eine standardisierte Methode zur Ermittlung und Überprüfung dieser Abhängigkeiten, wodurch sich Multi-Agent-Workflows über unabhängige Anbieter hinweg einfacher zusammenstellen lassen.

4. Offene Agent-Ökosysteme

Jede Plattform steht irgendwann vor derselben Herausforderung: die Pflege eines eigenen Verzeichnisses ihrer Dienste.

ERC-8257 verlagert diese Verantwortung auf eine gemeinsam genutzte Infrastruktur. Tool-Anbieter veröffentlichen die Daten einmalig. Agent-Frameworks, Wallets, Marktplätze und Anwendungen greifen auf dieselben Datensätze zu.

5. Organisationsübergreifende Agenten-Workflows

Die meisten Agenten-Workflows werden heute innerhalb einer einzigen Organisation oder Plattform abgewickelt.

ERC-8257 ebnet den Weg für organisationsübergreifende Arbeitsabläufe wie beispielsweise zwischen Anbietern und Kunden, zwischen Kunden und Marktplätzen und vieles mehr.

So könnte beispielsweise ein Forschungsbeauftragter Zugriff auf proprietäre Datenfeeds erwerben, die über registrierte Tools bereitgestellt werden.

Die Funktionsweise und die Fähigkeiten von ERC-8257 sind nun bekannt. Als Nächstes gilt es, den umfassenderen Agent-Stack zu verstehen, der erforderlich ist, damit die Agenten tatsächlich funktionieren können.

Die Einbindung von ERC-8257 in den Agentic-Infrastruktur-Stack

ERC-8257 löst ein spezifisches Problem innerhalb des übergeordneten Agenten-Stacks: die Ermittlung von Fähigkeiten und die überprüfbare Interaktion.

Allerdings benötigen die Akteure nach wie vor Identitäten, Ausführungsumgebungen, Zahlungswege und Koordination, um miteinander interagieren zu können.

Lassen Sie uns nun den Stapel zusammenstellen.

Aus dieser Perspektive betrachtet wirkt ERC-8257 weniger wie ein AI-Standard, sondern eher wie eine Infrastruktur.

• Ein registriertes Tool kann einen MCP-Server offenlegen.

• Ein Prädikat kann eine Zahlung verlangen, bevor der Zugriff gewährt wird.

• Ein Standard zur Identitätsfeststellung kann verwendet werden, um nachzuweisen, wer die Anfrage stellt.

Keine dieser Aufgaben obliegt ERC-8257 selbst.

Die Aufgabe des Standards besteht darin, eine einfachere Frage zu beantworten: „Welche Funktionen stehen zur Verfügung und wo sind sie zu finden?“

Nun, die Architektur ist solide, ebenso wie die Designentscheidung. Die offenen Fragen betreffen die Akzeptanz.

Wie geht es weiter mit ERC-8257?

Die meisten Softwareprogramme basieren heutzutage auf direkten Integrationen.

Ein Entwickler wählt einen Dienst aus, liest dessen Dokumentation, schreibt Code auf Basis dessen API und pflegt diese Beziehung im Laufe der Zeit.

ERC-8257 trägt nicht dazu bei, sondern lenkt die Entwicklung der agentenbasierten Infrastruktur in eine andere Richtung.

• Funktionen werden zur Laufzeit erkennbar.

• Zugriffsrichtlinien lassen sich programmieren.

• Dienste können ohne menschliche Genehmigung in Anspruch genommen werden.

ERC-8257 ist eine gängige Discovery-Schicht. Das mag wie ein kleiner Teil der Infrastruktur erscheinen.

DNS war ein kleiner Teil der Infrastruktur. Paketregister waren ein kleiner Teil der Infrastruktur. App-Stores begannen als Verzeichnisse.

Die größere Herausforderung liegt noch vor uns.

Wie sollten Akteure die Reputation bewerten? Wie sollten Marktplätze Tools einstufen? Nach welchen Standards sollten Zahlungen, Abonnements oder die Umsatzbeteiligung zwischen autonomen Systemen geregelt werden? Wie sollten Organisationen interne Fähigkeiten offenlegen, ohne die Sicherheit zu gefährden?

ERC-8257 gibt keine Antworten auf die Fragen. Es leitet den Dialog und den Lösungsweg ein.

FAQs (Häufig gestellte Fragen)

1. Wie funktioniert ERC-8257?

Ein Anbieter registriert ein Tool, indem er eine Erstelleradresse, eine Metadaten-URI, einen Manifest-Hash und optional ein Zugriffsprädikat veröffentlicht. Agenten rufen das Manifest ab, überprüfen es anhand des On-Chain-Eintrags, werten etwaige Zugriffsanforderungen aus und rufen dann das Tool auf.

2. Was ist ein ERC-8257-Manifest?

Ein Manifest ist eine maschinenlesbare Beschreibung eines Tools. Es enthält Metadaten wie Funktionen, Endpunkte, Nutzungsanforderungen und weitere Informationen, die Agenten benötigen, um den Dienst zu verstehen und mit ihm zu interagieren.

3. Ist ERC-8257 nur für KI-Agenten gedacht?

Nein. Jeder maschinell zugängliche Dienst kann über ERC-8257 registriert werden. Der Standard wurde zwar speziell für KI-Agenten entwickelt, doch auch APIs, Software-Dienste, Automatisierungssysteme und andere programmierbare Anwendungen können dasselbe Erkennungsmodell nutzen.

4. Inwiefern unterscheidet sich ERC-8257 von MCP?

MCP standardisiert die Art und Weise, wie Tools bereitgestellt und aufgerufen werden. ERC-8257 standardisiert die Art und Weise, wie Tools erkannt und verifiziert werden. Beide Standards ergänzen sich und können innerhalb derselben Agentenarchitektur gemeinsam genutzt werden.

5. Was können Entwickler mit ERC-8257 erstellen?

Entwickler können auf der Grundlage eines gemeinsamen Registrierungsstandards Agent-Marktplätze, programmierbare Zugangssysteme, organisationsübergreifende Agent-Workflows, Service-Discovery-Ebenen und Multi-Agent-Ökosysteme aufbauen.

6. Ist ERC-8257 im Mainnet verfügbar?

Ja. Der ToolRegistry-Vertrag wird unter 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 im Ethereum-Mainnet und auf Base. Stand Mitte 2026 sind 76 Tools indexiert. Der EIP befindet sich weiterhin im Entwurfsstatus, was bedeutet, dass sich die Schnittstelle vor der endgültigen Festlegung noch ändern kann.

7. Speichert ERC-8257 Metadaten zu Tools in der Blockchain?

Nein. Die Registrierungsstelle speichert Verweise auf Metadaten und nicht die Metadaten selbst. Die Beschreibungen der Tools verbleiben außerhalb der Blockchain, während die in der Blockchain gespeicherten Hashes es den Agenten ermöglichen, deren Integrität zu überprüfen.