Kryptografische Identität für KI-Agenten: Warum nicht-menschliche Akteure eine verifizierbare Identität brauchen – und wie Sie sie mit mTLS, JWT und SPIFFE/SPIRE ausstellen

Wenn ein KI-Agent autonom eine Datenbank abfragt, eine Zahlung auslöst oder einen zweiten Agenten beauftragt, stellt sich eine Frage, die jahrzehntelang nur für Menschen relevant war: Wer ist das eigentlich – und woher wissen wir, dass es wirklich dieser Akteur ist? Die unbequeme Antwort lautet in den meisten heutigen Systemen: Wir wissen es nicht. Wir vertrauen einem API-Schlüssel, der in einer Umgebungsvariablen liegt, kopiert, geloggt und weitergereicht werden kann. Für eine Belegschaft aus tausenden ephemeren, sich selbst startenden Software-Akteuren ist das kein tragfähiges Sicherheitsmodell mehr.

Dieser Pillar-Artikel erklärt, warum nicht-menschliche Akteure eine eigene, kryptografisch verifizierbare Identität benötigen, und zeigt konkret, wie Sie diese Identität ausstellen: mit gegenseitiger TLS-Authentifizierung (mTLS), mit signierten JSON Web Tokens (JWT) und – als operativ tragfähiges Gesamtsystem – mit dem offenen Standard SPIFFE und seiner Referenzimplementierung SPIRE.

Was bedeutet kryptografische Agenten-Identität – die kurze Antwort

Eine kryptografische Agenten-Identität ist ein eindeutiger, fälschungssicherer Identitätsnachweis für einen nicht-menschlichen Software-Akteur, der nicht auf einem geteilten Geheimnis beruht, sondern auf einem asymmetrischen Schlüsselpaar und einem signierten Dokument. Der Agent besitzt einen privaten Schlüssel, der seine Maschine nie verlässt; sein öffentlicher Schlüssel ist in einem von einer vertrauenswürdigen Instanz signierten Nachweis eingebettet. Jeder Empfänger kann diese Signatur prüfen, ohne den Aussteller online zu kontaktieren – und ohne dass jemals ein kopierbares Passwort über das Netz wandert.

Im Unterschied zu einem statischen API-Schlüssel beantwortet eine kryptografische Identität drei Fragen gleichzeitig: Wer ist der Akteur (ein eindeutiger Name), woher stammt diese Behauptung (eine prüfbare Signatur) und wie lange gilt sie (eine kurze, feste Lebensdauer). Genau diese drei Eigenschaften fehlen dem klassischen Bearer-Secret – und genau deshalb skaliert es für autonome Agenten nicht.

Praktisch umgesetzt wird das heute meist über drei aufeinander aufbauende Bausteine: mTLS sichert die Verbindung und beweist gegenseitig die Identität auf Transportebene; JWT trägt die Identität auf Anwendungsebene durch HTTP-Header und über mehrere Sprünge hinweg; SPIFFE/SPIRE stellt beide Nachweisformate automatisiert aus, rotiert sie und entzieht jeder Maschine die Last der Schlüsselverwaltung. Den Rest dieses Artikels widmen wir den Fragen, warum das nötig ist und wie es im Detail funktioniert.

Warum reichen API-Schlüssel und statische Geheimnisse für Agenten nicht mehr aus?

Statische Geheimnisse wurden für eine Welt entworfen, in der Software langlebig, überschaubar und von Menschen administriert war. KI-Agenten verletzen jede dieser Annahmen. Sie entstehen und vergehen im Minutentakt, sie rufen sich gegenseitig auf, und sie handeln ohne einen Menschen, der im Zweifel einen Knopf drückt. Ein Modell, das auf „ein langlebiges Passwort pro Dienst“ beruht, bricht unter diesen Bedingungen an mehreren Stellen.

Das geteilte Geheimnis ist das Problem, nicht die Lösung. Ein API-Schlüssel ist ein Bearer-Token: Wer ihn besitzt, ist er. Er liegt im Klartext in Konfigurationsdateien, in Umgebungsvariablen, in Log-Zeilen und – erfahrungsgemäß – früher oder später in einem öffentlichen Git-Repository. Es gibt keine kryptografische Bindung an die Maschine, die ihn rechtmäßig verwenden darf. Wird er kopiert, merkt das niemand, denn die Kopie ist vom Original nicht zu unterscheiden.

