PKIaaS für KI-Infrastruktur und KI-Agenten

KI-Agenten sind keine bloße Theorie mehr. Sie werden ab 2026 in Produktionsumgebungen eingesetzt, um Arbeitsabläufe zu automatisieren, API-Aufrufe auszuführen, Konfigurationen zu ändern, Transaktionen auszulösen und mit kritischen Systemen in Echtzeit und großem Umfang zu interagieren. Ein einzelner KI-Workflow kann fünf oder mehr Agenten umfassen, die Aufgaben untereinander austauschen, externe APIs aufrufen, Datenbanken lesen und Datensätze schreiben – alles ohne menschliches Eingreifen in den einzelnen Schritten.

Die Sicherheitsfrage, die die meisten Organisationen, die diese Systeme einsetzen, noch nicht vollständig beantwortet haben, lautet: Wie lässt sich feststellen, welcher Agent welche Aktion ausgeführt hat, und wie lässt sich dies beweisen? Die meisten KI-Agenten authentifizieren sich heute gegenüber APIs und Diensten mit statischen Anmeldeinformationen: API-Schlüsseln, Client-Geheimnissen und gemeinsamen Token. Diese Anmeldeinformationen vermitteln keine Identitätsaussage über ihren reinen Zeichenfolgenwert hinaus. Sie können kopiert werden, laufen nicht automatisch ab und bieten keinen Prüfpfad, der eine bestimmte Aktion einer bestimmten Agenteninstanz zuordnet. Laut dem IBM-Bericht „Cost of a Data Breach 2025“ fehlten 97 % der Organisationen, die von Sicherheitsvorfällen mit KI-Modellen betroffen waren, entsprechende Zugriffskontrollen.

Die Lösung für das Identitätsproblem von KI-Agenten ist dieselbe, die das Problem der Maschinenidentität für Server, Geräte und Workloads gelöst hat: kryptografische Identität, unterstützt durch eine kontrollierte Zertifizierungsstelle. PKI as a Service stellt die CA-Infrastruktur bereit, die KI-Agenten eindeutige, kurzlebige und verifizierbare Identitäten ausgibt. Dies ermöglicht mTLS für die Kommunikation zwischen Agent und Dienst, zertifikatbasiertes OAuth für Delegierungsketten und einen Audit-Trail, der jede Agentenaktion kryptografisch einer bestimmten Identität zuordnet.

Kurzantwort: Was leistet PKIaaS für die Identität von KI-Agenten?

PKIaaS stellt jedem KI-Agenten ein eindeutiges X.509-Zertifikat aus, das die Identität des Agenten (Name, Typ, Bereitstellungsumgebung, Berechtigungsbereich und ausstellende Organisation) kodiert. Das Zertifikat ist kurzlebig (Minuten bis Stunden für temporäre Agenten; 24 bis 48 Stunden für persistente Agenten), wird automatisch von der Identitätsinfrastruktur rotiert und von der PKIaaS-Zertifizierungsstelle signiert, deren Stammzertifizierungsstelle im Vertrauensbundle jedes vom Agenten aufgerufenen Dienstes enthalten ist. Bei einem API-Aufruf übermittelt der Agent das Zertifikat; der Dienst überprüft es anhand der PKIaaS-Stammzertifizierungsstelle; die Verbindung wird nur bei erfolgreicher Überprüfung hergestellt. Jede Zertifikatsausstellung wird im PKIaaS-Audit-Log protokolliert und liefert einen kryptografisch nachvollziehbaren Nachweis darüber, welcher Agent in welchem ​​Zeitraum aktiv war und welche Aktionen er ausführen durfte.

Wichtige Erkenntnisse

• Statische Anmeldeinformationen (API-Schlüssel, Clientgeheimnisse, gemeinsame Token) bieten keine Möglichkeit zur Nachvollziehbarkeit von KI-Agenten. Sie vermitteln keine Identitätsaussage über ihren Zeichenfolgenwert hinaus, können kopiert und zwischen Agenten geteilt werden, laufen nicht automatisch ab und erzeugen keinen Prüfpfad, der eine bestimmte Aktion einer bestimmten Agenteninstanz zuordnet. Zertifikatsbasierte Agentenidentität bietet all diese Eigenschaften strukturell und nicht über Richtlinien, die umgangen werden können.
• Auch kurzlebige KI-Agenten, die nur für eine einzige Aufgabe eingesetzt werden, benötigen eine eindeutige kryptografische Identität. Ein Zertifikat mit einer Gültigkeitsdauer von 30 Minuten, das einem kurzlebigen Agenten ausgestellt wird, ist nach dem Abfangen des Zertifikats innerhalb dieser 30 Minuten wertlos. Derselbe API-Schlüssel, der demselben kurzlebigen Agenten zugewiesen wird, ist so lange gültig, bis er manuell ausgetauscht wird – was möglicherweise nie geschieht.
• Das Problem der Delegationskette ist das schwierigste ungelöste Identitätsproblem in agentenbasierter KI. Wenn Agent A Agent B aufruft, der wiederum ein Tool aufruft, welches eine Transaktion auslöst, muss jeder Schritt in dieser Kette kryptografisch bis zu einer verantwortlichen Person oder einem Prinzipal zurückverfolgbar sein. Zertifikatsbasierte Identität in Kombination mit dem OAuth 2.0 Token Exchange (RFC 8693), der an diese Zertifikate gebunden ist, bietet den technischen Mechanismus für eine verifizierbare Delegationskette.
• mTLS für die Agent-zu-Dienst-Kommunikation ist das KI-Äquivalent zu Zero Trust für Workloads. Ein KI-Agent, der ein von PKIaaS ausgestelltes Zertifikat an eine API übermittelt, wird kryptografisch verifiziert, bevor eine Anwendungsanfrage verarbeitet wird. Ein Agent ohne gültiges PKIaaS-Zertifikat wird auf der TLS-Ebene abgewiesen, unabhängig davon, ob er sich in der Anwendungsnutzlast als autorisierter Agent ausgibt.
• Die regulatorischen Rahmenbedingungen für die Identität von KI-Agenten befinden sich im Wandel. Das NCCoE des NIST veröffentlichte 2026 ein Konzeptpapier zur Identität und Autorisierung von Software und KI-Agenten. Die ITU hat eine Fokusgruppe zu Vertrauen und Identität von KI-Agenten eingerichtet. Die Anforderungen des EU-KI-Gesetzes hinsichtlich Rechenschaftspflicht und menschlicher Aufsicht schaffen implizite Prüfpflichten für agentenbasierte KI-Systeme. Zertifikatsbasierte Identität ist der ausgereifteste technische Mechanismus, um diese neuen Anforderungen zu erfüllen.

