Agentenregister geben Auskunft darüber, was existiert, nicht darüber, ob man ihnen noch vertrauen kann.
Ein vierfragebasierter Rahmen für Register zu Agentenfähigkeiten, der Existenz, Eignung, Status und Herkunft umfasst, sowie ein einfacher Test zur letzten Überprüfung, den Sie noch heute durchführen können.
Stellen Sie sich einen Agenten bei einer routinemäßigen Aktion vor, der nach einem Tool anhand seines Namens sucht, es aufruft, eine sinnvolle Antwort erhält und fortfährt. Die Aktion ist erfolgreich – und das ist beunruhigend, denn niemand im Team hat jemals diese Funktionalität überprüft. Registrierungssysteme und Entdeckungsdienste sollen solche Situationen unter Kontrolle bringen, doch bereits innerhalb einer Woche trafen mehrere Produkte und Spezifikationen ein, die alle behaupteten, diese Kontrollschicht zu bieten.
Keines davon ist falsch, doch zusammen decken sie nur die Hälfte dessen ab, was ein Team wissen muss, bevor ein Agent eine neue Funktionalität verwendet. Dieser Artikel zerlegt das Problem in vier klare Fragen, zeigt auf, welche davon von aktuellen Registrierungssystemen beantwortet werden, und bietet eine konkrete Überprüfung sowie eine kurze Handlungsliste für die noch offenen Punkte.
Was in der Registrierungsschicht eingetroffen ist
Die unten aufgeführten Informationen spiegeln die Angaben zum Zeitpunkt der Erstellung wider; prüfen Sie die aktuelle Dokumentation, bevor Sie auf bestimmte Funktionen oder Versionen vertrauen.
AWS Agent Registry
Die Agent Registry auf AWS ist nun allgemein verfügbar. Man kann sie sich als einen privaten Katalog vorstellen, der über integrierte Steuerungsmechanismen verfügt und Agenten, MCP-Server, A2A-Agentenkarten, Fähigkeiten sowie beliebige benutzerdefinierte Ressourcen speichern kann. Beabsichtigt ist es, durch eine klare Trennung in zwei Ebenen zu arbeiten: Kuratoren arbeiten in einer Steuerungs-Ebene, in der Einträge genehmigt oder abgelehnt werden; Nutzer fragen hingegen eine Entdeckungs-Ebene ab, die ausschließlich genehmigte Einträge anzeigt. Jeder Eintrag durchläuft fünf Zustände (Entwurf, ausstehend, genehmigt, abgelehnt, veraltet). EventBridge-Ereignisse steuern den Übergang zwischen diesen Zuständen, und CloudTrail führt das Prüfprotokoll.
Mit der allgemeinen Verfügbarkeit kamen die Unterstützung für Infrastructure-as-Code (CloudFormation, CDK und Terraform), der Austausch zwischen Konten über RAM sowie die automatische Erkennung aller in einer Organisation bereits auf AgentCore laufenden Agenten. Diese Erkennungsfunktion wird oft übersehen, obwohl bereits unerfassene „Schatten“-Agenten zu ernsthaften Problemen bei der Inventarisierung führen. Zu den Unternehmen, die diese Technologie bereits einsetzen, gehören Southwest, PepsiCo, Syngenta, Amdocs und Sony – was darauf hindeutet, dass Käufer die Phase der Pilotprojekte hinter sich gelassen haben. AWS beschreibt das Design ausführlich auf seinem Machine-Learning-Blog.
Agentic Resource Discovery (ARD)
Neben diesem Ansatz gibt es eine von mehreren Anbietern unterstützte Spezifikation, die dasselbe Problem adressiert. Agentic Resource Discovery wurde von Mitarbeitern von Google, Microsoft und Hugging Face entwickelt und unter Apache 2.0 veröffentlicht; auch NVIDIA, Salesforce und Databricks trugen dazu bei. Die Berichterstattung von The New Stack beschreibt es als DNS für Agenten. Sein Funktionsumfang ist absichtlich begrenzt. Die Nachrichten werden im JSON-LD-Format über REST übertragen. Ein Endpunkt ist zwingend erforderlich – POST /search – und wird mit einer Beschreibung der Aufgabe statt mit dem Namen einer Ressource abgerufen. Anzeigendienste sind optional. Durch Federation kann ein Unternehmen sein eigenes Katalogsystem privat halten, während Anfragen an externe Register weitergeleitet werden, denen es vertraut. Zum Zeitpunkt der Erstellung liegt die Spezifikation bei Version 0,91; ihr Governance-Modell ist noch offen, und das W3C wird als möglicher Aufnahmepartner genannt.
Kontinuierliche Überprüfung als Produkt
Die dritte Neupositionierung betraf ein Startup namens AIR, das nach geheimer Entwicklung mit 50 Millionen Dollar aus zwei Seed-Runden finanziert wurde (Sequoia leitete die erste, Greenoaks die zweite). Das Unternehmen prüft die Plugins, Fähigkeiten sowie MCP-Server, die von Agenten verwendet werden. Eine Statistik von ihnen ist erwähnenswert: Rund 27 Prozent der öffentlich verfügbaren Fähigkeiten und Erweiterungen, die sie derzeit bewerten, werden ausgeschlossen.
Wenn innerhalb weniger Tage drei Neupositionierungen ein und denselben Bereich ansprechen, bedeutet das in der Regel, dass die Branche sich einig ist, wo das fehlende Element liegt.
Warum die Entdeckung nicht zu den Aufgaben von MCP gehört
MCP hat nie behauptet, das Problem der Werkzeugentdeckung lösen zu können. Es definiert die Mechanismen zur Aufrufung eines Tools, nachdem der Agent bereits entschieden hat, welches er verwenden will. A2A leistet eine ähnliche Funktion für Gespräche zwischen Agenten, die bereits voneinander wissen. In beiden Fällen wird davon ausgegangen, dass die Lokalisierung und Auswahl der erforderlichen Funktionalität bereits zuvor stattgefunden hat. Wenn Sie eine Erinnerung an diese Einteilung wünschen, lesen Sie wie das Model Context Protocol es Agenten ermöglicht, Werkzeuge zu entdecken und aufzurufen.
Was sich geändert hat, ist das Volumen. Die manuelle Verkabelung von MCP-Servern lässt sich mit einem Dutzend Werkzeugen bewältigen. Bei über tausend solcher Servern, die von verschiedenen internen Teams, SaaS-Anbietern und Cloud-Plattformen betrieben werden, ist ein Agent, der auf eine in seiner Konfiguration festgelegte Liste beschränkt ist, kaum noch ein Agent – er gleicht eher einem festen Skript, das zufällig ein Modell aufruft. Durch die Entdeckungsfunktion kann sich das Spektrum der verfügbaren Fähigkeiten laufend ändern. Gleichzeitig bedeutet das, dass niemand dieses Spektrum überprüft hat, und nur wenige Teams haben diesen Kompromiss in ihre Preisgestaltung einbezogen.
Ein weiterer Druck entsteht durch die Art und Weise, wie Agenten erweitert werden. Forscher, die den Quellcode von elf Produktions-Code-Tools untersuchten – insgesamt etwa vier Millionen Zeilen, die Tools wie OpenHands, Gemini CLI, Codex CLI und Claude Code umfassen (arXiv 2609.00006) – stellten fest, dass Fähigkeiten im SKILL.md-Stil dort MCP überholt haben: Neun der elf Tools unterstützen solche Fähigkeiten, acht unterstützen MCP. Somit ist das am schnellsten verbreitete Erweiterungsmechanismus eine Markdown-Datei, die voller Anweisungen ist, die ein Agent ausführen wird. Solche Dateien verfügen weder über ein Signierverfahren noch über nennenswerte Versionskontrolle, sodass eine Registry-Eintragung, die auf eine solche Datei verweist, nur wenig darüber verrät, was das Tool morgen tun wird.
Vier Fragen, die eine Registry beantworten sollte
Sobald ein Agent eine Funktion nutzen will, die ihm kürzlich noch nicht zur Verfügung stand, sind vier separate Antworten erforderlich. Sie klingen ähnlich, handeln aber um unterschiedliche Probleme – ihre Trennung zeigt, was ein bestimmtes Produkt tatsächlich leistet im Vergleich zu dem Zweck, für den es gekauft wird.
Existenz: Gibt es etwas, das dies kann?
Gibt es eine Funktion, die diese Aufgabe bewältigen kann, und wo ist sie untergebracht? Genau dafür dient ARDs POST /search, und auch das AWS Discovery-System erfüllt diese Aufgabe gut. Das Problem ist ernst, und aus praktischer Sicht ist es inzwischen nahezu gelöst.
Eignung: Welcher Kandidat eignet sich am besten für diese Aufgabe?
Eine Suche liefert mehrere Kandidaten – welchen sollte der Agent also verwenden? Die Autoren von ARD geben selbst an, dass hier der DNS-Vergleich nicht funktioniert: Eine Abfrage ergibt mehrere Kandidaten statt einer einzigen autoritativen Adresse, und jeder Dienst wendet seine eigenen Regeln für das Vertrauen sowie die Rangfolge an. Dies offen zu lassen, ist für eine junge Spezifikation vernünftig. Für Ihre Implementierung hingegen nicht, denn gerade bei der Rangfolge würde ein Angreifer am liebsten eingreifen, ähnlich wie bei Search-Engine-Poisoning oder Typosquatting in Paketregistern.
Status: Ist es derzeit bereits genehmigt?
Hier ist AWS am stärksten: Die Lebenszykluszustände zusammen mit den Ereignissen liefern eine gut strukturierte Antwort, die reifer ist als alles andere in diesen Systemen. Die Schwäche besteht darin, dass eine Genehmigung veraltet. Angenommen, ein Eintrag wurde durch automatische Erkennung erfasst, im März genehmigt und anschließend ignoriert. Im September gibt die Erkennungsfunktion ihn immer noch genauso zuverlässig aus, als hätte ein Kurator ihn heute Morgen überprüft.
Ursprung: Wer hat ihn verfasst und was hat sich geändert?
Wer hat diese Funktion entwickelt, was hat sich seit dem letzten Blick darauf geändert, und was wird bei der Ausführung geladen? In der aktuellen Welle an Veröffentlichungen gibt es darauf keine Antworten, und genau das ist die Grundlage für die Finanzierung von AIR. Ihre Argumentation, die weiterhin gilt, ist, dass die Überprüfung kontinuierlich stattfinden muss und nicht nur einmalig. Eine Fähigkeit, die vor einem Monat noch geprüft wurde, kann nach einem Update einer Abhängigkeit oder dem Entzug der Kontrolle über den Betreuer bösartig werden, während ihre Katalogeintragung unverändert bleibt. Auch wissenschaftliche Arbeiten deuten in diese Richtung. Jüngste Forschungen zu den Grundlagen fähigkeitsbasierter Agenten (arXiv 2608.29596) modellieren einen Lebenszyklus mit neun Phasen und stellen öffentliche Register, Marktplätze sowie Gegner in den Mittelpunkt der Architektur, anstatt sie als nachträgliche Aspekte zu betrachten.
Suchprobleme versus Lieferkettenprobleme
Die ersten beiden Fragen betreffen die Suche. Die letzten beiden beziehen sich auf die Lieferkette – und die Branche hat das bereits mit Browser-Erweiterungen, Container-Basisbildern sowie npm-Paketen durchgemacht. In jedem Fall existierten Kataloge lange, bevor jemand garantieren konnte, was sich darin befand, und die Sicherheitsvorfälle traten in diesem Zeitraum auf.
Der zuletzt überprüfte Test
Diese Überprüfung ist absichtlich einfach gehalten, denn die Antwort ist wichtiger als das Framework. Nehmen Sie Ihre aktuelle Liste der Agentenfähigkeiten – sei es ein ordnungsgemäßes Registry-System oder einfach nur eine Tabellenkalkulation – und wählen Sie einen Eintrag aus. Suchen Sie anschließend nach zwei Zeitstempeln:
- Wann wurde er genehmigt?
- Wann hat jemand – sei es ein Mensch oder eine automatisierte Aufgabe – ihn zuletzt mit seiner Quelle verglichen?
Wenn diese Zeitstempel übereinstimmen, handelt es sich um einen Katalog und nicht um ein Steuerungsmodul. Der erste dokumentiert eine frühere Entscheidung; der zweite spiegelt die aktuelle Realität wider. Zählen Sie die Tage zwischen den beiden Datumsangaben – so lange kann eine von jemandem genehmigte, anschließend vergessene Funktion ungehindert geändert werden, ohne dass jemand es bemerkt. Angesichts der Tatsache, dass bereits rund ein Viertel der öffentlich verfügbaren Fähigkeiten einer grundlegenden Überprüfung nicht standhält, ist diese Zahl ein angemessener Indikator für Ihre tatsächliche Exposition.
Viele Teams haben keinen zweiten Zeitstempel zur Verfügung. Diese Abwesenheit ist das eigentliche Problem: Es liegt nicht an einem schlechten Wert, sondern an einem fehlenden Feld.
Was in diesem Quartal zu tun ist
Der praktische Plan besteht aus drei Teilen, geordnet nach Aufwand.
- Einführung eines Registriersystems. Die Verwaltung von Inventaren stellt ein ernsthaftes Problem dar, und ein unüberwachter Agent ist gefährlicher als eine unüberwachte SaaS-Abonnementlösung, da er eigenständig agiert. Teams, die bereits auf Bedrock aufbauen, sollten sich intensiv mit der AWS-Option beschäftigen; wer Föderierung und Anbieterneutralität benötigt, könnte ARD bevorzugen.
- Hinzufügen des Feldes, das dem Registrierungssystem fehlt. Geben Sie jeder Eintragung ein Datum der letzten Überprüfung, das von einer automatisierten Aufgabe aktualisiert wird und nicht von einem Menschen. Entscheiden Sie im Voraus, was eine Veraltungsanzeige auslöst: Ablaufdatum, Quarantäne oder ein Alarm. Jede dieser Optionen ist besser als das heutige typische Verhalten, bei dem veraltete Einträge einfach endlos aktiv bleiben.
Ein nützlicher Begleiter zu diesem Ansatz ist eine Laufzeitsteuerungsschicht, die entscheidet, was eine entdeckte Fähigkeit tatsächlich tun darf; Rechte, Genehmigungsmechanismen und Risikostufen für Agenten behandeln diesen Aspekt.
Kernpunkte
- Registrierungsplattformen und Entdeckungsspezifikationen beantworten mittlerweile recht gut die Fragen „Was existiert?“ und „Ist es genehmigt?“.