Die Steuerung von KI-Agenten beginnt mit der Maschinenidentität. 

Die Art und Weise, wie Unternehmen über KI sprechen, hat sich im letzten Jahr verändert. Früher sorgte man sich darum, was ein Modell sagen könnte, ob es Halluzinationen hätte, Geheimnisse preisgeben oder etwas Anstößiges generieren würde. Heute geht es darum, was ein Modell leisten kann. KI-Agenten haben die Demo-Umgebung verlassen und sind in den Produktivbetrieb übergegangen, wo sie APIs aufrufen, Datenbanken abfragen, Geld transferieren und Tickets erstellen – eine Aktion nach der anderen, weitgehend ohne menschliche Aufsicht. Die Governance von KI-Agenten umfasst die Gewährung, Einschränkung, Überwachung und den Entzug der Befugnisse eines autonomen Agenten. Die Maschinenidentität – ein verifizierbarer, kryptografisch gesicherter Nachweis für jeden Agenten – ist der Kontrollpunkt, der die Durchsetzung dieser Regelung ermöglicht.

Diese Änderung ist wichtig, da ein Agent, der handeln kann, eine Berechtigung zum Handeln benötigt, und Berechtigung ist in erster Linie ein Identitätsproblem. Dieser Leitfaden erläutert, warum die Agenten-Governance – und nicht die Eingabeaufforderung oder die Modellebene – auf Identität basiert, wo die Governance aktuell versagt und wie PKI-, Sicherheits-, Plattform- und Compliance-Teams sie auf einer zertifikatbasierten Maschinenidentitätsgrundlage aufbauen können.

Wichtige Erkenntnisse

• Ein KI-Agent verhält sich wie eine privilegierte Arbeitslast, nicht wie ein Chatbot: Er verfügt über Anmeldeinformationen, stellt authentifizierte Anfragen und übt echten Zugriff aus, daher muss die Governance auf der Identitätsebene beginnen, nicht auf der Eingabeaufforderungsebene.
• Gartner geht davon aus, dass bis Ende 2026 rund 40 % der Unternehmensanwendungen aufgabenspezifische KI-Agenten integrieren werden, gegenüber weniger als 5 % im Jahr 2025. Microsoft berichtet, dass allein mit Copilot Studio über eine Million Agenten erstellt wurden.
• Die meisten Agentenidentitäten im heutigen Produktivbetrieb basieren auf SPIFFE- oder X.509-Zertifikaten, was bedeutet, dass die explosionsartige Zunahme von Maschinenidentitäten auch ein Problem des Zertifikatslebenszyklusmanagements darstellt, das genau zu dem Zeitpunkt auftritt, an dem die Gültigkeitsdauer öffentlicher TLS-Zertifikate auf etwa 47 Tage schrumpft.
• 51 % der Organisationen berichten, dass es keine klare Zuständigkeit für ihre KI-Identitäten gibt, und nur 18 % der Sicherheitsverantwortlichen sind sehr zuversichtlich, dass ihre Identitätssysteme Agentenidentitäten überhaupt verwalten können.
• Die Teams für PKI, Sicherheit, Plattform und Compliance sind jeweils für eine bestimmte Aufgabe zuständig; die untenstehende Verantwortlichkeits-/Aufgabenmatrix und Entscheidungstabelle zeigen genau, was und wer dafür verantwortlich ist.

Direkt zu: Zusammenfassung | Identität als Kontrollpunkt | Die Daten hinter der Dringlichkeit | Entscheidungstabelle | Verantwortlichkeits-/Maßnahmenmatrix | Nächste Schritte | FAQ

Zusammenfassung für die Teams PKI, Sicherheit, Plattform und Compliance

Wenn Sie eine dieser Funktionen leiten, finden Sie hier die in diesem Artikel unterstützte Entscheidung und eine Kurzübersicht zur Umsetzung.

• PKI-Teams: Behandeln Sie jeden KI-Agenten als zertifikatgestützte Workload-Identität und planen Sie die CA-Kapazität für eine um eine Größenordnung höhere Ausstellungsmenge.
• Sicherheitsteams: Abschaffung der Verwendung von geliehenen und gemeinsam genutzten Zugangsdaten für Agenten und Durchsetzung des Prinzips der minimalen Berechtigungen und des Just-in-Time-Zugriffs für jede Agentenidentität.
• Plattform-/DevSecOps-Teams: Die Ausstellung, Rotation und der Widerruf von Agentenidentitäten sollten über SPIFFE/SPIRE oder eine gleichwertige Zertifikatslebenszyklusplattform automatisiert werden; manuelle Prozesse können mit der zunehmenden Anzahl von Agenten nicht Schritt halten.
• Compliance-Teams: Bestätigen Sie, dass jede Agentenaktion einer aufgelösten Identität und, bei Workflows mit mehreren Agenten, der gesamten Delegationskette bis hin zu einem Menschen zugeordnet werden kann.

