KI-Transformation

Agent Name Service (ANS): Das DNS für KI-Agenten – Identität, Vertrauen und Zukunft der autonomen KI-Ökonomie

Agent Name Service (ANS) ist das DNS für KI-Agenten: ein universelles Verzeichnis für sichere Identität, Discovery und Interoperabilität in Multi-Agenten-Systemen.

Agent Name Service (ANS): Das DNS für KI-Agenten – Identität, Vertrauen und Zukunft der autonomen KI-Ökonomie

Der Agent Name Service (ANS) ist ein universelles, protokollunabhängiges Verzeichnis-Framework – das DNS für KI-Agenten. Während das klassische DNS menschenlesbare Namen auf IP-Adressen auflöst, wandelt ANS Agentennamen in maschinenlesbare Deskriptoren um: mit Identität, Fähigkeiten, Endpunkten und kryptografischen Nachweisen. ANS löst das sogenannte O(n²)-Vertrauensproblem: Ohne gemeinsame Identitätsschicht muss jeder Agent jeden anderen manuell verifizieren – ein exponentiell wachsender Aufwand, der bei Millionen von Agenten nicht funktioniert. GoDaddy hat im November 2025 die erste öffentliche ANS-Registry gestartet. Die Spezifikation liegt als IETF Internet-Draft vor, entwickelt von Experten aus AWS, Intuit und Cisco. ANS ist kein Forschungsprojekt mehr – es ist aktive Infrastruktur.

Was ist Agent Name Service?

Autonome KI-Agenten sind nicht mehr nur Assistenten für Menschen. Sie kommunizieren direkt miteinander, rufen APIs auf, verwalten Ressourcen und treffen Entscheidungen ohne menschliche Aufsicht. Das erzeugt ein fundamentales Problem: Wie weiß ein Agent, ob der andere legitim ist? ANS beantwortet diese Frage mit einer zentralen Infrastrukturkomponente. So wie DNS florian-gahn.de auf eine IP-Adresse auflöst, löst ANS einen Agentennamen auf einen strukturierten Deskriptor auf – mit verifizierbarer Identität, deklarierten Fähigkeiten und kryptografischen Zertifikaten. Der Name selbst trägt Bedeutung. Ein ANS-Name wie a2a://RiskAnalyzer.Financial.AcmeCorp.v2.1.software kodiert: - Protokoll: a2a (Google Agent2Agent) - AgentID: RiskAnalyzer – eindeutiger Bezeichner - Capability: Financial – Kernfähigkeit - Provider: AcmeCorp – verantwortliche Organisation - Version: v2.1 – semantische Versionierung - Extension: software – optionale Deployment-Metadaten Dieses Format ermöglicht sowohl menschliche Lesbarkeit als auch maschinelle Verarbeitbarkeit. Agenten können gezielt nach bestimmten Fähigkeiten suchen, ohne jeden Endpunkt manuell zu kennen.

Das O(n²)-Vertrauensproblem

Mit dem Wachstum von KI-Agenten-Ökosystemen entsteht ein Skalierungsproblem, das ANS als O(n²)-Vertrauensproblem bezeichnet. Ohne gemeinsame Verzeichnisinfrastruktur muss jeder Agent jeden anderen bilateral verifizieren – mit manuellem Schlüsselaustausch, bilateralen Verträgen und maßgeschneidertem Code. Ein Praxisbeispiel: Ein kleines Unternehmen möchte seinen Support-Chatbot (Agent A) mit dem Lagerbestands-Agenten des Lieferanten (Agent B), einem Payment-Gateway-Agenten (Agent C) und dem CRM-Agenten (Agent D) verbinden. Ohne ANS erfordert jede dieser vier Verbindungen separate Authentifizierungslösungen. Mit hundert Agenten wird das System unbeherrschbar. ANS reduziert diesen Aufwand auf O(1) pro Verbindung: Jeder Agent registriert sich einmal, alle anderen können ihn direkt verifizieren.

