KI-Agenten brauchen mehr als ein Login

Ein autonomer KI-Agent ist nicht einfach „ein Bot mit einem Passwort“. Sobald er Dienste nutzt, Verträge ausführt, Dateien liest, Zahlungen auslöst oder mit anderen Agenten verhandelt, braucht er mehrere Identitäten gleichzeitig. DID, OpenID Connect, TLS-Zertifikat, Wallet-Adresse, Service Account, Verifiable Credential und Reputation sind keine Synonyme. Sie sind unterschiedliche Ausweise derselben Entität.

Der Denkfehler: „Identität“ klingt nach einem Ding

Bei Menschen ist uns längst klar, dass Identität kontextabhängig ist. Dieselbe Person kann einen Reisepass, einen Personalausweis, einen Führerschein, eine Bankkarte, eine Krankenkassenkarte und einen Mitarbeiterausweis besitzen. Niemand würde sagen: „Welche davon ist die echte Identität?“ Die Person ist dieselbe. Die Nachweise erfüllen unterschiedliche Zwecke.

Bei Bots und KI-Agenten wirkt das zunächst ungewohnt, weil Software früher oft nur einen API-Key hatte. Ein kleines Skript ruft eine Schnittstelle auf, fertig. Autonome Agenten sind eine andere Kategorie: Sie handeln über Systemgrenzen hinweg. Sie müssen nicht nur „reinkommen“, sondern beweisen, wer sie sind, wofür sie berechtigt sind, welches Budget sie haben, zu welcher Organisation sie gehören und welche Handlungen ihnen zugerechnet werden.

Robert als Beispiel: derselbe Bot, mehrere Ausweise

Nehmen wir einen Agenten namens Robert. Robert ist kein Mensch, sondern ein autonomer Software-Agent. Er verarbeitet Rechnungen, fragt Cloud-Dateien ab, spricht mit anderen Agenten und darf kleine Zahlungen auslösen. Je nach Kontext zeigt Robert einen anderen Nachweis.

Das ist nicht doppelt gemoppelt. Es ist sauber getrennt. Ein TLS-Zertifikat beweist nicht automatisch, dass Robert Zahlungen auslösen darf. Eine Wallet-Adresse beweist nicht, dass Robert Mitarbeiter einer Firma ist. Ein OpenID-Login beweist nicht, dass die dazugehörige Bitcoin-Adresse wirklich Robert gehört. Genau diese Lücken werden in Agenten-Systemen gefährlich.

Warum ein einzelner Login für Agenten nicht reicht

Ein Login beantwortet meistens nur diese Frage: Hat eine Entität gerade Zugriff auf ein Konto bei diesem Dienst? Für klassische Webanwendungen ist das ausreichend. Für autonome Agenten ist es zu dünn.

Agenten handeln häufiger asynchron. Sie werden gestartet, pausiert, kopiert, migriert, neu deployed, in Queues geschoben oder von anderen Agenten beauftragt. Sie können im Namen eines Menschen, eines Teams, einer Firma oder eines anderen Agenten handeln. Dazu kommt: Viele relevante Aktionen passieren nicht in einem einzigen Identitätssystem. Ein Agent kann sich per OpenID bei einer Cloud anmelden, per mTLS mit einer internen API sprechen und per Wallet eine Zahlung signieren. Diese Schichten müssen zusammenpassen.

DID: der Anker, nicht der komplette Ausweis

Decentralized Identifiers, kurz DIDs, sind laut W3C eine Form verifizierbarer, dezentraler digitaler Identität. Eine DID kann sich auf Menschen, Organisationen, Dinge, Datenmodelle oder abstrakte Entitäten beziehen. Der wichtige Punkt: Die Kontrolle über die DID kann kryptografisch nachgewiesen werden, ohne dass jede Prüfung zwingend über einen zentralen Login-Anbieter laufen muss.

Für Agenten ist das stark, weil eine DID als Anker dienen kann. In einem DID Document stehen typischerweise öffentliche Schlüssel, Verification Methods und gegebenenfalls Service-Endpunkte. Der Agent oder sein Betreiber kann damit beweisen: „Ich kontrolliere den privaten Schlüssel zu dieser DID.“ Das ist aber noch nicht dieselbe Aussage wie: „Ich bin Mitarbeiter von Firma XYZ“ oder „Ich darf Rechnungen freigeben“. Dafür braucht es weitere Nachweise.

OpenID Connect: der Brückenschlag in bestehende Login-Welten

OpenID Connect ist kein Ersatz für DIDs. Es ist die pragmatische Login-Schicht für bestehende Systeme. Die OpenID-Spezifikation beschreibt OpenID Connect als Identitätsschicht auf OAuth 2.0. Ein Dienst kann damit prüfen, ob ein Endnutzer durch einen Authorization Server authentifiziert wurde, und erhält ein ID Token mit Claims.