Warum Identität der eigentliche Kontrollpunkt ist

Es ist hilfreich, aus Sicherheitssicht genau zu definieren, was ein KI-Agent tatsächlich ist. Lässt man die Begriffe „logisches Denken“ und „Autonomie“ außer Acht, bleibt eine Software übrig, die Anmeldeinformationen verwaltet, authentifizierte Anfragen stellt und Berechtigungen gegenüber realen Systemen ausübt. Anders ausgedrückt: Sie verhält sich eher wie eine privilegierte Anwendung als wie ein Chatbot.

Diese Umdeutung ist der Kern des Spiels. Sobald man akzeptiert, dass ein Agent ein nicht-menschlicher Akteur mit Zugriffsrechten ist, wird die Frage der Kontrolle vertraut: Wer ist das, was darf er berühren, und lässt sich beweisen, was er getan hat?

Die Identität ist der natürliche Engpass für alle drei. Die Authentifizierung legt fest, wer der Agent ist, die Autorisierung definiert seine Zugriffsrechte, und ein identitätsbezogener Prüfpfad protokolliert seine tatsächlichen Aktionen. Wird ein Agent anders gesteuert, bleibt nur der Datenverkehr, ohne dass eine Aktion einer verantwortlichen Identität zugeordnet werden kann. Ohne diese Verknüpfung ist keine Steuerung möglich, sondern nur die nachträgliche Beobachtung.

Es gibt einen tieferliegenden Grund, warum die Identität und nicht die Anwendung der Kontrollpunkt sein muss. Die Autorisierung innerhalb der Anwendung ist genau das, was ein kompromittierter oder manipulierter Agent umgehen kann, da der Agent selbst die Anwendung ist. Gültige Anmeldeinformationen und eine autorisierte Sitzung garantieren dann kein sicheres Ergebnis mehr. Indem die Entscheidung auf die Identitätsebene verlagert wird – auf die Frage, was dieser Agent ist und was er tun darf –, wird die Durchsetzung an einer Stelle platziert, die von einer manipulierten Eingabeaufforderung nicht erreicht werden kann.

Genau deshalb führt die OWASP Top 10 für agentenbasierte Anwendungen, die im Dezember 2025 als erste formale Taxonomie agentenspezifischer Risiken veröffentlicht wurde, Identitäts- und Privilegienmissbrauch neben Zielübernahme und bösartigen Agenten als Hauptkategorien auf. Allen diesen Risiken ist gemeinsam, dass ein Agent etwas tut, wozu er niemals hätte fähig sein dürfen, weil die zugrunde liegende Identitäts- und Zugriffsgrundlage zu breit gefasst, zu stark übernommen oder zu schlecht überwacht war, um dies zu verhindern.

Das Problem der Größenordnung: Wenn Maschinen die Menschen zahlenmäßig übertreffen

Hier die beunruhigende Ausgangslage: Maschinenidentitäten übertreffen menschliche Identitäten bereits bei Weitem – Schätzungen zufolge mehr als 80 zu 1 im gesamten Unternehmen – und KI-Systeme verschärfen diese Entwicklung noch. Das genaue Verhältnis variiert je nach Umgebung und Methode, doch die Richtung ist eindeutig. Viele dieser Identitäten verfügen über sensible oder privilegierte Zugriffsrechte, die niemals von einem Menschen überwacht werden.

Dieses Volumen wäre beherrschbar, wenn die Identitäten gut verwaltet würden, was aber in der Regel nicht der Fall ist. Jüngste Branchenstudien zeigen, dass 51 % der Unternehmen keine eindeutige Zuständigkeit für ihre KI-Identitäten angeben. Das bedeutet, dass mehr als die Hälfte nicht einmal sagen kann, wer für einen bestimmten Agenten oder eine bestimmte Berechtigung verantwortlich ist. Und in einer Umfrage von Ende 2025 waren nur 18 % der Sicherheitsverantwortlichen sehr zuversichtlich, dass ihre bestehenden Identitätssysteme Agentenidentitäten überhaupt verwalten könnten.

Das Muster ist eindeutig: Organisationen setzen autonome Software weitaus schneller ein, als sie das Identitätsgerüst aufbauen, um diese zu steuern.

Die Daten hinter der Dringlichkeit

Die Agentenidentität ist kein vom Zertifikatslebenszyklusmanagement getrenntes Problem, sondern ein zunehmend wichtiger Bestandteil davon. Die meisten Agentenidentitäts-Frameworks, darunter SPIFFE/SPIRE und das Agentenidentitätsmodell von Google Cloud, basieren auf kurzlebigen X.509-Zertifikaten. Das bedeutet, dass jeder neue Agent – ​​vereinfacht ausgedrückt – ein neuer Zertifikatsnutzer ist, der genau dann zum Einsatz kommt, wenn die Gültigkeit öffentlicher TLS-Protokolle am schnellsten abnimmt.