Langlebigkeit multipliziert das Risiko. Klassische Schlüssel werden ausgestellt und dann monate- oder jahrelang nicht angefasst. Das Zeitfenster, in dem ein abgegriffenes Geheimnis missbraucht werden kann, ist damit praktisch unbegrenzt. Bei einer Agenten-Belegschaft, in der einzelne Akteure Sekunden bis Minuten leben, ist ein über Monate gültiges Geheimnis grotesk überdimensioniert.

Die Verwaltung skaliert nicht. Bei einer Handvoll Diensten lässt sich Schlüsselrotation noch manuell organisieren. Bei tausenden ephemeren Agenten, die ständig neu entstehen, wird jede menschengebundene Rotation zum Engpass. Der Mensch wird zum Flaschenhals genau an der Stelle, an der das System eigentlich autonom sein soll.

Identität und Berechtigung verschmelzen unsauber. Ein API-Schlüssel sagt nichts darüber aus, wer der Akteur ist – er sagt nur, dass jemand das richtige Geheimnis kennt. Damit lässt sich keine saubere Autorisierung aufbauen, keine nachvollziehbare Protokollierung und keine differenzierte Vertrauensentscheidung treffen. Für regulierte Umgebungen in der DACH-Region, in denen Nachvollziehbarkeit und der Stand der Technik nach DSGVO erwartet werden, ist das ein ernstes Defizit.

Was unterscheidet eine nicht-menschliche Identität von einer menschlichen?

Der Begriff der nicht-menschlichen Identität (englisch oft non-human identity, NHI) fasst alle Akteure zusammen, die kein Mensch sind und dennoch auf Systeme zugreifen: Dienste, Workloads, Container, Funktionen – und neuerdings autonome KI-Agenten. Sie unterscheiden sich von menschlichen Identitäten in Dimensionen, die das Identitätsmanagement grundlegend verändern.

Menschen authentifizieren sich mit etwas, das sie wissen (Passwort), haben (Hardware-Token) oder sind (Biometrie). Sie tun das selten, bewusst und über eine interaktive Oberfläche. Ein Agent hingegen authentifiziert sich womöglich tausendmal pro Minute, vollautomatisch, ohne Bildschirm und ohne die Möglichkeit, einen zweiten Faktor in der Hand zu halten. Menschliche Mehrfaktor-Verfahren sind hier schlicht nicht anwendbar.

Die folgende Gegenüberstellung verdeutlicht, warum nicht-menschliche Akteure ein eigenes Identitätsmodell brauchen:

Dimension	Menschliche Identität	Nicht-menschliche Identität (Agent/Workload)
Lebensdauer	Jahre (Mitarbeiterverhältnis)	Sekunden bis Stunden (ephemer)
Authentifizierungsfaktor	Wissen/Besitz/Biometrie, MFA	Kryptografisches Schlüsselpaar, Attestierung
Häufigkeit	Selten, interaktiv	Sehr häufig, automatisiert
Anzahl pro Organisation	Hunderte bis Tausende	Zehntausende und mehr
Geheimnis-Rotation	Manuell, periodisch	Automatisiert, im Minutentakt
Nachweis der Herkunft	Onboarding durch HR	Plattform-Attestierung (Node/Workload)

Aus dieser Tabelle folgt die zentrale Designentscheidung: Eine nicht-menschliche Identität darf nicht auf einem Geheimnis beruhen, das ein Mensch ausstellt und verwaltet, sondern auf einem Schlüsselpaar plus Attestierung – einem maschinell prüfbaren Nachweis, dass dieser Akteur tatsächlich auf einer legitimen, erwarteten Plattform läuft. Genau hier setzen die folgenden Verfahren an.

Wie beweist mTLS die Identität eines Agenten auf der Transportebene?