Das KI-Agentenidentitätsproblem

KI-Agenten unterscheiden sich von herkömmlicher Software in einem entscheidenden Sicherheitsaspekt: ​​Sie agieren autonom. Ein Webserver bearbeitet Anfragen, initiiert sie aber nicht. Ein KI-Agent hingegen tut beides. Er erhält ein Ziel, analysiert dessen Erreichung und führt Aktionen in verschiedenen Systemen, APIs und Tools nacheinander aus – ohne menschliche Autorisierung in jedem Schritt. Die Berechtigung zu diesen Aktionen wurde dem Agenten bei der Bereitstellung übertragen, und die Kontrollen seiner Aktionen sind typischerweise grobkörnig: ein API-Schlüssel mit weitreichenden Berechtigungen, ein Dienstkonto mit umfassenden Zugriffsrechten oder ein systemweites Zugriffstoken, das nie speziell für die Aufgabe des Agenten festgelegt wurde.

Dadurch entsteht eine Lücke in Bezug auf Identität und Verantwortlichkeit, die mit zunehmender Größe des Unternehmens wächst. Setzt ein Unternehmen zehn KI-Agenten ein, ist diese Lücke noch überschaubar: Jeder weiß, worauf die einzelnen Agenten Zugriff haben. Setzt dasselbe Unternehmen jedoch tausend Agenten in Dutzenden von Workflows ein, kann niemand mehr zuverlässig beantworten: Welcher Agent hat den API-Aufruf um 2:47 Uhr getätigt? War er dazu berechtigt? Wie kann ich beweisen, dass die Aktion von Agent A und nicht von jemandem mit den Zugangsdaten von Agent A ausgeführt wurde?

Der Bericht „Palo Alto Networks 2026 Identity Security Landscape“ ermittelte ein Verhältnis von 109:1 zwischen Maschinenidentitäten und menschlichen Identitäten in Unternehmensumgebungen. KI-Agenten stellen den am schnellsten wachsenden Anteil dieser Maschinenidentitäten dar. Die Verwaltung ihrer Identitäten mit demselben statischen Anmeldeinformationsmodell, das für frühe Unternehmenssoftware verwendet wurde, ist keine Sicherheitsmaßnahme, sondern birgt ein hohes Haftungsrisiko.

Warum statische Anmeldeinformationen für KI-Agenten versagen

Statische Anmeldeinformationen versagen für KI-Agenten aus denselben Gründen, aus denen sie für jede Maschinenidentität versagen, verstärkt durch die autonome Natur des Agentenverhaltens:

Keine Identitätsbindung. Ein API-Schlüssel beweist lediglich, dass der Aufrufer im Besitz des Schlüssels ist, nicht aber, dass er der autorisierte Agent ist. Wird der Schlüssel aus der Umgebung des Agenten extrahiert, ist jeder Prozess mit diesem Schlüssel nicht vom Agenten zu unterscheiden. In einer Umgebung, in der Agenten miteinander interagieren (Kontextübergabe, Delegierung von Unteraufgaben, temporäre Zugriffsrechte teilen), steigt das Risiko des Datendiebstahls mit jeder Agenteninteraktion.

Kein automatischer Ablauf. API-Schlüssel laufen nicht ab, es sei denn, sie werden explizit erneuert. Ein außer Betrieb genommener KI-Agent behält seinen API-Schlüssel so lange gültig, bis das Betriebsteam dies bemerkt und ihn widerruft. In einer dynamischen Umgebung, in der Agenten für spezifische Aufgaben bereitgestellt und wieder entfernt werden, häufen sich verwaiste Anmeldeinformationen schnell an. Ein einem Agenten ausgestelltes Zertifikat mit einer Gültigkeitsdauer von 4 Stunden läuft mit dem Agenten ab, wodurch keine verwaisten Anmeldeinformationen entstehen und kein Aufräumaufwand erforderlich ist.

Keine Beweiskraft. Verursacht ein KI-Agent Schaden durch einen API-Aufruf, den er nicht hätte aufrufen sollen, oder durch das Auslösen einer Transaktion mit falschen Parametern, lässt sich anhand des API-Schlüssels im Audit-Log nicht eindeutig feststellen, welcher Agent den Aufruf getätigt hat, wenn der Schlüssel geteilt oder seine Verwahrung nicht nachverfolgt wurde. Ein X.509-Zertifikat mit einer spezifischen Seriennummer, ausgestellt für eine bestimmte Agentenbereitstellung, gewährleistet Beweiskraft: Der Eintrag im Audit-Log verweist auf das Zertifikat, das PKIaaS-Audit-Log protokolliert Ausstellungsdatum und Agentenidentität, und die Zuordnungskette ist kryptografisch vollständig.