• 45 % der Unternehmen erlebten im vergangenen Jahr Serviceausfälle aufgrund von Zertifikatsproblemen, und 37.5 % konnten einen Ausfall konkret auf ein abgelaufenes Zertifikat zurückführen., laut DigiCert Vertrauens-PulsumfrageVeröffentlicht am 2. Juli 2025.
• Die maximale Gültigkeitsdauer des öffentlichen TLS wird schrittweise auf 200 Tage im März 2026, 100 Tage im März 2027 und 47 Tage im März 2029 reduziert., bestätigt durch die Abstimmung SC-081v3 des CA/Browser Forums und Sectigos Analyse vom 14. April 2025 des gleichen Zeitplans.
• Schätzung des Wachstums des Zertifikatsbestands: Wenn die Nutzung von Agenten der von Gartner prognostizierten Entwicklung folgt und bis Ende 2026 40 % der Unternehmensanwendungen erreichen wird, und selbst ein Bruchteil dieser Agenten über eine eigene, auf X.509 basierende Identität mit einem 47-tägigen Erneuerungszyklus verfügt, könnte ein mittelständisches Unternehmen, das heute einige tausend Zertifikate verwaltet, innerhalb weniger Jahre einen Anstieg seines jährlichen Zertifikatsgeschäfts um eine Größenordnung erleben – und zwar nicht aufgrund des Wachstums von TLS-Lösungen für Endbenutzer, sondern allein aufgrund der Ausstellung von Agentenidentitäten.
• Keine dieser Zahlen beschreibt KI-Agenten im Speziellen, aber zusammen beschreiben sie das Umfeld, in dem die Identität von Agenten entsteht: eine Disziplin des Zertifikatslebenszyklus, die bereits unter immer kürzeren Gültigkeitsdauern leidet und nun eine neue und viel größere Population nicht-menschlicher Identitäten aufnehmen muss.

Wo die Agentensteuerung versagt

Um die Maschinenidentität für Agenten zu korrigieren, ist es hilfreich, die spezifischen Stellen zu kennen, an denen Probleme häufig auftreten. Einige wenige Fehlermuster tauchen immer wieder auf.

Geliehene und geteilte Anmeldeinformationen

Da es oft keine saubere Möglichkeit gibt, einem Agenten eine eigene Identität zuzuweisen, wählen Teams den Weg des geringsten Widerstands und übergeben ihm die Anmeldeinformationen eines Menschen oder ein gemeinsames Zugriffstoken. Der Agent agiert dann, als wäre er diese Person, erbt deren Berechtigungen, aber keine Verantwortung. In diesem Moment ist Ihr Prüfprotokoll fehlerhaft: Die Protokolle zeigen an, dass ein Mensch etwas getan hat, was tatsächlich ein autonomer Prozess ausgeführt hat, und jede nachträgliche Untersuchung basiert auf einer falschen Annahme.

Kein Besitzer, kein Lebenszyklus

Menschliche Identitäten haben einen natürlichen Lebenszyklus, da sie an eine reale Person und etablierte Identitätsprozesse gebunden sind: Zugriff wird bei Bedarf gewährt, Rollenänderungen werden überprüft, und der Zugriff wird entzogen, sobald die Person ihn nicht mehr benötigt. Nicht-menschliche Identitäten besitzen keinen solchen Anker.

Sie werden von Entwicklern, Automatisierung oder anderen Akteuren erstellt und überdauern in der Regel das Projekt, das sie ursprünglich rechtfertigte. Ohne einen Verantwortlichen und einen definierten Lebenszyklus sammeln sich Agentenidentitäten unbemerkt an, behalten ihre Zugriffsrechte unbegrenzt und werden zu verwaisten Anmeldeinformationen, an die sich niemand mehr erinnert, die Angreifer aber gerne finden.

Übermäßige Privilegien und schleichende Privilegienausweitung

Agenten werden häufig übermäßig mit Berechtigungen ausgestattet, da diese ihnen ermöglichen, Probleme sofort zu lösen. Einem Agenten freie Hand zu lassen, den besten Lösungsweg selbst zu finden, bedeutet faktisch, einen Insider zu schaffen, der durch eine einzige bösartige Eingabe gesteuert werden kann. In der Praxis verfügen die meisten Maschinenidentitäten über mehr Privilegien als nötig, und in agentenbasierten Systemen verstärkt sich dieser Überschuss, da Agenten Tools miteinander verknüpfen und so ihren Handlungsspielraum unbemerkt erweitern.

Zerbrochene Delegationsketten