Für Agenten heißt das: Wenn Robert in einem bestehenden SaaS-System arbeiten soll, ist OpenID Connect oft der einfachste Weg. Der Dienst versteht es bereits. Rollen, Gruppen, Tenant-Zuordnung und Single Sign-on sind vorhanden. Aber OpenID Connect sagt zunächst nur etwas in der Welt des jeweiligen Identity Providers. Die Verknüpfung zur DID, zur Wallet oder zu einem separaten TLS-Zertifikat muss zusätzlich bewiesen werden.

X.509 und mTLS: Maschinen müssen sich auch auf Leitungsebene ausweisen

Bei Bot-zu-Bot-Kommunikation reicht ein Web-Login nicht immer. Zwei Dienste können sich über TLS verschlüsselt verbinden. Mit mTLS weisen sich beide Seiten zusätzlich per Zertifikat aus. X.509-Zertifikate sind hier die etablierte Sprache der Internet-PKI; RFC 5280 beschreibt Format, Semantik und Zertifikatsketten für diese Welt.

Für Agenten ist das nützlich, wenn eine API nur mit bekannten Maschinen sprechen soll. Das Zertifikat sagt: Diese Verbindung kommt von einem bestimmten technischen Subjekt. Es sagt aber nicht automatisch: Dieses Subjekt darf Budget freigeben oder Zahlungen senden. Dafür braucht es wieder Rollen, Policies und Credentials.

Wallets: Identität wird handlungsfähig

Wallet-Adressen sind keine Personalausweise. Sie sind zunächst Adressen zu Schlüsselpaaren. Wer den privaten Schlüssel kontrolliert, kann signieren oder Transaktionen auslösen. Bei Agenten wird das spannend, weil eine Wallet den Agenten handlungsfähig macht: Er kann Kautionen hinterlegen, kleine Zahlungen leisten, Onchain-Verträge bedienen oder kryptografisch beweisen, dass er eine bestimmte Aktion autorisiert hat.

Das Risiko liegt auf der Hand: Eine Wallet-Adresse allein sagt nichts darüber, wer dahintersteht. Jeder kann behaupten: „Diese Adresse gehört Robert.“ Vertrauenswürdig wird es erst, wenn Robert oder Roberts Betreiber die Wallet-Adresse mit dem DID-Anker verknüpft und diese Verknüpfung signiert.

Verifiable Credentials: die eigentlichen Aussagen

Verifiable Credentials sind digitale Nachweise, die wie physische Ausweise Informationen transportieren können, aber kryptografisch prüfbar sind. Die W3C VC Data Model 2.0 beschreibt genau dieses Muster: Ein Aussteller macht Aussagen über ein Subjekt, der Halter präsentiert sie, ein Prüfer verifiziert sie.

Für Agenten ist das der entscheidende Teil. Die DID ist der Anker. Das Credential ist die Aussage. Nicht „Robert existiert“, sondern: Robert gehört zu Firma XYZ. Robert wurde von Daniel erstellt. Robert darf Rechnungen bis 500 € freigeben. Robert darf nur Lieferanten aus einer erlaubten Liste bezahlen. Robert darf keine neuen API-Schlüssel erzeugen. Robert darf im Namen von Team Buchhaltung handeln, aber nicht im Namen der Geschäftsführung.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "type": ["VerifiableCredential", "AgentAuthorityCredential"],
  "issuer": "did:web:firma.example",
  "validFrom": "2026-06-02T08:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6Mkg...",
    "agentName": "Robert",
    "organization": "Firma XYZ",
    "permissions": [
      "invoice.read",
      "invoice.approve.max_500_eur"
    ],
    "wallets": [
      "8xYw...",
      "bc1q..."
    ],
    "openid": "[email protected]",
    "certificateSubject": "CN=robert-agent.firma.example"
  }
}

Dieses Dokument ist bewusst als vereinfachtes Beispiel formuliert. In einem echten System kommen Signaturformat, Status-/Revocation-Mechanismus, Schema, Aussteller-Vertrauen, Ablaufzeit, Schlüsselrotation und Datenschutzfragen dazu. Aber das Prinzip ist genau das: Eine prüfbare Aussage bindet mehrere technische Identitäten an denselben Agenten.

Das eigentliche Problem: Korrelation ohne Überwachung

Die Verknüpfung mehrerer Identitäten ist mächtig, aber gefährlich. Wenn alle Identitäten immer öffentlich und dauerhaft miteinander verbunden sind, entsteht ein perfektes Tracking-Profil. Jeder könnte Roberts Login, Wallets, Zertifikate, Zahlungen, API-Zugriffe und Reputation über Systeme hinweg zusammenführen.