X.509-Zertifikate als KI-Agentenidentität

Ein von einer PKIaaS-Zertifizierungsstelle ausgestelltes X.509-Zertifikat für einen KI-Agenten kodiert dessen Identität in einem kryptografisch verifizierbaren, standardisierten Format. Die Felder „Subject Distinguished Name“ und „Subject Alternative Name“ des Zertifikats enthalten die Identitätsattribute des Agenten. Ein gut konzipiertes Agentenidentitätszertifikat könnte beispielsweise Folgendes kodieren:

• CN (Gebräuchlicher Name): Name und Versionskennung des Agenten (zum Beispiel, order-processing-agent-v2.1)
• O (Organisation): Die Geschäftseinheit oder das Team, dem der Agent gehört
• Organisationseinheit (OU): Die Bereitstellungsumgebung (Produktion, Staging, Sandbox)
• URI SAN: Eine SPIFFE-ID, falls der Agent in einer SPIFFE-kompatiblen Umgebung eingesetzt wird (spiffe://trust-domain/agents/order-processing)
• Benutzerdefinierte OID-Erweiterungen: Agentenversion, autorisierter Workflow-Bereich oder Bereitstellungs-ID in benutzerdefinierten X.509-Erweiterungen, falls das Agentenautorisierungsmodell Richtlinienattribute im Zertifikat erfordert

Das Zertifikat wird von der PKIaaS-Zertifizierungsstelle signiert und ist somit für jeden Dienst verifizierbar, der das PKIaaS-Root-CA-Zertifikat in seinem Vertrauenspaket enthält. Der zum Zertifikat gehörende private Schlüssel wird in der Ausführungsumgebung des Agenten generiert und verlässt diese niemals. Die PKIaaS-Zertifizierungsstelle signiert das Zertifikat auf Basis der Zertifikatsignieranforderung (CSR) des Agenten, welche den öffentlichen Schlüssel enthält. Der private Schlüssel wird niemals über die PKIaaS-Zertifizierungsstelle, den Geheimnismanager oder eine gemeinsam genutzte Infrastruktur übertragen; er verbleibt ausschließlich im sicheren Speicher des Agenten für die Dauer der Zertifikatsgültigkeit.

Bereitstellung von Agentenidentitäten beim Start

Der Bereitstellungsprozess für Agentenidentitäten funktioniert wie folgt: Beim Start eines Agenten (sei es als Container in Kubernetes, als serverlose Funktion, als Prozess auf einer virtuellen Maschine oder als kurzlebiger Rechenauftrag) fordert der Bereitstellungsschritt ein Zertifikat von der PKIaaS-Zertifizierungsstelle an. Die Authentifizierung der Anfrage erfolgt über einen von mehreren Mechanismen:

• OIDC-Token-Tausch: Die KI-Orchestrierungsplattform stellt dem Agenten beim Start ein kurzlebiges OIDC-Token aus. Der Agent übermittelt dieses Token an den PKIaaS-ACME-Endpunkt (mit externer Kontobindung) und erhält im Gegenzug ein Zertifikat. GitHub Actions, GitLab CI, AWS STS, Azure AD Workload Identity und GCP Workload Identity stellen alle OIDC-Token aus, die für diesen Zweck geeignet sind. Das OIDC-Token dient als Startanmeldeinformation; das Zertifikat ist die operative Anmeldeinformation, die der Agent für seine eigentliche Arbeit verwendet.
• Plattformbestätigung: In Kubernetes-Umgebungen bestätigt SPIRE die Pod-Identität des Agenten mithilfe der Kubernetes-Knotenattestierung und Pod-Selektoren und stellt dem Agenten anschließend direkt über die SPIFFE Workload API ein SVID (SPIFFE Verifiable Identity Document) aus. Mit PKIaaS als SPIRE-Upstream-CA wird dieses SVID an die PKIaaS-Root-Instanz weitergeleitet.
• Bootstrap für den Geheimnismanager: Für Agenten, die nicht in Kubernetes laufen, verwaltet ein autorisierter Secrets Manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) eine einmalige Anmeldeinformation, mit der der Agent seine erste Zertifikatsanforderung authentifiziert. Diese Anmeldeinformation wird bei der Verwendung verbraucht, und der Agent nutzt für alle nachfolgenden Operationen das ausgestellte Zertifikat.

mTLS für die Kommunikation zwischen Agenten und Diensten sowie zwischen Agenten.

Sobald ein Agent über ein von PKIaaS ausgestelltes Zertifikat verfügt, verwendet er dieses Zertifikat für die gegenseitige TLS-Authentifizierung mit jedem aufgerufenen Dienst. mTLS für die Agent-Dienst-Kommunikation bietet zwei Sicherheitseigenschaften, die statische Anmeldeinformationen nicht bieten können:

Dienstverifizierung durch den Agenten: Der Agent überprüft das TLS-Zertifikat des Dienstes anhand des PKIaaS-Root-CA-Vertrauenspakets, bevor Daten gesendet werden. Ein KI-Agent, der einen gefälschten API-Endpunkt aufruft (ein Man-in-the-Middle-Angriff zur Exfiltration des Agentenkontexts oder zur Manipulation von Agentenaktionen), wird beim TLS-Handshake erkannt, da der gefälschte Endpunkt kein von der PKIaaS-CA signiertes Zertifikat vorweisen kann. Die Anfrage des Agenten erreicht niemals ein System, das er nicht kryptografisch verifiziert hat.