Moderne Agenten-Workflows umfassen selten nur einen einzelnen Akteur. Ein übergeordneter Agent delegiert an einen Unteragenten, der wiederum an einen weiteren delegiert. Jeder dieser Unteragenten handelt potenziell im Auftrag einer Person, die den gesamten Prozess initiiert hat. Wenn etwas schiefgeht, muss diese Delegationskette bis zum ursprünglichen Auftraggeber zurückverfolgt werden. Standardmäßige Token-Mechanismen waren nie dafür ausgelegt, diese Kette nachzuverfolgen, sodass die Verantwortlichkeit irgendwo in der Mitte der Kette verloren geht. Wenn nicht geklärt werden kann, wer diesen Agenten mit welcher Befugnis und für welche Aufgabe beauftragt hat, existiert praktisch keine Governance.

Entscheidungstabelle: Zuordnung von Governance-Lücken der Agenten zur richtigen Antwort

Anhand dieser Checkliste können Sie eine häufig auftretende Lücke in der Agentenidentität der empfohlenen Maßnahme, dem zuständigen operativen Verantwortlichen und dem zu erwartenden Ergebnis zuordnen.

Luftüberwachung	Software Empfehlungen	Betriebsinhaber	Erwartetes Ergebnis
Agent, der die geliehenen Anmeldeinformationen eines Menschen verwendet	Weisen Sie dem Agenten eine eigene SPIFFE/X.509-basierte Identität zu.	Plattform-/DevSecOps-Team	Handlungen, die dem tatsächlichen Akteur und nicht einem Stellvertreter zuzurechnen sind.
Agentenidentität ohne zugewiesenen Eigentümer	Bei der Bereitstellung müssen ein Eigentümer und ein definierter Lebenszyklus festgelegt werden.	PKI-Team	Es sind keine verwaisten Agentenzugangsdaten mehr vorhanden, die das Projekt überdauert haben.
Agent mit umfassenden Zugriffsrechten überversorgt	Berechtigungen auf bestimmte Ressourcen und Aufgaben beschränken; Zero Trust anwenden	Sicherheits Team	Eine kompromittierte Eingabeaufforderung bleibt ein einzelner Fehler, keine Systemverletzung.
Multiagenten-Delegationskette	Die nachweisbare Delegationslinie muss bis zum menschlichen Auftraggeber zurückverfolgt werden.	Sicherheitsteam mit Compliance-Freigabe	Jede Aktion lässt sich zurückverfolgen bis zu demjenigen, der sie autorisiert hat, und zu den Gründen dafür.
Die wachsende Zahl der Agenten übersteigt die manuelle Ausstellung.	Automatisierte Zertifikatsausstellung, -rotation und -widerrufung	Plattform-/DevSecOps-Team	Der Identitätslebenszyklus hält mit der Agentenausbreitung Schritt, ohne dass manuelle Engpässe entstehen.
Prüfung oder aufsichtsrechtliche Untersuchung der Handlungen von Agenten	Kontinuierliche, identitätsaufgelöste Überwachung und Protokollierung gewährleisten.	Compliance-Team	Prüfbare Nachweise sind bereits vor der Anforderung durch die Aufsichtsbehörde verfügbar.

Aufbau von Governance auf einer maschinellen Identitätsgrundlage

Die gute Nachricht ist: All dies erfordert keine Neuerfindung der Sicherheit. Die Identitätsdisziplin, die den menschlichen Zugriff und die Kommunikation zwischen Maschinen in den letzten zwei Jahrzehnten sicherer gemacht hat, lässt sich problemlos auf Agenten übertragen, sobald man sie als gleichwertige Identitäten behandelt. Einige wenige Prioritäten sind dabei besonders wichtig.

Entdecken Sie die Agenten, von denen Sie nichts wussten.

Bevor man einen Agenten steuern kann, muss man wissen, dass er existiert – und das ist schwieriger als gedacht. Agenten werden in SaaS-Plattformen, Cloud-Diensten, Entwicklertools und Programmierassistenten eingerichtet, oft ohne dass die Sicherheitsvorkehrungen eingebunden werden. Das ist das Problem der Schatten-KI: eine Vielzahl unkontrollierter Agenten, die unbemerkt Zugriffsrechte anhäufen, während niemand eine Liste führt.

Der erste praktische Schritt hin zu einer effektiven Governance ist daher die Zertifikatsermittlung . Dazu gehört der Aufbau und die kontinuierliche Aktualisierung eines Verzeichnisses aller Agenten in Ihrer Umgebung, einschließlich der risikorelevanten Details wie Eigentümer, verwendete Anmeldeinformationen, genutzte Modelle und Tools sowie Zugriffsrechte. Das Prinzip ist einfach: Was man nicht sieht, kann man weder einschränken, überwachen noch widerrufen. Daher ist Transparenz oberstes Gebot.

Jedem Agenten eine eigene, überprüfbare Identität geben

