A2A-Sicherheitsmechanismen: Das Zutrittssystem für KI-Vertrauen

Wenn zwei KIs sich gegenseitig „anrufen“, was ist die größte Angst? Nicht, dass sie sich endlos unterhalten, sondern dass sich Fremde als Bekannte ausgeben und an der Tür klopfen.

Sicherheitsdesign-Prinzip: Erst abschließen, dann öffnen

Stell dir vor, du ziehst in eine neue Wohnung – das Erste, was du tust, ist nicht, Vorhänge aufzuhängen, sondern das Türschloss auszutauschen. Die Designer des A2A-Protokolls denken genauso – Standardmäßig sicher, jede Lockerung erfordert einen expliziten Schritt. Dieses System funktioniert wie eine komplette Zutrittskontrolle: Türschloss (Token), Zutrittskarte (Peer-Schlüssel), Türspion (Identitätsprüfung), Überwachungskamera (Audit-Log). In der Hermes-Nachrichtenplattform ist die A2A-Funktion als Plugin verfügbar, aber die Sicherheitsstandards machen keine Kompromisse: Ohne konfiguriertes Token wird nur auf 127.0.0.1 gelauscht – als wäre die Tür abgeschlossen und der Schlüssel nur in der eigenen Hand.

Die vier Verteidigungslinien im Detail

Erste Linie: Localhost-Bindung + Token (Türschloss)

Standardmäßig lauscht A2A nur auf dem lokalen Rechner – von außen ist die Tür gar nicht erst erreichbar. Um einen externen Dienst anzubieten, müssen zwei Bedingungen gleichzeitig erfüllt sein: A2A_HOST muss die Adresse freigeben und ein Bearer-Token muss konfiguriert sein. Das ist, als würdest du nicht nur das Fenster öffnen, sondern auch einen Kaktus mit Stacheln auf die Fensterbank stellen – beides ist unabdingbar.

Zweite Linie: Unabhängige Schlüssel pro Peer (Zutrittskarte)

Jeder Peer hat sein eigenes, exklusives Token, konfiguriert über A2A_PEER_TOKENS="alice:tok1,bob:tok2". Das ist kein Universalschlüssel für alle Türen, sondern jeder Besucher bekommt eine eigene Zutrittskarte. Die authentifizierte Identität steuert Rate-Limiting, Vertrauenslisten und Audit – wer welche Karte durchgezogen hat, wie oft und wann, alles wird protokolliert.

Dritte Linie: Injektionsfilter + Desensibilisierung (Sicherheitskontrolle)

Eingehender Text wird gefiltert und als „Eingabe von nicht vertrauenswürdigem Peer“ markiert; entfernte Peers können keine Operator-Slash-Befehle aufrufen. Das ist wie die Sicherheitskontrolle am Flughafen – Flüssigkeiten im Koffer werden separat geprüft. Bei ausgehenden Antworten werden Credential-artige Strings (API-Keys, JWTs, Tokens) automatisch entfernt – als würde man bei einem versendeten Brief die Personalausweisnummer des Empfängers automatisch schwärzen.

Vierte Linie: Audit-Log + Schleifenschutz (Überwachungskamera)

Jeder Austausch wird an ~/.hermes/a2a_audit.jsonl angehängt – als hätte man eine 24-Stunden-Überwachung vor der Tür. Die Rundenbegrenzung gegen Endlosschleifen funktioniert wie eine Gegensprechanlage beim Nachbarn – wenn zwei KIs sich endlos unterhalten, unterbricht das System automatisch.

Echte Angriffsgeschichten: 3 von der Community entdeckte und behobene Probleme

Geschichte 1: SSRF-Bypass (#78298) – Mit „digitalen Geheimcodes“ das Türschloss überlisten

Ein Angreifer fand heraus, dass die Sicherheitsprüfung der Callback-URL einen String-Präfix-Abgleich auf den Hostnamen macht, z. B. ob er mit 127. beginnt. Aber IP-Adressen haben eine „ganzzahlige Schreibweise“ – 2130706433 ist nur eine andere Schreibweise für 127.0.0.1. Das ist, als würde man die Hausnummer in Morsecode schreiben und der Pförtner lässt einen durch, weil er sie nicht erkennt. Die Lösung: Der Callback-Host wird zuerst in eine Standard-IP aufgelöst und dann geprüft – als würde der Pförtner jede Adressform erst in eine standardisierte Hausnummer übersetzen und dann vergleichen.

Geschichte 2: Identitätskollaps hinter Reverse-Proxy (#80534/#80779) – Alle werden zur selben Person

Bei Deployment hinter nginx oder K8s leitete das A2A-Plugin die Aufrufer-Identität aus der Socket-Adresse ab. Aber der Proxy steht dazwischen, also erscheinen alle Peers mit derselben IP – der des Proxys. Das ist wie beim Pförtnerhäuschen eines Apartmentkomplexes, wo alle Besucher als „vom Pförtner vertreten“ registriert werden. Rate-Limiting teilt sich einen einzigen Bucket (einer, der beschäftigt ist, bremst alle aus), die Vertrauensliste kann nur die Proxy-Adresse enthalten, und das Audit sieht den echten Aufrufer nicht. Die Lösung: Die echte Identität wird aus X-Forwarded-For abgeleitet, aber nur wenn sichergestellt ist, dass man „hinter einem vertrauenswürdigen Proxy“ ist.

Geschichte 3: Audit-Blindstelle (#81003/#81042) – Abgewiesenes Klopfen wird nicht protokolliert

Das Audit-Log erfasst nur akzeptierten Traffic. 401 (ungültiges Token) und 403 (nicht vertrauenswürdig) erzeugen keine Einträge. Das ist, als würde die Überwachungskamera nur Leute filmen, die problemlos eintreten, während der Einbrecher beim Schlossknacken nicht aufgenommen wird. Credential-Stuffing-Angriffe, Sondierung mit widerrufenen Tokens, laterale Bewegungsversuche – genau diese Angriffe braucht das Audit am dringendsten. Die Lösung: Auch alle abgelehnten Authentifizierungen werden an das Append-only-Audit-Log angehängt, mit decision-Feld + HTTP-Statuscode + Aufrufer-IP.

Was das für Nutzer bedeutet

Die Kernlogik dieses Systems ist: Sicherheit ist kein nachträglicher Fix, sondern der Standardzustand. Als Hermes-Nutzer musst du kein Sicherheitsexperte sein, um Basisschutz zu bekommen – die vier Verteidigungslinien greifen automatisch. Noch wichtiger: Die Community härtet das System durch echte Angriffe kontinuierlich ab – vom SSRF-Bypass über den Reverse-Proxy-Identitätskollaps bis zur Audit-Blindstelle, jedes Problem entspricht einem realen Szenario. Das A2A-Protokoll ist wie eine ständig verstärkte Burg, jeder Stein ist durch reale Einsätze erprobt. Wenn deine beiden Agenten sich das nächste Mal gegenseitig „anrufen“, gibt es zwischen ihnen nicht nur Türschloss, Zutrittskarte, Sicherheitskontrolle und Überwachungskamera, sondern auch eine Gruppe von Wachen, die auf die Logs starren.