Normales TLS – das Schloss im Browser – authentifiziert nur eine Seite: Der Server weist sich mit einem Zertifikat aus, der Client bleibt anonym. Gegenseitiges TLS (mTLS) dreht das um: Beide Seiten legen ein Zertifikat vor und beide prüfen das Gegenüber. Für die Kommunikation zwischen zwei Agenten ist das die natürliche Antwort, denn hier gibt es keinen „Browser-Nutzer“ und keinen „anonymen Client“ – beide Seiten sind benannte, gleichberechtigte Akteure, die sich gegenseitig vergewissern müssen.

Der Mechanismus beruht auf asymmetrischer Kryptografie. Jeder Agent besitzt ein Schlüsselpaar: einen privaten Schlüssel, der die Maschine niemals verlässt, und ein Zertifikat, das den zugehörigen öffentlichen Schlüssel und den Namen des Agenten enthält und von einer Zertifizierungsstelle (CA) signiert ist. Beim Verbindungsaufbau beweist jede Seite durch eine kryptografische Operation, dass sie den privaten Schlüssel zu ihrem Zertifikat besitzt – ohne ihn jemals zu übertragen. Anschließend prüft jede Seite, ob das Zertifikat der Gegenseite von einer vertrauenswürdigen CA signiert wurde.

Der entscheidende Vorteil gegenüber einem API-Schlüssel ist die Bindung an Besitz statt an Wissen. Ein Angreifer, der den Datenverkehr mitschneidet, erbeutet kein wiederverwendbares Geheimnis – der private Schlüssel taucht im Netz nie auf. Die Identität ist an die Maschine gebunden, die den privaten Schlüssel hält, nicht an eine Zeichenkette, die beliebig kopierbar ist.

mTLS löst jedoch nicht alles allein. Es sichert die Verbindung zwischen zwei Punkten, endet aber an jedem TLS-Endpunkt. Sobald ein Aufruf über mehrere Sprünge läuft – Agent A ruft Dienst B, der im Namen von A weiter Dienst C anspricht – trägt mTLS die ursprüngliche Identität nicht von selbst weiter. Außerdem ist die Verwaltung der Zertifikate und ihrer kurzen Lebensdauer der eigentliche operative Aufwand. Beide Lücken adressieren JWT und SPIFFE/SPIRE.

Wie transportiert ein JWT die Identität auf der Anwendungsebene?

Ein JSON Web Token (JWT) ist ein kompaktes, signiertes Dokument, das Aussagen über einen Akteur transportiert. Es besteht aus drei Teilen: einem Kopf (welcher Algorithmus, welcher Schlüssel), einer Nutzlast mit den Claims (wer, ausgestellt von wem, gültig bis wann) und einer Signatur. Weil die Signatur die ersten beiden Teile kryptografisch absichert, kann jeder Empfänger mit dem öffentlichen Schlüssel des Ausstellers prüfen, ob der Token echt und unverändert ist – ganz ohne Rückfrage beim Aussteller.

Während mTLS auf der Transportebene wirkt, lebt das JWT auf der Anwendungsebene: Es reist in einem HTTP-Authorization-Header durch REST- und gRPC-Aufrufe. Das macht es zur passenden Wahl überall dort, wo zertifikatsbasiertes mTLS unpraktisch ist – etwa hinter einem Load Balancer, der TLS terminiert, oder bei einer API, die ohnehin Bearer-Token erwartet.

Der eigentliche Mehrwert für Agenten-Ketten ist die Weitergabe über mehrere Sprünge. Ruft Agent A den Dienst B, kann B das empfangene JWT bei der weiteren Kommunikation mit Dienst C mitführen oder gegen ein abgeleitetes Token mit eingeschränkten Rechten eintauschen. So bleibt nachvollziehbar, in wessen Namen eine Aktion am Ende der Kette ausgeführt wird – eine Eigenschaft, die für die Protokollierung und Autorisierung autonomer Agenten zentral ist.

Allerdings ist ein JWT ein Bearer-Token: Wer es besitzt, kann es bis zum Ablauf verwenden. Daraus folgen zwei eiserne Regeln. Erstens muss die Gültigkeitsdauer kurz sein – Minuten, nicht Tage –, damit ein abgegriffenes Token schnell wertlos wird. Zweitens sollte das Token an einen Empfänger gebunden werden (über den aud-Claim, das Publikum), damit es nicht an einer anderen Stelle wiederverwendet werden kann. Wer JWTs mit langer Lebensdauer ausstellt, hat im Grunde nur den API-Schlüssel in neuer Verpackung wiederholt.