Warum bestehende Protokolle nicht ausreichen

A2A (Google), MCP (Anthropic) und ACP (IBM) definieren, wie Agenten miteinander sprechen. Sie lösen aber nicht, mit wem gesprochen werden soll und ob dieser Gesprächspartner vertrauenswürdig ist. ANS füllt genau diese Lücke: Es ist die Adressierungs- und Discovery-Schicht, die diesen Protokollen fehlt. Wichtig: ANS konkurriert nicht mit A2A oder MCP – es ergänzt sie. Während MCP definiert, wie ein Modell Tools aufruft, definiert ANS, wie ein Agent einen anderen Agenten findet, der diese Tools anbietet. !Infografik Agent Name Service ANS: 36 Prozent unsichere Agenten-Skills, ANS-Namensschema mit Protokoll, Fähigkeit, Anbieter, Version und Umgebung, fähigkeitsbasierte Entdeckung, Zero-Knowledge-Berechtigungsnachweise sowie Vergleich von traditionellem DNS und ANS-Standard mit Adapter Layer für Google A2A, Anthropic MCP und IBM ACP Bild: KI-generiert

Wie funktioniert ANS?

Die ANS-Architektur ist modular aufgebaut und besteht aus fünf zentralen Komponenten.

Agent Registry

Das Herzstück ist das Agenten-Verzeichnis – eine verteilte oder zentrale Datenbank, die Profile aller registrierten Agenten speichert. Jedes Profil enthält: - Kryptografische Identität: PKI-Zertifikate (X.509) oder Dezentrale Identifikatoren (DIDs) - Capability-Deklaration: Was der Agent kann und wozu er autorisiert ist - Protokoll-Metadaten: Spezifische Informationen für A2A, MCP, ACP u. a. - Lebenszyklus-Timestamps: Registrierung, Erneuerung, Ablauf

PKI-Integration: Certificate Authority und Registration Authority

ANS nutzt die Public Key Infrastructure (PKI) als kryptografisches Fundament. Zwei Instanzen spielen dabei zusammen: Die Registration Authority (RA) prüft Registrierungsanfragen, validiert die Identität des Agenten-Betreibers (z. B. per Domain Control Validation) und erzwingt Registry-Richtlinien. Die Certificate Authority (CA) stellt daraufhin X.509-Zertifikate aus, die den öffentlichen Schlüssel des Agenten unwiderruflich an seinen ANS-Namen binden. Andere Agenten können Signaturen mit dem öffentlichen Schlüssel aus dem Zertifikat verifizieren – ohne direkte Kommunikation mit der CA. GoDaddy setzt dabei auf hybride Zertifikate: ein Server-Zertifikat für TLS-Verbindungssicherheit und ein separates Identitätszertifikat für die ANS-spezifische Authentifizierung.

Protocol Adapter Layer

Die Protokoll-Adapter-Schicht macht ANS protokollunabhängig. Sie übersetzt zwischen dem internen Registry-Format und den spezifischen Anforderungen von A2A, MCP, ACP und zukünftigen Standards. Adapter sind als pluggbare Module implementiert – neue Protokolle lassen sich ergänzen, ohne die Core-Registry zu verändern.

Transparency Logs

Manipulationssichere Transparenzprotokolle sichern die Integrität der Registry. ANS nutzt einen Merkle-Tree-basierten Ansatz analog zu RFC 6962 (Certificate Transparency). Jedes Lifecycle-Event – Registrierung, Update, Zertifikatserneuerung, Widerruf – wird als unveränderliches Leaf in den Baum eingetragen. Das Ergebnis: append-only Logs, die jede Manipulation sofort erkennbar machen. Jede Partei kann die Integrität unabhängig verifizieren, ohne der Registry-Betreiberin vertrauen zu müssen.

Zero-Knowledge-Proofs für Capability-Attestation