Der wichtigste Schritt besteht darin, Agenten nicht länger fremde Identitäten zuweisen zu lassen, sondern ihnen eigene zuzuweisen. Die Identität eines Agenten sollte kryptografisch verifizierbar sein, an die jeweilige Arbeitslast und den Ausführungsort gebunden und kurzlebig sein, anstatt als langfristiges Geheimnis in einer Konfigurationsdatei gespeichert zu werden. Genau dieses Problem wurde mit dem SPIFFE-Standard und seiner SPIRE-Implementierung gelöst. Es ist wichtig zu verstehen, was ein SPIFFE-Identitätsdokument intern tatsächlich ist: In den meisten Implementierungen handelt es sich um ein kurzlebiges X.509-Zertifikat.

Google Clouds eigenes Agentenidentitätsmodell folgt demselben Muster: Zugriffstoken werden an die eindeutigen X.509-Zertifikate eines Agenten gebunden, wodurch die Wiederverwendung eines gestohlenen Tokens deutlich erschwert wird. Anders ausgedrückt: Die Grundlage für eine vertrauenswürdige Agentenidentität bildet dieselbe Public-Key-Infrastruktur, die seit jeher auch die Vertrauenswürdigkeit von Maschinen gewährleistet. Jedes von dieser Infrastruktur ausgestellte Zertifikat unterliegt nun derselben 47-tägigen Gültigkeitsdauer wie alle anderen Zertifikate.

Den gesamten Lebenszyklus verwalten

Eine Identität, die nicht deaktiviert werden kann, stellt ein potenzielles Risiko dar. Agentenidentitäten benötigen dieselben Lebenszykluskontrollen wie alle sensiblen Zugangsdaten: Bereitstellung, die festhält, wem die Identität gehört und warum sie existiert; automatische Rotation, damit Zugangsdaten nie lange statisch bleiben; und zuverlässiger Widerruf, sobald ein Agent deaktiviert wird oder sich unzulässig verhält.

Da diese Zugangsdaten nur kurzlebig sind und in großer Zahl existieren, ist eine manuelle Verwaltung schlichtweg keine Option. Automatisierung ist hier keine Annehmlichkeit, sondern eine Grundvoraussetzung – nur so können Bereitstellung, Rotation und Widerruf mit dem Wachstum der Agentenpopulation Schritt halten.

Prinzip der minimalen Berechtigungen und Zero Trust durchsetzen

Jeder Agent sollte nur die kleinstmöglichen Berechtigungen erhalten, die er für seine Aufgaben benötigt, beschränkt auf spezifische Ressourcen und idealerweise auf bestimmte Aufgaben. Die Anwendung von Zero-Trust -Prinzipien stellt sicher, dass keine Anfrage einfach so durchgeht, nur weil sie von einem bereits authentifizierten Agenten stammt; jede Aktion wird zum Zeitpunkt ihrer Ausführung anhand von Identität, Gültigkeitsbereich und Richtlinien geprüft.

Ziel ist es, von der Frage, wer im letzten Quartal Zugriff hatte, zur kontinuierlichen Beantwortung der Frage überzugehen, was dieser Agent aktuell tun darf und warum. Wenn Identität als letzte Verteidigungslinie betrachtet wird, bleibt ein einzelner kompromittierter Zugriffspunkt ein einzelner Fehler und führt nicht zu einer systemweiten Sicherheitslücke.

In der Praxis übernimmt das Prinzip der minimalen Berechtigungen für Agenten einige Mechanismen des Privileged Access Management. Die Just-in-Time-Bereitstellung gewährt erhöhte Zugriffsrechte nur für den Moment, in dem sie tatsächlich benötigt werden, und entzieht sie anschließend wieder, anstatt dauerhafte Berechtigungen zu belassen. Besonders sensible Aktionen können durch eine menschliche Genehmigung oder eine zusätzliche Authentifizierung geschützt werden. Zudem ermöglicht es, einen Agenten bei anomalem Verhalten sofort zu sperren oder abzuschalten, sodass ein kompromittierter Agent gestoppt werden kann, bevor er dauerhaften Schaden anrichten kann.

Kontinuierliche Überwachung und Gewährleistung der Revisionsfähigkeit der Lieferkette

Governance ist keine einmalige Konfiguration, sondern eine kontinuierliche Überwachung. Die Echtzeitüberwachung der Agentenaktivitäten ermöglicht es, subtile Signale frühzeitig zu erkennen, bevor sie sich verschärfen. Bei Agenten sind die relevanten Signale recht spezifisch: der Zugriff auf Ressourcen außerhalb seines normalen Aufgabenbereichs, der Versuch, die eigenen Berechtigungen zu erweitern, oder eine Aktion, die nicht der eigentlich auszuführenden Aufgabe entspricht.

Genauso wichtig ist, dass jede Aktion einer eindeutigen Identität zugeordnet werden kann und, bei Workflows mit mehreren Agenten, die vollständige Delegierungskette bis hin zu einem menschlichen Benutzer nachvollziehbar ist. Diese Nachvollziehbarkeit macht aus einer Menge Protokolldateien etwas, das Sie gegenüber Aufsichtsbehörden, Wirtschaftsprüfern oder Incident-Respondern tatsächlich erklären können.

