Agent Name Service: Bekommen KI-Agenten jetzt eine überprüfbare Identität?

Was die Linux Foundation am 10. November wirklich angekündigt hat

Die Linux Foundation hat Agent Name Service (ANS) am 10. November 2026 als offenes Projekt unter ihr Dach genommen. Ziel ist eine verifizierbare Identität für Softwareagenten, die über Domains und Plattformen hinweg gefunden und angesprochen werden können. Laut Ankündigung umfasst die Spezifikation sieben Dokumente; elf Organisationen unterstützen das Vorhaben. Das ist eine Governance- und Standardisierungsnachricht, keine flächendeckende Freischaltung eines fertigen Internet-Verzeichnisses.

Der Zeitpunkt ist relevant: Agenten arbeiten zunehmend über Unternehmensgrenzen hinweg. Ein A2A-Aufruf, eine MCP-Verbindung oder ein Einkauf durch einen Agenten erfordert mehr als die Behauptung, für eine bestimmte Firma zu handeln. Ein Gegenüber muss zuerst ermitteln können, welcher Betreiber oder welche Domain hinter dem Agenten steht. ANS adressiert diese Identitätsfrage, nicht automatisch die Qualität seiner Antworten.

Wie DNS, Zertifikate und öffentliche Logs zusammenspielen

ANS baut auf DNS als öffentlichem Namensraum auf. Ein Betreiber kann eine Agentenidentität an seine Domain binden und die dafür vorgesehenen Informationen über DNS veröffentlichen. Zertifikatsbasierte Signale sollen die Prüfung der Zuordnung unterstützen. Die Dokumente sehen außerdem Registrierung, Versionierung, öffentliche Audit-Logs, Integritätsüberwachung und Agent-zu-Agent-Authentifizierung vor.

Der praktische Ablauf ist deshalb mehrstufig: Ein Client entdeckt den Agenten, überprüft die veröffentlichte Domainbindung und die zugehörigen Nachweise, kontrolliert Aktualität oder Änderungen und trifft erst anschließend eine eigene Zugriffsentscheidung. Ein DNS-Eintrag allein ersetzt keine sichere Verbindung, und ein gültiges Zertifikat ersetzt keine Berechtigung für eine konkrete Handlung.

Warum Identität und Autorisierung zwei verschiedene Probleme sind

Ein verifizierter Agent kann dennoch falsch konfiguriert sein, irreführende Anweisungen erhalten oder mehr Daten verlangen, als seine Aufgabe benötigt. Die technische Identität beantwortet „Wen habe ich vor mir?“. Autorisierung beantwortet „Was darf diese Identität hier tun?“. Das sind getrennte Kontrollschichten. Für eine Überweisung, einen Datenexport oder eine Produktionsänderung benötigen Betreiber zusätzliche Rechteprüfung, Begrenzung der Werkzeuge und gegebenenfalls eine menschliche Freigabe.

AgentenCode-Einordnung: Eine öffentlich prüfbare Identität wird erst dann zum echten Vertrauenssignal, wenn ihre Prüfung vor der Werkzeugfreigabe erzwungen wird. Verzeichnis- oder Zertifikatsdaten dürfen nicht mit einem Gütesiegel für Sicherheit, Leistung oder Compliance verwechselt werden.

Erste Interoperabilität: AGNTCY Directory und ANS Finder

Als konkrete frühe Integrationen nennt die Linux Foundation den AGNTCY Agent Directory Service, der ANS-Identitäten prüfen kann. ANS Finder ist nach Angaben der Initiatoren interoperabel mit Agentic Resource Discovery (ARD) und hat dessen Registry-Konformitätstests bestanden. Diese Nachweise betreffen definierte Discovery-Schnittstellen, nicht die Gesamtsicherheit beliebiger Agenten oder ein universelles Zertifizierungsverfahren.

Die Unterscheidung ist für Unternehmen zentral. Ein Agent kann im Verzeichnis auffindbar sein, ohne im eigenen Unternehmen freigeschaltet zu werden. Ebenso können registrierte und korrekt adressierte Endpunkte zu einer älteren, widerrufenen oder mittlerweile anders konfigurierten Version gehören. Registry-Nachweise und Laufzeitsignale müssen deshalb gemeinsam betrachtet werden.

Praxischeck: fünf Prüfschritte vor der ersten Agentenverbindung