Über klassische PKI hinaus unterstützt ANS Zero-Knowledge-Proofs (ZKPs) für Capability-Nachweise. Ein Agent kann damit beweisen, dass er für bestimmte Aufgaben berechtigt ist – ohne die zugrundeliegenden sensiblen Daten preiszugeben. Beispiel: Ein Gesundheits-Agent weist nach, dass er Zugriff auf Patientendaten hat und HIPAA-konform arbeitet – ohne eine einzige Patientenzeile zu übermitteln.

Welche Vorteile hat ANS konkret?

ANS bringt vier strategische Vorteile, die in produktiven Multi-Agenten-Systemen den Unterschied machen.

Sicherheit durch Zero-Trust-Architektur

ANS implementiert ein echtes Zero-Trust-Modell für Multi-Agenten-Systeme: - Kein Standard-Vertrauen: Jede Verbindung erfordert kryptografische Authentifizierung, unabhängig von Netzwerkposition - Least Privilege: Agenten erhalten ausschließlich die minimal nötigen Berechtigungen - Instant Revocation: Bei Anomalien werden Zugriffsrechte in Echtzeit entzogen - Keine hardcodierten Secrets: API-Schlüssel und Passwörter in Konfigurationsdateien entfallen vollständig Die ClawHavoc-Kampagne vom Januar 2026 illustriert, warum das relevant ist: Angreifer registrierten 341 bösartige Agent-Skills in einem 3-Tage-Fenster, schleusten Malware in ungesicherte Netzwerke ein und schrieben Backdoors direkt in Session-Persistenz-Dateien. ANS mit obligatorischer CA-Validierung würde genau diese Art von Registry-Poisoning verhindern.

Capability-Aware Discovery

Klassisches DNS löst Namen auf Adressen auf – mehr nicht. ANS löst auf strukturierte Deskriptoren mit semantischen Fähigkeitsbeschreibungen auf. Ein Agent sucht nicht nach einer IP, sondern nach „einem Financial-Risk-Analyzer der Version 2.x, der A2A unterstützt und HIPAA-konform ist“ – und bekommt genau das.

Vollständige Auditierbarkeit

Jeder Lifecycle-Event ist manipulationssicher protokolliert. Unternehmen haben lückenlose Compliance-Nachweise: Welcher Agent hat wann mit wem kommuniziert? Welche Zertifikate waren zum Zeitpunkt X gültig? Die Antworten stehen im Transparency Log.

Nahtlose Enterprise-Integration

ANS ist für Produktionsumgebungen gebaut, nicht nur für Whiteboards. Es integriert sich direkt in: - Kubernetes für Infrastructure-Management - GitHub CI/CD-Pipelines für automatisiertes Deployment - Open Policy Agent (OPA) für Policy-Enforcement als Code - Prometheus und Grafana für Monitoring und Alerting

Wer treibt ANS voran?

Drei Akteure prägen die Entwicklung des Standards.

IETF-Standardisierung

ANS liegt seit Mai 2025 als Internet-Draft bei der IETF vor (draft-narajala-ans, überarbeitet als draft-narajala-courtney-ansv2, zuletzt aktualisiert April 2026). Autoren sind Experten von DistributedApps.ai, Amazon Web Services, Intuit und Cisco Systems. Die Spezifikation ist damit auf dem Weg zu einem offiziellen Internetstandard.

GoDaddy als Industry-Treiber

GoDaddy hat im November 2025 die erste öffentliche ANS-Registry gestartet. Die API ist für Entwickler offen zugänglich, der Quellcode liegt als Open-Source-Projekt auf GitHub (godaddy/ans-registry), und die offizielle Standards-Dokumentation ist unter AgentNameRegistry.org erreichbar. Für GoDaddy-eigene Domains läuft die Validierung vollautomatisch über Shopper-ID-Verifizierung. Externe Domains durchlaufen ACME-Challenges (DNS-01 oder HTTP-01).