Achten Sie auf die Standards, nicht nur auf den Hype.

Die Governance-Landschaft holt schnell auf. Neben den OWASP Top 10 für agentenbasierte Anwendungen startete das NIST im Februar 2026 seine KI-Agenten-Standards-Initiative, und sein Nationales Kompetenzzentrum für Cybersicherheit veröffentlichte ein Konzeptpapier zur Identität und Autorisierung von KI-Agenten – ein klares Signal dafür, dass die Agentenidentität zu einem formalen Standardisierungsthema wird.

Die Regulierung verläuft parallel: Die EU-KI-Gesetzgebung enthält Verpflichtungen für Systeme mit hohem Risiko, und mehrere nationale KI-Gesetze treten bis 2026 in Kraft. Gleichzeitig bieten Rahmenwerke wie das NIST AI Risk Management Framework Organisationen eine strukturierte Möglichkeit, die Kontrolle ihrer KI-Agenten zu dokumentieren. Die Schlussfolgerung ist einfach: Eine auf verifizierbarer Maschinenidentität basierende Agenten-Governance ist nicht mehr nur eine gute Sicherheitsmaßnahme, sondern der Standard, den Prüfer und Aufsichtsbehörden von Ihnen erwarten.

Eigentümer- und Aktionsmatrix des Teams

Team	Verantwortung	Schlüsselaktion
PKI-Team	Besitzt die Berechtigung zur Ausstellung von Zertifikaten für Agentenidentitäten	Modell erwartetes agentenbasiertes Zertifikatsvolumen im Vergleich zur aktuellen CA- und CLM-Kapazität
Sicherheits Team	Gewährleistet die Einhaltung der Mindestprivilegien, die Integrität der Qualifikationsnachweise und die Integrität der Delegation.	Fremde Zugangsdaten abschaffen und überprüfbare Delegationsketten vorschreiben
Plattform-/DevSecOps-Team	Besitzt den automatisierten Agentenidentitätslebenszyklus	Binden Sie SPIFFE/SPIRE oder eine gleichwertige Plattform in die Agentenbereitstellungspipelines ein.
Compliance-Team	Besitzt die Prüfnachweise für die Handlungen der Agenten	Bestätigen Sie, dass jede Agentenaktion zu einer Identität und einer Delegierungskette aufgelöst wird.

Was macht man als nächstes

• PKI-Teams: Das prognostizierte Ausstellungsvolumen von Zertifikaten aufgrund des Wachstums der Agentenidentitäten vor dem 100-tägigen TLS-Gültigkeitsstadium im März 2027 verstärkt die Belastung zusätzlich.
• Sicherheitsteams: Prüfen Sie, ob ein Agent im Produktivbetrieb noch geliehene menschliche Anmeldeinformationen oder ein gemeinsam genutztes Token verwendet.
• Plattformteams: Pilotprojekt zur automatisierten, zertifikatsgestützten Identitätsausstellung für Ihren Agenten mit den höchsten Berechtigungen in diesem Quartal.
• Compliance-Teams: Prüfen Sie, ob Ihr Audit-Framework Agentenidentitäts- und Delegierungsprotokolle bereits als Nachweis akzeptiert, oder weisen Sie jetzt auf die bestehende Lücke hin.

Wie könnte eine Verschlüsselungsberatung helfen?

Wenn die Identität von Agenten letztendlich auf Zertifikaten und PKI basiert, wird die Verwaltung dieser Identitätsebene zum Fundament Ihrer gesamten Agenten-Governance-Strategie. Genau hier setzt der CertSecure Manager von Encryption Consulting an. Der CertSecure Manager ist eine herstellerneutrale Lösung für das Zertifikatslebenszyklusmanagement, die Erkennung, Automatisierung, Registrierung, Richtliniendurchsetzung und Integrationen in Ihrer gesamten Umgebung zentralisiert.

Es beugt Ausfällen durch automatisierte Verlängerungen vor, stärkt die Compliance, optimiert den IT-Betrieb und vereinheitlicht die Verwaltung öffentlicher und privater Zertifizierungsstellen über eine einzige, automatisierte und skalierbare Plattform.

Da KI-Agenten die Anzahl der zu berücksichtigenden Maschinenidentitäten vervielfachen, bieten die automatisierte Erkennung, die robuste rollenbasierte Zugriffskontrolle und die kontinuierliche Transparenz der Zertifikatsvorgänge von CertSecure Manager die Lebenszyklus-Governance und die Durchsetzung des Least-Privilege-Prinzips, die agentenbasierte Umgebungen erfordern, sodass die kryptografischen Identitäten, auf die Ihre Agenten angewiesen sind, aktuell, begrenzt und nachvollziehbar bleiben, anstatt sich unkontrolliert auszubreiten.