Was ist SPIFFE und welches Problem löst der Standard?

SPIFFE steht für Secure Production Identity Framework for Everyone – ein offener, herstellerneutraler Standardsatz unter dem Dach der Cloud Native Computing Foundation (CNCF), der definiert, wie Software-Akteure in dynamischen Umgebungen eine einheitliche, kryptografisch verifizierbare Identität erhalten. SPIFFE legt nicht ein neues kryptografisches Verfahren fest, sondern eine gemeinsame Sprache für Identität, die mTLS und JWT zusammenführt und plattformübergreifend nutzbar macht.

Der Kern ist die SPIFFE-ID – ein eindeutiger Name in URI-Form, etwa spiffe://example.org/zahlungs-agent. Der erste Teil, die Trust Domain, benennt die Vertrauensgrenze (eine Organisation, eine Umgebung); der Pfad benennt den konkreten Workload. Diese ID ist der stabile Anker, auf den sich Berechtigungen, Protokolle und Vertrauensentscheidungen beziehen.

Getragen wird die SPIFFE-ID vom SVID (SPIFFE Verifiable Identity Document) – dem Dokument, mit dem ein Workload seine Identität beweist. Hier schließt sich der Kreis zu den beiden vorherigen Abschnitten, denn ein SVID existiert in genau zwei Formaten:

• X.509-SVID: ein X.509-Zertifikat, in dem die SPIFFE-ID im Feld Subject Alternative Name (SAN) als URI eingebettet ist. Dieses Format greift direkt in mTLS – es ist das Zertifikat, das beide Seiten beim Handshake vorlegen.
• JWT-SVID: ein signiertes JSON Web Token, das die SPIFFE-ID trägt und sich für HTTP-/REST-Kontexte sowie für die Weitergabe über mehrere Sprünge eignet.

Damit beantwortet SPIFFE die Frage, was eine Identität ist und wie sie aussieht. Offen bleibt die schwierigere Frage: Wie kommt ein frisch gestarteter Agent, der noch nichts besitzt, überhaupt an sein erstes SVID, ohne dass ein Mensch ihm ein Geheimnis übergibt? Diese Frage beantwortet die Laufzeitumgebung SPIRE.

Wie stellt SPIRE Identitäten ohne ein erstes Geheimnis aus?

SPIRE (SPIFFE Runtime Environment) ist die Referenzimplementierung von SPIFFE: das laufende System, das SVIDs ausstellt, verteilt, rotiert und prüft. Es löst das sogenannte Bootstrapping-Problem – das Henne-Ei-Problem, wie ein Akteur seine erste Identität erhält, ohne bereits eine zu besitzen. Die Antwort heißt Attestierung: Statt einem Agenten ein Geheimnis mitzugeben, beweist SPIRE seine Identität anhand prüfbarer Eigenschaften seiner Umgebung.

SPIRE besteht aus zwei Komponenten. Der SPIRE Server ist der Vertrauensanker einer Trust Domain. Er führt die Registrierungseinträge – die Regeln, die bestimmte Plattform-Eigenschaften (sogenannte Selektoren) auf SPIFFE-IDs abbilden – und betreibt die Zertifizierungsstelle, die SVIDs signiert. Der SPIRE Agent läuft auf jedem Knoten, auf dem identifizierte Workloads laufen, holt SVIDs vom Server und stellt sie den Workloads über eine lokale Schnittstelle bereit.

Die Identitätsausstellung verläuft in zwei Stufen:

1. Node-Attestierung: Beim Start beweist der SPIRE Agent dem Server, dass er auf einem legitimen Knoten läuft – etwa indem er in Kubernetes ein Service-Account-Token vorlegt oder eine signierte Instanz-Identität des Cloud-Anbieters nutzt. Der Server vertraut also nicht einem mitgegebenen Passwort, sondern einer von der Plattform selbst ausgestellten, prüfbaren Aussage.
2. Workload-Attestierung: Fragt ein Agent über die Workload API sein SVID an, prüft der lokale SPIRE Agent, welcher Prozess da ruft. Er inspiziert dazu Kernel-Metadaten des Betriebssystems – etwa die Prozess-ID, die zugehörige Kubernetes-Pod-Information – und gleicht sie gegen die registrierten Selektoren ab. Erst wenn die Eigenschaften passen, erhält der Workload sein SVID.