Darum ist die Architektur nicht einfach: „Alles in ein DID Document schreiben und fertig.“ Gute Agenten-Identität muss selektiv offenlegen. Ein anderer Agent soll prüfen können, dass Robert eine Zahlung auslösen darf, ohne automatisch jede andere Wallet, jedes Cloud-Konto und jede frühere Interaktion zu sehen. Das ist der gleiche Grund, warum ein Mensch nicht beim Paketdienst seinen Reisepass, Führerschein, Arbeitsvertrag, Bankkarte und komplette Bonitätshistorie auf den Tisch legt.

Reputation: die Identität bekommt Geschichte

Bei Agenten reicht eine einmalige Prüfung nicht. Wenn Robert heute korrekt handelt, morgen aber Unsinn macht, muss das System reagieren. Reputation ist deshalb eine eigene Schicht. Sie beantwortet andere Fragen als Login oder Credential: Hat dieser Agent schon erfolgreich Aufgaben abgeschlossen? Gab es Policy-Verstöße? Wurde ein Schlüssel kompromittiert? Hat der Betreiber die Verantwortung übernommen? Wurde eine Berechtigung widerrufen?

Reputation sollte nicht nur ein öffentlicher Score sein. Ein einzelner Zahlenwert lädt zu Manipulation ein und kann falsche Sicherheit erzeugen. Besser sind nachvollziehbare Ereignisse: signierte Interaktionsbelege, Audit-Logs, begrenzte Zeitfenster, Widerrufslisten, Aussteller-Vertrauen und interne Risikoentscheidungen.

Wie zwei Bots einander prüfen könnten

Stellen wir uns vor, Robert möchte mit einem anderen Agenten namens Paula sprechen. Paula soll eine Rechnung prüfen, Robert soll sie freigeben und eine kleine Zahlung auslösen. Paula muss jetzt nicht „Robert mögen“. Paula muss prüfen.

1. Paula erhält Roberts DID oder einen signierten Präsentationsnachweis.
2. Paula löst die DID auf und findet gültige Verification Methods.
3. Robert beweist Kontrolle über den privaten Schlüssel.
4. Paula prüft Roberts Credentials: Aussteller, Signatur, Ablauf, Widerruf.
5. Paula prüft die Bindungen: Wallet, OpenID-Konto, Zertifikat, Service Account.
6. Paula erlaubt nur die konkrete Aktion, die durch Policy und Credential gedeckt ist.

Warum das für automatisierte Zahlungen so wichtig wird

Autonome Zahlungen sind der Moment, in dem Identität praktisch wird. Ein Agent, der nur Texte schreibt, kann Fehler machen. Ein Agent, der Geld bewegt, kann Schaden auslösen. Deshalb reicht es nicht, dass eine Wallet signiert. Entscheidend ist: Darf diese Wallet in diesem Kontext genau diese Zahlung auslösen?

Ein gutes System trennt deshalb mindestens vier Ebenen: Besitz der Wallet, Zugehörigkeit der Wallet zum Agenten, Befugnis des Agenten, konkrete Policy der Zahlung. Beispiel: Robert besitzt die Solana-Wallet. Die Wallet ist in Roberts DID-Bindung enthalten. Firma XYZ hat Robert ein Credential ausgestellt. Dieses Credential erlaubt Zahlungen bis 500 €. Die konkrete Rechnung liegt bei 312 €. Erst dann wird gezahlt.

Was in die DID gehört und was nicht

Ein häufiger Architekturfehler ist, zu viele Daten direkt in den DID-Anker zu packen. Eine DID sollte stabil genug sein, um als Anker zu dienen, aber nicht zum öffentlichen Lebenslauf des Agenten werden. In vielen Fällen gehören nur technische Verifikationsmethoden und Service-Endpunkte hinein. Rollen, Budgets, Wallet-Bindungen, Zertifikatszuordnungen und Unternehmenszugehörigkeit können besser als Credentials modelliert werden.

Warum? Weil Credentials ausgestellt, aktualisiert, abgelaufen und widerrufen werden können. Wenn Robert die Firma verlässt, muss nicht die ganze DID verschwinden. Wenn nur die Bitcoin-Wallet rotiert, muss nicht das OpenID-Konto neu entstehen. Wenn die Freigabegrenze von 500 € auf 100 € sinkt, wird ein Credential ersetzt oder widerrufen. Das System bleibt beweglich.

Schlüsselrotation ist kein Detail, sondern Überleben

Agenten werden kompromittiert. Private Keys können falsch gespeichert werden. Deployment-Pipelines können Logs schreiben, die nie hätten geschrieben werden dürfen. Ein alter Container kann noch laufen. Ein Mitarbeiter kann einen geheimen Schlüssel kopiert haben. Wer Agenten-Identität baut, muss Schlüsselrotation von Anfang an einplanen.