Für einen Pilot empfiehlt AgentenCode einen bewusst engen Ablauf. Erstens: den Domaininhaber und die zuständige Organisation unabhängig bestimmen. Zweitens: DNS- und Zertifikatsinformationen in einer dokumentierten Prüfstrecke auslesen. Drittens: Version, Änderungen und gegebenenfalls Widerruf berücksichtigen. Viertens: den Agenten nur mit ausdrücklich freigegebenen Tools und Datenquellen verbinden. Fünftens: alle relevanten Aktionen und Nachweise protokollieren.

Beginnen sollte ein Pilot mit einer ungefährlichen Leseoperation. Eine erfolgreiche Identitätsprüfung darf nicht sofort Schreibrechte, Zahlungsauslösungen oder Zugang zu Kundendaten eröffnen. Erst wenn die Fehlerfälle getestet sind – falsche Domain, abgelaufene Identität, manipulierte Registry-Angaben und unterbrochene DNS-Auflösung –, kommt eine schrittweise Freigabe weiterer Fähigkeiten in Betracht.

Die offenen Angriffsflächen bleiben erheblich

DNS- oder Domainkompromittierungen können Identitätssignale beeinflussen. Zertifikate können ablaufen, Schlüssel entwendet werden und Name-to-Endpunkt-Zuordnungen in Caches veralten. Hinzu kommen Risiken durch Abhängigkeiten von Discovery-Diensten und die Frage, wie Identitätswechsel und Unteragenten nachvollziehbar bleiben. Die ANS-Spezifikation beschreibt dafür Bausteine, aber das konkrete Risikoniveau hängt von Implementierung, Aktualisierungsprozess und Durchsetzung ab.

Noch wichtiger: Ein Angreifer kann auch einen wirklich registrierten Agenten durch Prompt-Injection zu schädlichen Aktionen verleiten. Deshalb dürfen Betreiber eine erfolgreiche Namensprüfung niemals als Ersatz für Laufzeitsandbox, Richtlinienkontrolle, Tool-Berechtigungen und Audit-Logs behandeln.

Wie reif ist der Standard – und was ist noch nicht belegt?

Die Aufnahme unter die Linux Foundation und die genannten elf Unterstützer stärken die institutionelle Grundlage. Offene Gremien und öffentliche Spezifikationen machen eine interoperable Umsetzung wahrscheinlicher. Ob daraus ein breit genutzter Internetstandard wird, ist jedoch offen. Die Ankündigung liefert weder flächendeckende Implementierungszahlen noch unabhängige Sicherheitsmessungen für alle unterstützten Produkte.

Für Ausschreibungen sollte ANS deshalb zunächst als mögliche Identitätsinfrastruktur und nicht als verpflichtendes Compliance-Zertifikat behandelt werden. Relevante Fragen sind Versionsreife, Wartungsverantwortung, Nachweisformate, Widerrufsprozess und tatsächliche Kompatibilität mit vorhandenen Agentengateways.

AgentenCode-Entscheidung: Wo ANS heute Mehrwert stiften kann

Der unmittelbarste Nutzen entsteht bei Agenten, die nicht ausschließlich innerhalb eines einzigen geschlossenen Unternehmenssystems arbeiten: Lieferantenagenten, fremde MCP-Endpunkte, A2A-Integrationen oder Marktplätze. Für rein interne Dienste kann eine bereits vorhandene PKI oder Workload-Identity zunächst genügen. ANS ist kein pauschaler Grund, bestehende Identitätsinfrastruktur zu ersetzen.

Unsere Empfehlung: ANS in einem kontrollierten Discovery-Pilot mit einer festen Zahl externer Agenten vergleichen. Messen sollten Teams die Erfolgsquote valider und absichtlich ungültiger Identitätsnachweise, die Zeit bis zur Erkennung eines Widerrufs und die Zahl unberechtigter Tool-Zugriffe. Erst eine solche Überprüfung zeigt, ob der Standard in der konkreten Architektur einen zusätzlichen Sicherheits- und Integrationsnutzen bringt.

Dass Cloudflare, Cisco, GoDaddy, DigiCert und weitere Firmen zu den elf Unterstützern gehören, zeigt Interesse auf mehreren Ebenen des Agenten-Ökosystems: DNS, Zertifikatsausstellung, Sicherheit und Verzeichnisdienste. Es sagt aber noch nichts darüber aus, wie viele fremde Systeme eine ANS-Identität heute tatsächlich automatisch prüfen. Ein neutrales Gremium und die konkrete Integration in AGNTCY sind überprüfbare Zwischenschritte; weltweite Interoperabilität bleibt eine Aufgabe für offene Tests.