Um den Schutz weiter auszubauen, erweitert CBOM Secure die Analyse über Zertifikate hinaus auf Ihre gesamte kryptografische Landschaft aus Algorithmen, Schlüsseln und Protokollen. So entsteht die kryptografische Stückliste, die Compliance unterstützt und Sie auf den Übergang nach der Quantencomputer-Ära vorbereitet, der mit diesem Wachstum an Identitäten einhergeht. Unser Leitfaden „CBOM: Vom Inventar zur Analyse “ zeigt Ihnen, wie Sie dieses Inventar in ein kontinuierliches Programm für kryptografische Agilität umwandeln. Da die heute getroffenen Entscheidungen zur Agentenidentität auch nach der Quantencomputer-Ära relevant sind, unterstützen Sie unser PQC Center of Excellence und unser 9-phasiger PQC-Readiness -Plan bei der Planung der kryptografischen Agilität für die Zertifikatsinfrastruktur, auf die Ihre Agenten angewiesen sein werden.

Weiterführende Lektüre von Encryption Consulting

• Der richtige Zeitpunkt, um eine CSR-Meldung zu erstellen deckt den Zertifikatsanforderungsschritt ab, von dem jede SPIFFE/X.509-basierte Agentenidentität abhängt.
• Automatisierung der Zertifikatsverwaltung in Azure Key Vault umfasst die Orchestrierungsschicht, die für die Verarbeitung agentengesteuerter Zertifikatsvolumina in großem Umfang erforderlich ist.
• Auswahl eines Zertifizierungsregistrierungsverfahrens: ACME vs. EST vs. SCEP vs. CMP umfasst die automatisierten Registrierungsprotokolle, die die Ausstellung von Zertifikaten an Agentenpopulationen skalieren.
• Leitfaden zur Migration der Post-Quanten-Kryptographie (9 Phasen) legt den Fahrplan für die Agilität von Kryptowährungen dar, der dem Wachstum der maschinellen Identität folgt.

Fazit

KI-Agenten sind wahrhaft transformativ, und die Produktivitätssteigerungen sind so real, dass selbst größte Vorsicht ihre Verbreitung nicht aufhalten wird. Umso wichtiger ist es, sich über die Anforderungen an ihre Steuerung im Klaren zu sein. Die Versuchung besteht darin, Steuerung als Problem besserer Hinweise und intelligenterer Schutzmechanismen auf Modellebene zu betrachten. So nützlich diese auch sind, sie stehen über einer grundlegenderen Frage: Verfügt jeder Agent über eine verifizierbare Identität, einen angemessenen Zugriffsbereich und eine nachvollziehbare Dokumentation all seiner Aktionen?

Beantworten Sie diese Frage gut, und Ihr restliches Governance-Programm hat eine solide Grundlage. Ignorieren Sie sie hingegen, weil die Agenten im Einsatz sind und die Frist naht, schaffen Sie im Stillen die größte unkontrollierte Angriffsfläche, die Ihr Unternehmen je hatte – eine überprivilegierte, herrenlose und nie rotierte Identität nach der anderen.

Agenten als vollwertige Identitäten zu behandeln, ihr Vertrauen in einer gut verwalteten PKI zu verankern, ihren Lebenszyklus zu automatisieren und sie dem Prinzip der minimalen Berechtigungen und kontinuierlicher Überwachung zu unterwerfen, ist kein einmaliges Projekt, sondern eine fortlaufende Verpflichtung. Genau das entscheidet darüber, ob wir die Versprechen agentenbasierter KI einlösen oder von ihr selbst zunichtegemacht werden. In einer Umgebung, in der nicht-menschliche Identitäten die menschlichen bereits um ein Vielfaches übertreffen, ist die Identität von Maschinen kein nebensächliches Detail der KI-Governance. Sie ist das Fundament, auf dem alles andere aufbaut, und der Ausgangspunkt von allem.

Diese Richtlinien werden alle sechs Monate für dauerhaft gültige Erklärungen wie diese überprüft und sofort aktualisiert, sobald das CA/Browser Forum, das NIST oder eine große KI-Plattform die Anforderungen an diese Prozesse ändert.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus „Die Steuerung von KI-Agenten beginnt mit der Maschinenidentität“?

KI-Agenten verhalten sich wie privilegierte Workloads, nicht wie Chatbots. Daher muss effektive Governance auf der Identitätsebene und nicht auf der Eingabeaufforderungsebene ansetzen. Jedem Agenten eine eigene, verifizierbare, zertifikatsbasierte Identität mit minimalen Berechtigungen, automatisiertem Lebenszyklusmanagement und einer nachvollziehbaren Delegationskette zuzuweisen, macht Governance nicht nur wünschenswert, sondern auch durchsetzbar.

Warum ist das für das Zertifikatslebenszyklusmanagement wichtig?