Agentenverifizierung durch den Dienst: Der Dienst überprüft das Agentenzertifikat anhand des PKIaaS-Root-CA-Vertrauenspakets, bevor er eine Anfrage verarbeitet. Ein nicht autorisierter Agent oder ein kompromittierter Prozess, der versucht, sich als Agent auszugeben, kann kein gültiges, von PKIaaS ausgestelltes Zertifikat vorlegen (das Zertifikat ist kryptografisch an den privaten Schlüssel gebunden, der im Ausführungskontext des legitimen Agenten generiert wurde). Der Dienst lehnt die Verbindung ab, bevor Anwendungslogik ausgeführt wird.

Für die Agentenkommunikation in Multiagenten-Workflows gilt dasselbe mTLS-Muster. Agent A präsentiert sein Zertifikat Agent B; Agent B verifiziert es anhand des PKIaaS-Root-Zertifikats; Agent B präsentiert sein Zertifikat Agent A; Agent A verifiziert es. Keiner der Agenten kann von einem Prozess imitiert werden, der nicht über den entsprechenden privaten Schlüssel verfügt.

Zertifikatbasiertes OAuth: Absicherung von Agentenautorisierungsabläufen

Viele KI-Agenten interagieren mit APIs, die OAuth 2.0 zur Autorisierung verwenden. Das Standard-OAuth-Muster für Maschinenclients ist der Client Credentials Grant: Der Client (Agent) übermittelt eine Client-ID und ein Client-Geheimnis, um ein Zugriffstoken zu erhalten. Das Client-Geheimnis ist ein statisches Anmeldeinformationsmerkmal mit den oben beschriebenen Problemen.

Zertifikatsbasiertes OAuth ersetzt das Client-Geheimnis durch das X.509-Zertifikat des Agenten. Bei diesem Verfahren, das die OAuth 2.0 Mutual-TLS-Clientauthentifizierung (RFC 8705) nutzt, authentifiziert sich der Agent beim OAuth-Autorisierungsserver mithilfe seines von PKIaaS ausgestellten Zertifikats im TLS-Handshake (mTLS-Clientauthentifizierung), anstatt ein Client-Geheimnis im Anfragetext zu übermitteln. Der Autorisierungsserver überprüft das Zertifikat anhand des PKIaaS-CA-Vertrauenspakets und stellt ein Zugriffstoken aus, das an den Fingerabdruck des Zertifikats gebunden ist. Dieses Zugriffstoken ist nur gültig, wenn es zusammen mit dem Zertifikat vorgelegt wird, mit dem es ausgestellt wurde: Das Bearer-Token und das Client-Zertifikat müssen übereinstimmen. Gestohlene Zugriffstoken sind daher ohne den zugehörigen privaten Schlüssel wertlos.

Für Workflows mit mehreren Agenten ermöglicht die OAuth 2.0 Token Exchange-Spezifikation (RFC 8693) Agenten den Bezug von Zugriffstoken, die die Delegierungskette kodieren: Agent B kann ein Token anfordern, das belegt, dass er mit der von Agent A delegierten Autorität handelt. Agent A wurde wiederum von dem Benutzer oder Systemprinzipal autorisiert, der den Workflow initiiert hat. In Kombination mit zertifikatsbasierter Authentifizierung an jedem Hop wird die Delegierungskette kryptografisch verifizierbar: Jedes Zugriffstoken in der Kette ist an ein bestimmtes Zertifikat gebunden, jedes Zertifikat wurde von der PKIaaS-CA für eine bestimmte Agentenidentität ausgestellt, und das PKIaaS-Audit-Log protokolliert den Ausstellungsverlauf.

Das Delegationskettenproblem in Multiagenten-Workflows

Die technisch komplexeste Herausforderung im Bereich der Identitätsverwaltung in agentenbasierter KI ist die Delegationskette: Wenn Agent A eine Aufgabe an Agent B delegiert, der ein Tool aufruft, welches wiederum eine Zahlung in einem Finanzsystem auslöst, muss jedes System in dieser Kette die Autorisierungskette kennen, die die endgültige Aktion bewirkt hat. Ohne kryptografische Delegationsketten sieht das Finanzsystem lediglich, dass Agent B diese Anfrage gestellt hat, ohne zu wissen, dass Agent B im Auftrag von Agent A handelte. Dieser Auftrag wurde von einem menschlichen Workflow-Verantwortlichen erteilt und durch eine Organisationsrichtlinie eingeschränkt.

Dies ist aus drei Gründen wichtig. Erstens, Autorisierung: Das Finanzsystem muss überprüfen, ob die oberste Instanz in der Kette (die Person oder Organisation) berechtigt war, die von Agent B angeforderte Zahlung zu autorisieren. Zweitens, Verantwortlichkeit: Fragt der Prüfer, wer eine bestimmte Transaktion autorisiert hat, muss die Antwort über jeden Agenten in der Kette bis zu einer von einem Menschen verantworteten Entscheidung nachvollziehbar sein. Drittens, Begrenzung: Wird Agent B kompromittiert oder falsch konfiguriert, beschränkt sich der Schaden auf das, was die Delegationskette autorisiert, und nicht auf alles, worauf der API-Schlüssel von Agent B zugreifen kann.

Der technische Mechanismus für kryptografische Delegierungsketten kombiniert zertifikatsbasierte Identität mit Token-Austausch. Agent A besitzt ein PKIaaS-Zertifikat, das seine Identität kodiert. Agent A authentifiziert sich mit diesem Zertifikat beim Autorisierungsserver und erhält ein Zugriffstoken, das auf seinen autorisierten Workflow beschränkt ist. Bei der Delegierung an Agent B verwendet Agent A den Token-Austausch gemäß RFC 8693, um ein delegiertes Zugriffstoken für Agent B zu erhalten. Dieses Token kodiert sowohl die Identität von Agent A als auch die von Agent B (sowie die Bereichsbeschränkungen der Delegierung). Agent B verwendet sein eigenes PKIaaS-Zertifikat zur mTLS-Authentifizierung, wenn er dieses delegierte Token vorlegt. Jedes von Agent B aufgerufene System kann die vollständige Delegierungskette anhand der Token-Ansprüche und des im mTLS-Handshake präsentierten Zertifikats verifizieren.