OWASP Agentic Security Initiative

Das OWASP GenAI Security Project hat ANS v1.0 im Mai 2025 als sicherheitsfokussierte Spezifikation veröffentlicht. OWASP bringt dabei die Perspektive der Bedrohungsanalyse ein: Die ANS-Spezifikation enthält ein vollständiges Threat-Model mit definierten Angriffsszenarien (Agent Impersonation, Registry Poisoning, Credential Compromise) und den jeweiligen Gegenmaßnahmen.

Wie sieht die Zukunft von ANS aus?

ANS steht am Anfang. Die nächsten zwölf Monate entscheiden, ob es zum De-facto-Standard wird.

Nächste Entwicklungsschritte

Die IETF-Spezifikation benennt konkrete Vorhaben für die nächsten Versionen: - Framework-Integration: ANS soll direkt in LangChain, AutoGen und CrewAI eingebettet werden, damit Entwickler ohne Zusatzkonfiguration ANS-fähige Agenten bauen können - Reputation Systems: Vertrauensbewertungen, Endorsements und Attestierungen sollen direkt in Agenten-Profile integriert werden - Capability Negotiation Protocol: Ein standardisiertes Protokoll, mit dem Agenten nach der Discovery spezifische Service-Level-Agreements aushandeln und digital bindend schließen - Formale Verifikation: Mathematisch bewiesene Sicherheitseigenschaften für Registrierungs- und Auflösungsprotokolle

Offene Herausforderungen

ANS ist noch kein fertiger globaler Standard. Drei Probleme müssen gelöst werden: Namenskollisionen und Squatting: Wer verhindert, dass jemand mcp://GPT.Financial.OpenAI.v1 registriert, obwohl er keine Verbindung zu OpenAI hat? Ein Governance-Modell analog zu ICANN für DNS fehlt noch. Ein Governance-Whitepaper ist angekündigt, aber noch nicht veröffentlicht. Globale Skalierbarkeit: Milliarden von KI-Agenten – das ist keine Übertreibung, das ist die prognostizierte Entwicklung der nächsten Jahre. Distributed-Database-Architekturen (Cassandra, NoSQL) und Distributed Hash Tables (DHTs) für die Auflösung sind evaluiert, aber noch nicht produktionsskaliert getestet. Semantische Interoperabilität: ANS löst Identität und Discovery über Protokollgrenzen hinweg. Die tiefere semantische Frage – kann ein MCP-Agent und ein A2A-Agent wirklich dasselbe unter „Financial Risk Analysis“ verstehen? – bleibt offen. Standardisierte Capability-Ontologien und Übersetzungs-Gateways sind als Forschungsthema benannt, aber nicht spezifiziert.

ANS als Fundament der autonomen Maschinenökonomie

Die eigentliche strategische Bedeutung von ANS liegt jenseits von Sicherheit und Effizienz: Es ist die Voraussetzung für eine Maschinenökonomie, in der Agenten autonom Dienste kaufen, verkaufen und kombinieren. Agenten-Marktplätze wie das CreatorBid-Ökosystem brauchen genau das: verifizierte Identitäten mit transparenten Fähigkeitsnachweisen, ohne dass ein Marktplatzbetreiber jede Transaktion manuell prüft. GoDaddy positioniert ANS bewusst als Domain-Registrierung für die Agenten-Ära. Die Parallele ist nicht zufällig: Wer die Naming-Infrastruktur kontrolliert, hat strategische Relevanz in dem Ökosystem, das darauf aufbaut.

FAQ: Häufig gestellte Fragen zu Agent Name Service