Bemerkenswert ist, dass die Workload API ohne ein eigenes Geheimnis auskommt: Sie wird typischerweise über einen lokalen Unix-Domain-Socket bereitgestellt, und der Agent identifiziert den aufrufenden Prozess allein anhand der vom Kernel gelieferten Metadaten. Der Agent muss also kein Passwort kennen, um sein erstes Zertifikat zu bekommen – er muss nur der sein, der er vorgibt zu sein, und das wird an der Umgebung verifiziert. Damit ist das geteilte Geheimnis aus der Gleichung verschwunden.

Wie funktioniert die automatische Rotation kurzlebiger Identitäten?

Der vielleicht größte operative Gewinn von SPIFFE/SPIRE ist, dass kurze Lebensdauer kein Aufwand mehr ist, sondern der Normalzustand. SVIDs – sowohl X.509 als auch JWT – sind kurzlebig (in der Praxis oft im Bereich einer Stunde, konfigurierbar bis auf Minuten) und werden vom SPIRE Agent automatisch erneuert, bevor sie ablaufen. Kein Mensch rotiert hier Schlüssel; das System tut es kontinuierlich von selbst.

Daraus folgt eine drastische Verkleinerung des Schadensfensters. Wird ein X.509-SVID kompromittiert, ist es nach Minuten ohnehin abgelaufen und durch ein neues ersetzt. Ein dauerhaft missbrauchbares Geheimnis, wie es der klassische API-Schlüssel darstellt, existiert nicht mehr. Sicherheit entsteht hier nicht durch die Stärke eines einzelnen langlebigen Geheimnisses, sondern durch die Flüchtigkeit vieler kurzlebiger Nachweise.

Auf der Vertrauensseite arbeitet SPIRE mit Trust Bundles – Sammlungen der öffentlichen Schlüssel, mit denen sich SVIDs einer Trust Domain prüfen lassen. Auch diese Schlüssel werden regelmäßig rotiert: Beim geordneten Schlüsselwechsel veröffentlicht der Betreiber den neuen öffentlichen Schlüssel rechtzeitig im Voraus im Bundle, sodass Empfänger ihn bereits kennen, bevor das erste damit signierte SVID auftaucht. So entsteht ein bruchfreier Übergang ohne Ausfallfenster.

Für JWT-SVIDs folgt das Bundle dem etablierten Standard JWK (JSON Web Key, RFC 7517): Die öffentlichen Schlüssel werden als JWK-Einträge mit gesetztem Verwendungszweck und Schlüssel-ID veröffentlicht. Das bedeutet, dass jede Bibliothek, die bereits JWTs prüfen kann, auch JWT-SVIDs verifizieren kann – ein wichtiger Faktor für die Anschlussfähigkeit an bestehende Systeme.

Wie überbrücken Federation und OIDC die Grenzen zwischen Vertrauensdomänen?

Sobald Agenten über Organisations- oder Umgebungsgrenzen hinweg interagieren, reicht eine einzelne Trust Domain nicht mehr. Hier kommt die SPIFFE-Federation ins Spiel: Zwei Trust Domains tauschen ihre Trust Bundles über definierte Endpunkte aus und können dadurch die SVIDs der jeweils anderen Domain prüfen. Ein Agent in Domain A kann so einem Agenten in Domain B vertrauen, obwohl beide von unterschiedlichen SPIRE-Servern ausgestellt wurden – ohne ein geteiltes Geheimnis zwischen den Organisationen.

Strategisch noch wichtiger ist die OIDC-Federation. SPIRE kann einen OIDC-konformen Endpunkt bereitstellen und damit als Identitätsanbieter auftreten, dem große Cloud-Plattformen von Haus aus vertrauen. Ein Workload kann dann sein JWT-SVID gegen ein kurzlebiges Cloud-Token eintauschen – etwa um auf einen Speicherdienst zuzugreifen –, ohne dass irgendwo ein statisches Cloud-Zugangsgeheimnis hinterlegt sein muss. Genau die langlebigen Cloud-Schlüssel, die in der Praxis am häufigsten verloren gehen, verschwinden damit aus der Architektur.