Sicherung der KI-Infrastruktur: Mehr als nur Agentenidentität

Die Identität von KI-Agenten ist der sichtbarste PKI-Anwendungsfall für KI-Infrastrukturen, aber nicht der einzige. Die Infrastruktur, die KI unterstützt, benötigt auch PKI-gestützte Sicherheit.

Modell-Bereitstellungsinfrastruktur

KI-Modell-Inferenzendpunkte (unabhängig davon, ob sie lokal, auf ML-Plattformen von Cloud-Anbietern oder über API-Dienste gehostet werden) dienen als Backends, die von Agenten abgefragt werden. Diese Endpunkte benötigen TLS-Zertifikate für eine sichere Übertragung. In Umgebungen, in denen nur autorisierte Agenten Inferenzendpunkte aufrufen dürfen, muss der Inferenzendpunkt zudem die Identität des Agenten verifizieren (mTLS auf der Inferenz-API-Ebene). Eine PKIaaS-Zertifizierungsstelle, die Zertifikate sowohl für die Inferenzinfrastruktur als auch für die Agenten ausstellt, bildet die Vertrauensbasis für diese bidirektionale Verifizierung.

Schulungs- und Feinabstimmungsinfrastruktur

Die Infrastruktur für das Training und die Feinabstimmung von KI-Modellen verarbeitet sensible Daten: Trainingsdatensätze, Modellgewichte, Evaluierungsergebnisse und Feedbackdaten. Die Kommunikation zwischen den Komponenten der Trainingsinfrastruktur (Datenlader, Rechenknoten, Speicher für Modell-Checkpoints, Dienste zur Experimentverfolgung) sollte über TLS-Zertifikate der PKIaaS-Zertifizierungsstelle der Organisation und nicht über selbstsignierte Zertifikate erfolgen. Dadurch wird sichergestellt, dass die interne Kommunikation der Trainingsinfrastruktur gemäß der Vertrauenshierarchie der Organisation authentifiziert und verschlüsselt ist und dass die Zertifikatsidentität jeder am Modelltraining beteiligten Komponente in den Audit-Logs erfasst wird.

Modellartefaktsignierung

KI-Modellartefakte (Gewichte, Konfigurationsdateien, Eingabeaufforderungsvorlagen, Werkzeugdefinitionen) sollten mit Codesignaturzertifikaten der PKIaaS-Zertifizierungsstelle signiert werden. Ein von der PKIaaS-Zertifizierungsstelle der Organisation signiertes Modellartefakt kann als authentisch (erstellt durch den autorisierten Modellentwicklungsprozess der Organisation) und unverändert (die Signatur ist ungültig, wenn das Artefakt nach der Signierung manipuliert wurde) verifiziert werden. Dies entspricht der Sicherheit in der Software-Lieferkette: So wie die Codesignatur sicherstellt, dass bereitgestellte Software durch eine autorisierte Build-Pipeline erstellt wurde, gewährleistet die Signierung von Modellartefakten, dass bereitgestellte Modelle durch eine autorisierte Trainings- oder Feinabstimmungs-Pipeline erstellt wurden.

Agenten-Framework-Infrastruktur

Die Infrastrukturkomponenten agentenbasierter KI-Frameworks (Orchestratoren, Speicher, Tool-Registries, Agentenmanagement-APIs, Observability-Plattformen) sind selbst Dienste, mit denen Agenten und Operatoren interagieren. Diese Komponenten sollten über TLS-Zertifikate einer PKIaaS-Zertifizierungsstelle verfügen, und die von ihnen bereitgestellten APIs sollten eine mTLS-Authentifizierung von den aufrufenden Agenten und Operatoren erfordern. Eine Orchestrierungs-API, die von jedem nicht authentifizierten Prozess aufgerufen werden kann, stellt keine sichere Orchestrierungsschicht dar; sie ist eine Schwachstelle in der Steuerungsebene, die von einem Agenten ausgenutzt werden kann, dessen Authentifizierungskontext manipuliert wurde.

Maschinenidentitätsinventar für KI-Agenten

Die in früheren Beiträgen zur Workload-Identität beschriebene Herausforderung der Maschinenidentitätsverwaltung ist für KI-Agenten besonders akut, da Agenten schneller bereitgestellt und deaktiviert werden als herkömmliche Workloads. Eine agentenbasierte KI-Plattform kann Hunderte von Agenten pro Stunde starten, jeder mit einem eigenen Zertifikat. Ohne eine Maschinenidentitätsverwaltung, die nachverfolgt, welche Zertifikate welchen Agenten ausgestellt wurden und welche Agenten noch aktiv bzw. deaktiviert sind, verliert das Unternehmen fast unmittelbar nach Beginn der großflächigen Bereitstellung die Transparenz über seine KI-Agentenidentitäten.

Eine mit der PKIaaS-Zertifizierungsstelle verbundene CLM-Plattform stellt das Maschinenidentitätsinventar für KI-Agenten bereit: Jede Zertifikatsausstellung wird mit den Identitätsattributen des Agenten, dem Ausstellungszeitstempel, der Gültigkeitsdauer und dem PKIaaS-Audit-Logeintrag, der das Zertifikat mit der Ausstellungsanfrage verknüpft, protokolliert. Bei kurzlebigen Agentenzertifikaten (1 bis 24 Stunden) zeigt das Inventar die aktuell aktiven Agenten an: welche Agenten über gültige Zertifikate verfügen und welche Zertifikate abgelaufen sind (und die entsprechenden Agenten nicht mehr aktiv sein sollten). Zeigt das CLM-Inventar ein aktives Zertifikat für einen Agenten an, dessen Einsatz beendet wurde, deutet dies darauf hin, dass die Beendigung des Agenten keine ordnungsgemäße Bereinigung der Anmeldeinformationen beinhaltete oder dass das Zertifikat vor der Beendigung des Agenten exfiltriert wurde.