Die meisten Agentenidentitäts-Frameworks, darunter SPIFFE/SPIRE und das Agentenidentitätsmodell von Google Cloud, basieren auf kurzlebigen X.509-Zertifikaten. Da die Nutzung von Agenten bis Ende 2026 voraussichtlich 40 % aller Unternehmensanwendungen erreichen wird, steigt der Aufwand für die Ausstellung und Erneuerung von Zertifikaten rasant an – und das genau zu dem Zeitpunkt, an dem das CA/Browser Forum die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate bis 2029 auf 47 Tage verkürzt.

Welche Teams sind für die Umsetzung dieser Richtlinien verantwortlich?

PKI-Teams sind für die Zertifikatsausstellung von Agentenidentitäten zuständig; Sicherheitsteams für das Prinzip der minimalen Berechtigungen, die Integrität der Anmeldeinformationen und die Delegierungsintegrität; Plattform- und DevSecOps-Teams für die Automatisierung des Agentenidentitätslebenszyklus; und Compliance-Teams für die Bestätigung, dass jede Agentenaktion zu einer Identität und Delegierungskette führt. Die obige Verantwortlichkeits-/Aktionsmatrix zeigt die Aufschlüsselung nach Teams.

Welche Risiken erhöhen sich, wenn die Agentenidentität manuell verwaltet wird?

Die manuelle Verwaltung von Agentenidentitäten führt zu geliehenen oder gemeinsam genutzten Anmeldeinformationen, die die Verantwortlichkeit untergraben, zu verwaisten Agentenidentitäten ohne Eigentümer oder Lebenszyklus, zu übermäßigen Berechtigungen, die durch eine einzige kompromittierte Eingabeaufforderung ausgenutzt werden können, und zu unterbrochenen Delegierungsketten, die es unmöglich machen, eine Aktion dem autorisierten Benutzer zuzuordnen. Die Trust Pulse Survey von DigiCert ergab, dass 37.5 % der zertifikatsbezogenen Ausfälle direkt auf ein abgelaufenes Zertifikat zurückzuführen waren – ein Risiko, das sich mit zunehmendem Volumen agentenbasierter Zertifikate verstärkt.

Wie reduziert Automatisierung das Risiko von Agentenidentitäts- und Zertifikatsausfällen?

Die Automatisierung der Ausstellung, Rotation und des Widerrufs von zertifikatsbasierten Agentenidentitäten mithilfe von SPIFFE/SPIRE oder einer vergleichbaren Zertifikatslebenszyklusplattform eliminiert den manuellen Schritt, der am ehesten dazu führt, dass Anmeldeinformationen veralten oder Agentenzertifikate unbemerkt ablaufen. Da Agentenidentitäten nur kurzlebig sind und in großer Zahl existieren, sorgt die Automatisierung für eine stets aktuelle Erneuerung und verhindert Ausfälle.

Welche Kennzahlen sollten Teams nach der Implementierung verfolgen?

Erfassen Sie den Anteil der Agentenidentitäten mit dokumentiertem Inhaber, die Anzahl der Agenten, die noch geliehene oder gemeinsam genutzte Anmeldeinformationen verwenden, die Anzahl der agentenbasierten Zertifikate unter automatisierter Lebenszyklusverwaltung, Delegationsketten, die vollständig zu einem menschlichen Prinzipal zurückgeführt werden können, sowie zertifikatsbezogene Vorfälle mit Agentenidentität. Berichten Sie diese Daten vierteljährlich, um die zunehmende Nutzung von Agenten zu unterstützen.

Wie hängt das mit der 47-tägigen TLS-Zertifikatsbereitschaft zusammen?

Der Zeitplan des CA/Browser-Forums verkürzt die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 200 Tage am 15. März 2026, 100 Tage am 15. März 2027 und 47 Tage am 15. März 2029. Da die meisten Agentenidentitätssysteme auf X.509-Zertifikaten basieren, gilt der gleiche 47-tägige Erneuerungszyklus wie für Web-TLS auch für jede zertifikatbasierte Agentenidentität. Dadurch wird die automatisierte Ausstellung und Erneuerung zu einer Grundvoraussetzung für die Agentenverwaltung im großen Maßstab und nicht nur zu einer praktischen Funktion im Zertifikatsmanagement.

Wie sollte dies in Multi-Cloud- oder Hybrid-PKI-Umgebungen gehandhabt werden?

Standardisieren Sie die Agentenidentitätsvergabe auf einer CA-unabhängigen Zertifikatslebenszyklusplattform wie CertSecure Manager. So erhalten Agenten, die in verschiedenen Clouds, On-Premises-Infrastrukturen und hybriden PKI-Umgebungen laufen, ihre Identität durch dieselben Richtlinien, Algorithmen und denselben Audit-Trail. Dadurch entfällt die separate Entwicklung der Agentenidentitätsverwaltung für jeden Cloud-Anbieter oder jede interne CA.