Für die Praxis der DACH-Region ist das relevant, weil hybride und Multi-Cloud-Landschaften die Regel sind. Eine einheitliche, föderierbare Identitätsschicht über lokale Rechenzentren und mehrere Cloud-Anbieter hinweg vereinfacht nicht nur den Betrieb, sondern auch die Nachweisführung gegenüber Prüfern: Es gibt eine kohärente Antwort auf die Frage, wer im System mit wem reden darf und warum.

Wichtig ist die saubere Trennung der Begriffe: SPIFFE/SPIRE liefert Authentifizierung – den verlässlichen Beweis, wer ein Akteur ist. Was dieser Akteur darf, ist eine Frage der Autorisierung und gehört in eine separate Richtlinien-Schicht. Eine stabile, kryptografisch fundierte Identität ist die Voraussetzung jeder sinnvollen Autorisierung, ersetzt sie aber nicht.

mTLS, JWT oder SPIFFE/SPIRE – wann setzen Sie was ein?

Die drei Bausteine sind keine konkurrierenden Optionen, sondern Schichten, die zusammenspielen. Die folgende Übersicht ordnet sie nach ihrer Rolle:

Kriterium	mTLS (X.509)	JWT	SPIFFE/SPIRE
Ebene	Transport (Verbindung)	Anwendung (Header)	Ausstellung & Verwaltung beider
Beweistyp	Besitz des privaten Schlüssels	Signatur, Bearer-Token	Attestierung der Plattform
Mehrere Sprünge	Endet an jedem Endpunkt	Über die Kette weitergebbar	Liefert das passende Format je Fall
Rotation	Manuell aufwendig	Manuell aufwendig	Automatisch, kurzlebig
Bootstrapping	Erstausstellung ungelöst	Erstausstellung ungelöst	Über Attestierung gelöst
Eignung	Dienst-zu-Dienst-Verbindungen	API-Aufrufe, Delegation	Belegschaft aus vielen Agenten

Die pragmatische Empfehlung: Für die direkte Verbindung zweier Dienste innerhalb einer Vertrauensgrenze ist X.509-mTLS die natürliche Wahl. Für API-Aufrufe und delegierte Aktionen über mehrere Sprünge ist das JWT das richtige Werkzeug. Sobald Sie aber mehr als eine Handvoll Akteure betreiben – und eine Agenten-Belegschaft überschreitet diese Schwelle sofort –, lösen Sie das Ausstellungs-, Rotations- und Bootstrapping-Problem nicht von Hand, sondern mit SPIFFE/SPIRE, das Ihnen je nach Kontext das passende SVID-Format liefert.

Wie sieht eine schrittweise Einführung in der Praxis aus?

Ein tragfähiger Einstieg muss nicht mit einem Big-Bang beginnen. Bewährt hat sich ein schrittweises Vorgehen, das den Betrieb nicht überfordert und früh Sicherheitsgewinne liefert.

Schritt eins: Bestandsaufnahme der nicht-menschlichen Identitäten. Bevor Sie etwas ausstellen, müssen Sie wissen, welche Geheimnisse heute existieren. Erfassen Sie API-Schlüssel, Dienstkonten und statische Zugangsdaten und bewerten Sie deren Lebensdauer und Verbreitung. Diese Inventur ist oft der ernüchterndste und zugleich wertvollste Teil des Projekts.

Schritt zwei: Trust Domain und Namensschema festlegen. Definieren Sie die Vertrauensgrenze und ein konsistentes Schema für SPIFFE-IDs, das Umgebung, Team und Workload sinnvoll abbildet. Ein durchdachtes Namensschema zahlt sich später bei jeder Autorisierungsregel und jedem Protokolleintrag aus.

Schritt drei: SPIRE in einer abgegrenzten Umgebung erproben. Beginnen Sie mit einem nicht kritischen Cluster oder Dienst, richten Sie SPIRE Server und Agent ein und lassen Sie einen ersten Workload sein SVID über die Workload API beziehen. Hier lernen Sie die Attestierungs-Selektoren kennen, ohne Produktionsrisiko einzugehen.