Für die Steuerung von KI-Agenten bietet das CLM-Inventar auch eine Richtliniendurchsetzung: Zertifikate, die an KI-Agenten ausgestellt werden und die die maximal zulässige Gültigkeitsdauer überschreiten, die an Agenten mit Namenskonventionen ausgestellt werden, die gegen die Unternehmensrichtlinien verstoßen, oder die an Agenten in Umgebungen ausgestellt werden, in denen sie nicht zum Betrieb berechtigt sind, werden allesamt als Richtlinienverstöße angezeigt, die zur Behebung markiert werden können, bevor der Agent einen Vorfall verursacht.

Der Prüfpfad: KI-Aktionen zurechenbar machen

Eine der Governance-Anforderungen für agentenbasierte KI in regulierten Umgebungen ist die Nachvollziehbarkeit von KI-Aktionen: Wenn ein KI-Agent eine Entscheidung trifft, einen Datensatz ändert oder eine Transaktion auslöst, muss ein prüfbarer Nachweis darüber vorliegen, welcher Agent die Entscheidung getroffen hat, unter welcher Befugnis und in welchem ​​Zeitraum. Zertifikatsbasierte Agentenidentität ermöglicht diese Zuordnung auf Infrastrukturebene, anstatt sich auf Anwendungsprotokollierung zu verlassen, die von den Agenten selbst gesteuert wird.

Die Zuordnungskette funktioniert wie folgt: Die PKIaaS-Zertifizierungsstelle stellt Agent X zum Zeitpunkt T ein Zertifikat mit der Seriennummer S aus, das 4 Stunden gültig ist. Agent X verwendet dieses Zertifikat zur Authentifizierung an der Transaktions-API. Das Zugriffsprotokoll der Transaktions-API protokolliert die Seriennummer S des Client-Zertifikats und die Anfragedetails. Das PKIaaS-Audit-Protokoll protokolliert, dass das Zertifikat S zum Zeitpunkt T für die Agentenidentität „order-processing-agent-v2.1/production“ mit einer Gültigkeit von 4 Stunden ausgestellt wurde. Die Kombination beider Protokolle ergibt eine vollständige Zuordnung: „Um 14:32:07 rief die Instanz order-processing-agent-v2.1 in der Produktionsumgebung (Zertifikat S, ausgestellt um 14:00:00) die Transaktions-API auf und initiierte die Zahlungstransaktion Nr. 4472.“

Diese Zuordnung ist kryptografisch unanfechtbar: Die Zertifikatseriennummer im Zugriffsprotokoll entspricht einem spezifischen privaten Schlüssel, der im Ausführungskontext der jeweiligen Agenteninstanz generiert wurde. Kein anderer Prozess hätte das Zertifikat S ohne den zugehörigen privaten Schlüssel vorlegen können, und dieser private Schlüssel wurde im Speicher des Agenten generiert und nicht an einem Ort gespeichert, auf den ein anderer Prozess zugreifen könnte. Die Zuordnung ist unabhängig von den Protokollen des Agenten selbst, die ein Angreifer, der den Agenten kompromittiert hat, manipulieren könnte.

Neue regulatorische Signale für die Identität von KI-Agenten

Die regulatorischen Rahmenbedingungen für die Identität von KI-Agenten befinden sich noch in der Anfangsphase, entwickeln sich aber rasant. Mehrere Signale aus den Jahren 2025 und 2026 weisen die Richtung an:

NIST NCCoE (2026): Das Nationale Kompetenzzentrum für Cybersicherheit (NCCoE) des NIST veröffentlichte 2026 ein Konzeptpapier zur Identität und Autorisierung von Software und KI-Agenten. Daraus geht hervor, dass die wichtigste US-amerikanische Normungsorganisation für Cybersicherheit derzeit formale Richtlinien zur kryptografischen Identität von KI-Agenten erarbeitet. Organisationen, die bereits jetzt zertifikatsbasierte Agentenidentitäten entwickeln, sind damit der voraussichtlich zukünftigen formalen Empfehlung einen Schritt voraus.

ITU-Fokusgruppe: Die Internationale Fernmeldeunion (ITU) hat 2026 eine Fokusgruppe zum Thema Vertrauen und Identität von KI-Agenten eingerichtet. Deren Auftrag ist die Entwicklung internationaler Rahmenbedingungen für die Identität und Verantwortlichkeit von Agenten. Dies signalisiert, dass die Identität von KI-Agenten als Problem internationaler Standards und nicht nur als herstellerspezifische Implementierungsfrage behandelt wird.

Anforderungen an die Rechenschaftspflicht gemäß EU-KI-Gesetz: Das ab August 2024 schrittweise in Kraft tretende EU-KI-Gesetz verpflichtet KI-Systeme mit hohem Risiko zur Führung von Betriebsprotokollen, die eine menschliche Überwachung und nachträgliche Verantwortlichkeit ermöglichen. Für agentenbasierte KI-Systeme, die in Hochrisikobereichen (z. B. Einstellungsentscheidungen, Kreditwürdigkeitsprüfung, Management kritischer Infrastrukturen) autonom agieren, lässt sich die Rechenschaftspflicht am einfachsten durch kryptografische Zuordnung der Agentenaktionen erfüllen, wie sie zertifikatsbasierte Identitätsprüfung gewährleistet.