Was ist der Unterschied zwischen ANS und DNS? DNS löst menschenlesbare Namen auf IP-Adressen auf und ist für statische Web-Hosts konzipiert. ANS löst Agentennamen auf strukturierte Deskriptoren auf – mit Identität, Fähigkeiten, Zertifikaten und Protokoll-Metadaten. ANS nutzt DNS als kryptografischen Vertrauensanker (Domain Control Validation), ersetzt es aber nicht. Ist ANS bereits produktionsreif? GoDaddys ANS-Registry ist seit November 2025 live und für Entwickler zugänglich. Die IETF-Spezifikation ist als Internet-Draft (Stand April 2026) aktiv in Revision. ANS ist damit produktiv nutzbar, aber noch kein ratifizierter RFC-Standard. Für Produktionseinsätze gilt: Die Registry-API ist stabil, das Governance-Modell für globales Squatting-Management noch nicht final. Welche Kommunikationsprotokolle unterstützt ANS? ANS ist protokollunabhängig. Der Protocol Adapter Layer unterstützt aktuell A2A (Google), MCP (Anthropic) und ACP (IBM). Neue Protokolle lassen sich als pluggbare Module ergänzen, ohne die Core-Registry zu verändern. Wie registriert man einen Agenten in ANS? Über die GoDaddy ANS API: API-Key generieren auf AgentNameRegistry.org, Registrierungsanfrage mit ANSName, Capability-Deklaration und Domain-Informationen senden. Bei GoDaddy-Domains läuft die Validierung automatisch per Shopper-ID. Externe Domains durchlaufen einen ACME-Challenge-Prozess. Das Zertifikat wird nach erfolgreicher Validierung automatisch ausgestellt. Was passiert, wenn ein Agent kompromittiert wird? ANS unterstützt sofortigen Zertifikatswiderruf (Instant Revocation). Der betroffene Agent wird im Transparency Log als widerrufen markiert – alle anderen Agenten erhalten bei der nächsten Auflösung den aktualisierten Status. Der Widerruf ist manipulationssicher im Merkle-Tree protokolliert. Wie verhält sich ANS zu Zero-Trust-Architekturen? ANS ist eine der Kernkomponenten für Zero-Trust in Multi-Agenten-Systemen. Es erzwingt obligatorische kryptografische Authentifizierung bei jeder Verbindung, Least-Privilege-Berechtigungen und kontinuierliche Identitätsvalidierung. Sicherheitsrichtlinien lassen sich als Code schreiben (OPA-Integration) und automatisch auf alle Agenten durchsetzen. Ist ANS dezentral oder zentral? Die aktuelle GoDaddy-Implementierung ist zentral betrieben, aber auf Dezentralisierung ausgelegt. Die Transparency-Log-Architektur (RFC 6962, Merkle Trees) ermöglicht dezentrale Verifikation ohne vertrauenswürdigen Dritten. Der IETF-Draft diskutiert einen „foundation-led root governance“-Ansatz mit delegierten Sub-Spaces – vergleichbar mit dem Modell, das die CNCF für Certificate Transparency nutzt.

Fazit

Agent Name Service ist die Infrastruktur, die Multi-Agenten-Systemen fehlt, um sicher zu skalieren. Das O(n²)-Vertrauensproblem ist real, und ANS löst es mit bewährten Mechanismen aus der Internet-Infrastruktur: DNS als Vertrauensanker, PKI für kryptografische Identität, Transparency Logs für Unveränderlichkeit. Die Tatsache, dass GoDaddy, AWS, Intuit und Cisco gemeinsam an der IETF-Spezifikation arbeiten, signalisiert: Das ist kein Nischenprojekt. Wer heute KI-Agenten in Produktionssystemen einsetzt, sollte ANS auf dem Radar haben. Wie KI-Agenten generell orchestriert werden, zeigt der Artikel zu KI-Agenten. Die zugrunde liegenden Kommunikationsprotokolle erklärt der Beitrag zum Modell-Kontext-Protokoll (MCP). Welche Sicherheitsrisiken in Agenten-Systemen aktuell am dringendsten sind, listet das OWASP Agentic Top 10.

Interaktive Inhalte werden geladen …