Schritt vier: mTLS oder JWT je nach Kommunikationsmuster aktivieren. Stellen Sie bestehende Dienst-zu-Dienst-Verbindungen auf X.509-mTLS um und führen Sie für API-Aufrufe JWT-SVIDs ein. Wichtig ist, beides parallel zum Altbestand zu betreiben und schrittweise umzuschalten, statt hart zu migrieren.

Schritt fünf: statische Geheimnisse abschalten und Autorisierung aufsetzen. Erst wenn die kryptografische Identität trägt, entziehen Sie den alten Schlüsseln die Gültigkeit. Anschließend bauen Sie auf den nun verlässlichen SPIFFE-IDs eine saubere Autorisierungs-Schicht auf – etwa über enge OAuth-2.1-Scopes und eine kontinuierliche Zero-Trust-Prüfung pro Aktion. Die Reihenfolge ist entscheidend: erst die verifizierbare Identität, dann die darauf gestützte Berechtigung.

Welche Fehler sollten Sie bei der Agenten-Identität vermeiden?

Auch ein gutes Verfahren lässt sich falsch betreiben. Drei Muster begegnen einem in der Praxis immer wieder.

Das erste Anti-Muster ist das langlebige JWT. Wer JWT-SVIDs mit Tagen oder Wochen Gültigkeit ausstellt, hat das Bearer-Token-Risiko des API-Schlüssels nur umetikettiert. Kurze Lebensdauer und automatische Rotation sind kein Luxus, sondern der eigentliche Sinn der Übung. Ein JWT ohne enge aud-Bindung und ohne kurze Ablaufzeit ist ein Sicherheitsversprechen, das es nicht hält.

Das zweite Anti-Muster ist das Verwechseln von Authentifizierung und Autorisierung. Eine SPIFFE-ID sagt verlässlich, wer ruft – nicht, was der Aufrufer darf. Wer beide Schichten vermengt, baut sich entweder zu grobe oder zu starre Berechtigungen. Halten Sie die Identitäts-Schicht schlank und prüfbar und kapseln Sie die Berechtigungslogik separat.

Das dritte Anti-Muster ist der ungeschützte private Schlüssel. Die ganze Sicherheit von mTLS und SVIDs steht und fällt damit, dass der private Schlüssel die Maschine nicht verlässt. Wird er in ein Log geschrieben, in ein Image gebacken oder über das Netz verschickt, ist der kryptografische Vorteil dahin. Die Workload API von SPIRE ist genau deshalb so gestaltet, dass der Schlüssel lokal bleibt – diesen Vorteil sollte man nicht durch eigene Umwege zunichtemachen.

Fazit: Identität ist das Fundament autonomer Agenten

Je autonomer Software-Akteure werden, desto weniger trägt das alte Modell des geteilten Geheimnisses. Eine kryptografische, verifizierbare Identität verschiebt die Sicherheit weg vom kopierbaren Passwort hin zum nachweisbaren Besitz und zur prüfbaren Herkunft. mTLS sichert die Verbindung, JWT trägt die Identität durch die Aufrufkette, und SPIFFE/SPIRE macht aus beidem ein automatisiertes, kurzlebiges, attestiertes System, das ohne menschliches Schlüsselmanagement skaliert.

Wer heute eine Belegschaft aus KI-Agenten aufbaut, entscheidet damit zugleich über deren Sicherheitsfundament. Die verifizierbare Identität ist keine nachträgliche Härtung, sondern die Voraussetzung dafür, dass Autonomie überhaupt verantwortbar ist – und der Punkt, an dem ein durchdachtes Identitätsmodell den Unterschied zwischen kontrollierter Skalierung und unkontrolliertem Risiko ausmacht.

---

Quellen und weiterführende Spezifikationen: die offizielle SPIFFE-Dokumentation (spiffe.io), die SPIFFE/SPIRE-Projektseite der CNCF sowie die JWT-Spezifikation (RFC 7519) und JWK (RFC 7517). Dieser Beitrag beschreibt allgemeine Architekturprinzipien und nennt keine produktbezogenen Empfehlungen; er enthält keine bezahlte Platzierung.