Erwartungen an die KI-Governance im Finanzsektor: Die EBA (Europäische Bankenaufsichtsbehörde) und andere Aufsichtsbehörden des Finanzsektors integrieren die KI-Governance in ihre Leitlinien zum IKT-Risikomanagement. Für Finanzinstitute, die KI-Agenten zur Automatisierung von Handel, Kreditentscheidungen, Kundenservice oder Betrugserkennung einsetzen, umfasst die KI-Governance die Prüfbarkeit automatisierter Entscheidungen, was die Zuordnung der Agentenidentitäten erfordert.

Wie Verschlüsselungsberatung helfen kann

• PKI als Dienstleistung: Verschlüsselungsberatung PKIaaS-Angebot Bietet die CA-Infrastruktur für die Identität von KI-Agenten: ACME+EAB für die OIDC-basierte Agentenzertifikatsbereitstellung, REST-API für die direkte Integration in KI-Orchestrierungsplattformen, SPIFFE-Upstream-CA-Plugin für Kubernetes-basierte Agentenbereitstellungen und Zertifikatsprofile für kurzlebige, temporäre Agentenidentitäten (Gültigkeit: 15 Minuten bis 4 Stunden). Kontaktieren Sie uns unter Verschlüsselungsberatung um Ihre KI-Agentenidentitätsarchitektur zu besprechen.
• CertSecure Manager: Verschlüsselungsberatung CertSecure Manager bietet die Ebene für die Maschinenidentitätsinventarisierung für KI-Agentenzertifikatsbestände: kontinuierliche Erkennung von PKIaaS-ausgestellten Agentenzertifikaten, Ablaufüberwachung mit aktiver Agentenverfolgung, Durchsetzung von Richtlinien für Gültigkeitszeiträume und Namenskonventionen von Zertifikaten sowie SIEM-Integration, die Ereignisse aus dem Lebenszyklus von Agentenzertifikaten zusammen mit API-Gateway-Zugriffsprotokollen in den Sicherheitsüberwachungs-Stack einspeist, um die in diesem Beitrag beschriebene Zuordnungskorrelation zu ermöglichen.
• CBOM Secure: Für Organisationen, die die kryptografische Sicherheit ihrer KI-Infrastruktur vor dem Einsatz zertifikatsbasierter Agentenidentität bewerten, bietet Encryption Consulting die passende Lösung. CBOM Secure bietet kryptografische Erkennung, die vorhandene statische Anmeldeinformationen (API-Schlüssel, Token, Client-Geheimnisse) aufdeckt, die von KI-Agenten und der Infrastruktur verwendet werden, und ermöglicht so eine priorisierte Migration von statischen Anmeldeinformationen zu zertifikatsbasierter Identität.
• PKI-Dienste: Für Organisationen, die die Identitätsarchitektur für KI-Agenten von Grund auf neu entwickeln, einschließlich der Konfiguration des OIDC-Token-Austauschs, des Zertifikatsprofildesigns für Agentenidentitätsattribute, der mTLS-Konfiguration für Inferenzendpunkte und Orchestrierungs-APIs sowie des Delegierungskettendesigns unter Verwendung des RFC 8693 Token-Austauschs, bietet Encryption Consulting die passende Lösung. PKI-Dienste Architekturberatung und Implementierungsunterstützung für jede Komponente des Agentenidentitätsprogramms.
• Beratungsleistungen im Bereich Compliance: Für Organisationen in regulierten Sektoren, die agentenbasierte KI einsetzen (Finanzdienstleistungen gemäß DORA, Gesundheitswesen gemäß HIPAA, Bundesbehörden gemäß FISMA/FedRAMP oder EU-Einrichtungen gemäß dem AI Act), bietet Encryption Consulting die Lösung. Compliance-Beratungsdienste Die Architektur der KI-Agentenidentität wird den geltenden regulatorischen Rechenschafts- und Prüfbarkeitsanforderungen zugeordnet, wodurch ein Rahmenwerk für den Nachweis der Konformität entsteht, das aufzeigt, wie die zertifikatsbasierte Agentenidentität die entsprechenden Verpflichtungen erfüllt.

Fazit

KI-Agenten sind Maschinen. Sie benötigen eine Maschinenidentität. Die Technologie für kryptografische Maschinenidentität ist in PKI-Systemen seit Jahrzehnten produktionserprobt; neu ist ihre Anwendung auf eine Klasse von Maschinen, die schneller, autonomer und mit weitreichenderen Folgen als herkömmliche Workloads arbeiten. Ein KI-Agent, der Konfigurationen ändert, Zahlungen auslöst oder mit kritischen Systemen interagiert, sollte mindestens genauso gut identifiziert sein wie ein Webserver oder ein in eine Domäne eingebundener Laptop. Er muss sogar sorgfältiger identifiziert werden, denn die Folgen eines nicht identifizierten oder imitierten KI-Agenten sind kein 503-Fehler, sondern autonome Aktionen, die mit der falschen Berechtigung ausgeführt werden.

PKIaaS stellt die CA-Infrastruktur bereit, um KI-Agenten eindeutige, kurzlebige und verifizierbare Identitäten in dem Umfang und der Geschwindigkeit auszustellen, die für agentenbasierte KI-Implementierungen erforderlich sind. Die verwendeten Muster – OIDC-Token-Austausch für die Bereitstellung, SPIFFE/SPIRE für Kubernetes-basierte Agenten, mTLS für die Agent-zu-Dienst-Kommunikation, zertifikatsbasiertes OAuth für Autorisierungsabläufe und RFC-8693-Token-Austausch für Delegierungsketten – sind bereits produktionsreif. Die Herausforderung besteht nun darin, diese mit den spezifischen KI-Orchestrierungsplattformen und der Infrastruktur des Unternehmens zu konfigurieren und zu integrieren.