Das bedeutet: kurze Gültigkeiten, klare Revocation-Mechanismen, getrennte Schlüssel für Authentifizierung, Signatur und Zahlung, keine dauerhaften Allmacht-Tokens, Hardware- oder KMS-gestützte Schlüssel, wo es sinnvoll ist, und Audit-Logs, die nicht vom Agenten selbst überschrieben werden können.

Der menschliche Vergleich bleibt die beste Erklärung

Wenn Sie das Modell jemandem erklären müssen, nehmen Sie nicht zuerst Blockchain, JSON-LD oder OAuth. Nehmen Sie einen Menschen am Empfang eines Unternehmens.

Der Reisepass beweist die Person. Der Mitarbeiterausweis beweist die Zugehörigkeit. Die Bankkarte erlaubt Zahlungen, aber nur mit Limit und Konto. Der Führerschein erlaubt Autofahren, aber nicht Vertragsabschluss. Eine Vollmacht erlaubt eine konkrete Handlung. Eine Zutrittskarte öffnet Türen, aber nicht das Konto. Alles gehört zur gleichen Person, aber kein einzelner Ausweis ersetzt alle anderen.

Was Unternehmen praktisch daraus lernen sollten

Viele Unternehmen werden nicht morgen ein vollständiges DID-/VC-System für Agenten betreiben. Das muss auch nicht der erste Schritt sein. Der erste Schritt ist eine saubere Trennung: Agenten sind eigene technische Identitäten, keine geteilten Mitarbeiterkonten. Jeder Agent bekommt einen klaren Zweck, begrenzte Rechte, getrennte Schlüssel, eigene Logs und einen Verantwortlichen.

Dann kommt die Bindung: Welche Cloud-Rolle gehört zu welchem Agenten? Welche Wallet gehört zu welchem Agenten? Welche Aktionen darf der Agent ausführen? Wer hat diese Befugnis ausgestellt? Wie wird sie widerrufen? Wo steht das Budget? Wer sieht den Audit-Trail?

Die Architektur, die sich abzeichnet

Für autonome KI-Agenten entwickelt sich die Identitätsarchitektur in Richtung eines mehrschichtigen Modells. Nicht eine Identität ersetzt alle anderen. Stattdessen gibt es einen kryptografischen Anker, mehrere kontextspezifische Nachweise und eine Policy-Schicht, die konkrete Handlungen erlaubt oder blockiert.

Agent
 ├─ DID als globaler Identitätsanker
 ├─ Wallets für Zahlung und Signatur
 ├─ Zertifikate für TLS und mTLS
 ├─ OpenID-Konten für bestehende Dienste
 ├─ Service Accounts für Cloud-Rollen
 ├─ Verifiable Credentials für Zugehörigkeit und Befugnisse
 └─ Reputation für Verlauf, Vertrauen und Sanktionen

Das ist technisch anspruchsvoller als „API-Key in die Umgebungsvariable legen“. Aber genau dort liegt die Zukunft, wenn Agenten nicht nur Texte erzeugen, sondern Dinge tun: einkaufen, buchen, freigeben, zahlen, verhandeln, deployen, melden, sperren und eskalieren.

Was noch offen ist

Die Standards sind da, aber die breite Praxis ist noch jung. DIDs sind W3C-Standard, Verifiable Credentials 2.0 ist spezifiziert, OpenID Connect ist etabliert, X.509 ist Internet-Basis. Gleichzeitig ist die Kombination für autonome Agenten noch kein fertiges Produkt von der Stange. Es fehlen einheitliche Trust Frameworks, einfache Revocation-UX, robuste Wallet-Policies, gute Agenten-Verzeichnisse, Sybil-Schutz, saubere Haftungsmodelle und verständliche Admin-Oberflächen.

Das macht das Thema so spannend: Es ist kein reines Zukunftsbild und kein fertiger Massenstandard. Es ist die Schicht, die gerade zwischen klassischem IAM, Kryptografie, Cloud-Sicherheit, Zahlungsinfrastruktur und KI-Agenten entsteht.

Offizielle Quellen

• W3C: Decentralized Identifiers (DIDs) v1.0
• W3C: Verifiable Credentials Data Model v2.0
• W3C: Verifiable Credential Data Integrity 1.0
• OpenID Foundation: OpenID Connect Core 1.0
• OpenID Foundation: OpenID for Verifiable Credential Issuance 1.0
• OpenID Foundation: OpenID for Verifiable Presentations 1.0
• IETF/RFC Editor: RFC 5280 X.509 Public Key Infrastructure