Organisationen, die jetzt, bevor die Agentenbereitstellungen einen Punkt erreichen, an dem eine nachträgliche Implementierung praktikabel ist, eine zertifikatsbasierte Identitätsverwaltung für KI-Agenten in ihre agentenbasierten KI-Programme integrieren, erhalten die von Regulierungsbehörden geforderten Prüfprotokolle, die Verantwortlichkeit und die Zugriffskontrollen, die Sicherheitsteams letztendlich benötigen werden. Organisationen, die erst handeln, wenn eine regulatorische Vorgabe dies erzwingt, rüsten ihre bereits bereitgestellte Agentenpopulation nachträglich mit einer Identitätsinfrastruktur aus, die ursprünglich ohne diese konzipiert wurde.

Wenn Ihre Organisation KI-Agenten einsetzt und eine zertifikatsbasierte Identitätsarchitektur dafür entwerfen möchte, wenden Sie sich an Encryption Consulting.

Dieser Beitrag wird halbjährlich überprüft und immer dann aktualisiert, wenn NIST, ITU, die Durchführungsbestimmungen des EU AI Act oder wichtige agentenbasierte KI-Rahmenwerke wesentliche Aktualisierungen der Anforderungen oder Empfehlungen zur Identität von KI-Agenten veröffentlichen.

Häufig gestellte Fragen

Warum benötigen KI-Agenten eine kryptografische Identität anstelle von API-Schlüsseln?

API-Schlüssel sind statisch, teilbar, laufen nicht automatisch ab und liefern keinen kryptografischen Nachweis darüber, welcher Agent sie verwendet hat. Ein von PKIaaS ausgestelltes X.509-Zertifikat ist kurzlebig, kryptografisch an den Ausführungskontext des jeweiligen Agenten gebunden, unanfechtbar und wird automatisch erneuert. Ein gestohlenes Zertifikat ist nach Ablauf seiner Gültigkeitsdauer wertlos; ein gestohlener API-Schlüssel bleibt bis zur manuellen Erneuerung nutzbar. Laut dem IBM-Bericht „Cost of Data Breach 2025“ fehlten 97 % der Unternehmen, die Sicherheitslücken in KI-Modellen erlitten, entsprechende Zugriffskontrollen.

Was ist das Problem der Delegierungskette von KI-Agenten?

In Multi-Agenten-Workflows delegiert Agent A Aufgaben an Agent B, der daraufhin Tools aufruft und Transaktionen auslöst. Jeder Schritt muss kryptografisch bis zu einem verantwortlichen Prinzipal zurückverfolgbar sein. Ohne kryptografische Delegierungsketten kann jeder Agent jede beliebige Autorisierung beanspruchen. Zertifikatsbasierte Identität in Kombination mit OAuth 2.0 Token Exchange (RFC 8693), verankert in PKIaaS-ausgestellten Zertifikaten, bietet den technischen Mechanismus für eine verifizierbare Delegierungskette, in der die Identität und der Autorisierungsbereich jedes einzelnen Schritts kryptografisch nachweisbar sind.

Wie funktioniert mTLS für die Kommunikation zwischen KI und Diensten?

mTLS erfordert, dass sowohl der KI-Agent als auch der Dienst Zertifikate vorlegen und verifizieren, bevor die Verbindung hergestellt wird. Der Agent verifiziert das Zertifikat des Dienstes (um Aufrufe gefälschter Endpunkte zu verhindern), und der Dienst verifiziert das Zertifikat des Agenten (um nicht autorisierte Agenten auf der TLS-Ebene abzuweisen). Zertifikatbasiertes OAuth (RFC 8705) erweitert dies, indem es OAuth-Zugriffstoken an den Fingerabdruck des Agentenzertifikats bindet. Dadurch sind gestohlene Zugriffstoken ohne den zugehörigen privaten Schlüssel nutzlos.

Wie kurzlebig sollten Zertifikate für KI-Agenten sein?

Für kurzlebige Agenten, die für eine einzelne Aufgabe gestartet werden: 15 Minuten bis 4 Stunden, entsprechend der erwarteten Aufgabendauer. Für dauerhafte Agenten: 24 bis 48 Stunden mit automatischer Verlängerung vor Ablauf. Die Gültigkeitsdauer sollte kurz genug sein, damit ein kompromittiertes Zertifikat abläuft, bevor ein Angreifer es effektiv ausnutzen kann, und lang genug, damit die Infrastruktur für die automatische Verlängerung es zuverlässig ersetzt, bevor der Agent ohne gültige Anmeldeinformationen ausgeführt wird.

Wie ist der regulatorische Status der Anforderungen an die Identität von KI-Agenten?

Das Thema ist noch im Entstehen, entwickelt sich aber rasant. Das NCCoE des NIST veröffentlichte ein Konzeptpapier für 2026 zur Identität und Autorisierung von Software und KI-Agenten. Die ITU richtete eine Fokusgruppe für 2026 zum Thema Vertrauen und Identität von KI-Agenten ein. Der EU-KI-Act schafft Rechenschafts- und Prüfpflichten für risikoreiche KI-Systeme. Aufsichtsbehörden des Finanzsektors integrieren KI-Governance in ihre Leitlinien zum IKT-Risikomanagement. Zertifikatsbasierte kryptografische Identität ist der ausgereifteste technische Mechanismus, um diese neuen Anforderungen an Rechenschaftspflicht und Zuordnung zu erfüllen.