Die Identitätskrise am Rande der agentenbasierten KI

Der globale Markt für agentenbasierte KI erreichte im Jahr 2025 ein Volumen von 7.6 Milliarden US-Dollar und wird Prognosen zufolge bis 2034 auf über 196.6 Milliarden US-Dollar anwachsen. Dennoch verfügen die meisten Implementierungen über keine hardwarebasierte Agentenidentität.

Herkömmliche Software-Authentifizierungsmethoden wie API-Schlüssel, OAuth-Token, mTLS-Zertifikate und Dienstidentitäten dienen der Authentifizierung von Software oder Workloads. Sie belegen, dass ein Prozess die korrekten Anmeldeinformationen vorgelegt hat. Sie beweisen jedoch nicht, dass die zugrundeliegende Hardware vertrauenswürdig ist, die Firmware nicht verändert wurde oder der Agent auf der erwarteten Plattform ausgeführt wird.

Dies ist die zentrale Sicherheitsherausforderung für agentenbasierte KI.

Ein Zertifikat kann bestätigen, dass eine Workload über den korrekten privaten Schlüssel verfügt. Es kann jedoch allein nicht Aufschluss darüber geben, ob der Rechner, auf dem diese Workload ausgeführt wird, kompromittiert wurde. Vereinfacht gesagt, ist Softwareidentität wie ein Ausweis. Hardwarebasierte Identität ähnelt eher biometrischen Daten, da sie im Gerät selbst verankert ist.

Hardwarebasierte Identität schafft eine stärkere Vertrauensgrundlage, indem sie die Identität des Agenten mit einer hardwarebasierten Vertrauensbasis verknüpft. Anstatt nur zu fragen: „Ist dies die richtige Software?“, können Unternehmen fragen: „Läuft dies auf der richtigen Hardware mit der richtigen Firmware in einem verifizierten Zustand?“ Diese Unterscheidung gewinnt zunehmend an Bedeutung, wenn agentenbasierte KI in Unternehmens- und regulierte Umgebungen Einzug hält.

Die Grundlage für dieses Vertrauensmodell existiert bereits durch Standards wie DICE von TCG, SPDM von DMTF und CMS mit X.509-Zertifikaten . Gemeinsam können diese Standards dazu beitragen, eine Identitätskette zwischen Hardware und Agent aufzubauen, die nachweist, wo ein Agent ausgeführt wird, in welchem ​​Zustand sich die Plattform befindet und ob dieser Plattform vertraut werden kann.

Was genau bedeutet „Hardwareidentität“?

Hardware-Identität ist das Prinzip, dass die Identität eines Geräts in etwas verankert sein sollte, das nicht ohne physische Zerstörung aus der Hardware extrahiert werden kann: ein kryptografischer Schlüssel, der während der Herstellung eingebettet wird, nur für die Firmware zugänglich ist, die direkt auf diesem Silizium läuft, und der wahrscheinlich mit dem spezifischen hergestellten Gerät verknüpft ist.

Die etablierteste Implementierung dieses Prinzips ist das Trusted Platform Module (TPM), das seit Jahrzehnten in Unternehmensservern und Laptops zum Einsatz kommt. TPMs wurden jedoch für eine Welt relativ statischer Maschinen und vergleichsweise einfacher Vertrauenszusicherungen entwickelt. Die Herausforderung von KI-Agenten, die auf speziell entwickelten KI-Beschleunigern, Edge-Inferenzhardware, Cloud-basierten Siliziumchips und GPU-Clustern laufen, erfordert einen flexibleren, modularen Ansatz für hardwarebasierte Identität.

Dieser Ansatz basiert auf drei ineinandergreifenden Standards. Jeder einzelne wird in dieser Reihe in einem eigenen Blogbeitrag ausführlich behandelt, aber hier ist eine kurze Beschreibung der jeweiligen Funktion:

DICE: Device Identifier Composition Engine (TCG)

DICE, entwickelt von der Trusted Computing Group, bildet die Grundlage: einen Mechanismus zur Ableitung einer eindeutigen, hardwaregebundenen kryptografischen Identität aus einem bei der Herstellung eingebetteten Geheimnis. Jede darauf aufbauende Firmware-Schicht wird gemessen und in die Identitätsableitung einbezogen. Die auf der Anwendungsschicht resultierende Identität spiegelt daher nicht nur die Hardware selbst wider, sondern auch den spezifischen Firmware-Zustand. Ein System mit modifizierter Firmware besitzt eine andere Identität als dasselbe System mit unveränderter Firmware – und dieser Unterschied ist kryptografisch nachweisbar.

SPDM: Sicherheitsprotokoll und Datenmodell (DMTF)

SPDM ist das Kommunikationsprotokoll, mit dem eine Komponente ihre Hardwareidentität gegenüber einer anderen nachweisen kann. Während DICE die Identität erzeugt, dient SPDM als Mechanismus, um diese Identität während einer Live-Interaktion zu präsentieren und zu verifizieren. Ein KI-Orchestrator, der SPDM verwendet, kann eine Hardwarekomponente – beispielsweise eine GPU, eine Netzwerkkarte oder eine sichere Enklave – überprüfen und erhält eine kryptografisch signierte Bestätigung der Identität und des Messzustands dieser Komponente, bevor er ihr Arbeitslasten zuweist.

CMS und X.509: Die PKI-Hülle

Die kryptografische Nachrichtensyntax (CMS, RFC 5652) und X.509-Zertifikatsprofile bilden die Schnittstelle zwischen Hardwareidentität und dem umfassenderen PKI-Ökosystem . DICE erzeugt eine hardwarebasierte Zertifikatskette. SPDM bestätigt die Integrität der Hardware zur Laufzeit. CMS stellt den Rahmen für die Signierung einzelner Agentenaktionen, Transaktionen oder Nachrichten bereit und verknüpft diese mit der hardwarebasierten Identität des jeweiligen Agenten. Zusammen bilden diese drei Standards eine vollständige Vertrauenskette vom Silizium bis zur signierten Aktion.

Hardwarebasierte Identität für KI-Agenten

DICE, SPDM, IEEE 802.1AR-2018 (Secure Device Identity) und CMS sind heute in Unternehmenshardware etabliert und weit verbreitet. KI-Beschleuniger führender Hardwarehersteller implementieren bereits DICE. Unternehmensserver unterstützen SPDM. Die Zertifikate, die diese Attestierungen in eine nutzbare PKI integrieren , entsprechen bereits den etablierten X.509- und IEEE 802.1AR-Profilen.

Die Herausforderung besteht darin, dass bisher niemand die operative Infrastruktur entwickelt hat, die diese Hardwarestandards mit dem Bereitstellungslebenszyklus von KI-Agenten verbindet. Zertifikatsausstellungsplattformen wurden für Server, Benutzer und Geräte entwickelt. Sie waren nicht dafür ausgelegt:

• Registrieren Sie die Hardwareidentität eines KI-Beschleunigers mithilfe von DICE-abgeleiteten Zertifikatsketten
• Überprüfen Sie die Firmware-Integrität über SPDM, bevor Sie ein Betriebsagentenzertifikat ausstellen.
• Verwalten Zertifikatslebenszyklus für Agentenidentitäten, die mehrmals täglich erstellt und wieder abgebaut werden können.
• Verknüpfen Sie signierte Agentenaktionen über CMS mit der hardwarebasierten Kette, die die Herkunft des Agenten beweist.

Die operative Lücke zwischen den bestehenden Standards und der Infrastruktur, die sie für agentenbasierte KI implementiert, birgt genau das Risiko. Unsere Zusammenarbeit mit einem Fortune-100-Unternehmen im Bereich SPDM-konformer PKI für Gerätezertifikate, basierend auf DICE X.509 und IEEE 802.1AR, repräsentiert die Art von realer Implementierung, die die meisten Anbieter noch als zukünftiges Ziel ihrer Roadmap betrachten. Die Standards existieren, die Hardware unterstützt sie, und die Implementierungsarbeiten für Unternehmen, die sie fordern, laufen bereits.

Fünf strukturelle Unterschiede zwischen Hardware-PKI

Im Folgenden werden die 5 PKI-Implikationen aufgeführt, die sich strukturell unterscheiden und bei der Hardwarefertigung berücksichtigt werden müssen.

1. Der private Schlüssel ist physisch an Silizium gebunden.

In einer Server- PKI kann ein privater Schlüssel exportiert, gesichert, migriert oder planmäßig rotiert werden. In einer Hardware-Identitäts-PKI wird der private Schlüssel vom UDS (Unique Device Secret) abgeleitet, einem Wert, der gemäß der TCG-DICE-Architektur bei der Herstellung physisch in den Chip eingebettet wird. Er kann weder exportiert noch gesichert werden. Eine Kompromittierung des Schlüssels führt zur Außerbetriebnahme des Geräts, nicht zum Austausch des Zertifikats.

PKI-Implikationen:

• Kein Schlüsselhinterlegungsmodell für hardwaregebundene Schlüssel
• Die Schlüsselrotation erfordert den Austausch des physischen Geräts.
• Ihre Zertifizierungsstelle kann den Schlüssel nicht allein über einen Standard-CSR-Workflow verifizieren – die DICE-Ableitungskette liefert den Bindungsnachweis.

2. Die Gültigkeitsdauer des Zertifikats muss sich an der Lebensdauer des Geräts orientieren, nicht an Konformitätszeiträumen.

Das CA/Browser Forum hat eine maximale Gültigkeitsdauer von 47 Tagen für TLS-Zertifikate vorgeschrieben (Abstimmung SC-081, gültig ab März 2026). Ein heute auf den Markt kommender KI-Beschleuniger könnte sich noch im Jahr 2045 in der Produktion befinden. Die Spezifikation der TCG DICE-Zertifikatprofile regelt dies direkt:

Geräte ohne sichere Uhr können den „Nicht nach“-Teil der Gültigkeitsdauer des Zertifikats auf den in X.509 definierten Wert „GeneralizedTime“ von 99991231235959Z setzen . Dieser Wert gibt an, dass das Zertifikat kein definiertes Ablaufdatum hat.

Dies ist weder optional noch eine Umgehungslösung. Es handelt sich um das Standardverhalten für Hardwarezertifikate auf Geräten ohne Echtzeituhr. Ihre Zertifizierungsstelleninfrastruktur muss so konfiguriert sein, dass sie Zertifikate mit diesem Wert ausstellt. Die meisten CA-Plattformen für Unternehmen erzwingen standardmäßig maximale Gültigkeitsdauerbeschränkungen; Sie benötigen daher explizite Konfigurationsausnahmen für Hardwarezertifikatsprofile.

3. Zwei unterschiedliche Identitätsphasen erfordern zwei völlig getrennte PKI-Hierarchien

Die Hardwareidentität arbeitet in zwei Phasen mit unterschiedlichen Vertrauensankern:

Phase 1- Fertigungszeitidentität (IDevID)	Phase 2 – Bereitstellungszeitidentität (LDevID)
Standard: IEEE 802.1AR-2018 + TCG DICE X.509	Standard: IEEE 802.1AR-2018 + TCG DICE X.509
Ausgestellt von: Zertifizierungsstelle des Geräteherstellers	Ausgestellt von: Zertifizierungsstelle des Geräteinhabers (völlig unabhängig von der Zertifizierungsstelle des Herstellers)
Richtlinien-OID: id-tcg-kp-identityInit {id-tcg-kp 6}	Richtlinien-OID: id-tcg-kp-identityLoc {id-tcg-kp 7}
Zweck: Nachweis, dass es sich um Originalhardware dieses Herstellers handelt.	Zweck: Operative Identität innerhalb der Eigentümerumgebung
Dies ist die Geburtsurkunde des Geräts. Sie kann nach der Herstellung nicht neu ausgestellt werden.	Ausgestellt nach erfolgreicher SPDM-Attestierung der IDevID-Kette.

Diese beiden Hierarchien dürfen niemals eine gemeinsame Wurzel haben. Die Hersteller-CA hat keinerlei Autorität über die Betriebsumgebung des Eigentümers. Eine Zusammenführung dieser Hierarchien ermöglicht dem Hardwareanbieter die fortlaufende Kontrolle über die PKI-Entscheidungen einer implementierenden Organisation. Dies stellt sowohl ein Versagen des Vertrauensmodells als auch, in regulierten Branchen, ein Compliance-Problem dar.

4. Widerruf bedeutet eine physische Maßnahme, nicht die Ersetzung des Zertifikats.

Die Aufhebung einer IDevID erlaubt keine Neuausstellung mit einem neuen Schlüssel. Der Schlüssel ist hardwaregebunden. Die Aufhebung führt zur Quarantäne oder Außerbetriebnahme des Geräts. Ihre CRL- und OCSP- Infrastruktur muss diese Gegebenheit berücksichtigen.

• IDevID-CRL-Einträge sollten Gerätequarantäne-Workflows auslösen, nicht nur die Zertifikatsinvalidierung.
• Die OCSP-SLAs für Hardware-CAs müssen streng sein, d. h. ein Gerät, das seine Zertifikatskette nicht validieren kann, ist betriebsunfähig.
• Die Veröffentlichungsfrequenz der Sperrlisten (CRL) kann für Hardware-Zertifizierungsstellen länger sein als für Server-Zertifizierungsstellen (wöchentlich bis monatlich), da Schlüsselkompromittierungsereignisse selten und physikalisch begrenzt sind.

5. Die ausstellende Zertifizierungsstelle kann in der Geräte-Firmware eingebettet sein.

Die TCG DICE-Spezifikation definiert eine eingebettete Zertifizierungsstelle (Embedded Certificate Authority, ECA), eine Zertifizierungsstelle, die in der Geräte-Firmware integriert ist und Zertifikate an darüber liegende Firmware-Schichten ausgibt.

Die ECA ist eine echte Zertifizierungsstelle. Sie verfügt über ein Schlüsselpaar, das vom DICE CDI (Compound Device Identifier) ​​abgeleitet ist. Sie signiert Zertifikate. Sie muss während des Herstellungsprozesses von der Hersteller-CA zertifiziert werden. Das bedeutet:

• Die vom Hersteller ausgestellte Zertifizierungsstelle muss verfügbar und in die Produktionslinie integriert sein.
• Das ECA-Zertifikat MUSS Folgendes enthalten: keyCertSign in Key Usage, cA: TRUE in Basic Constraints with pathLengthConstraint, Policy OID id-tcg-kp-eca {id-tcg-kp 12}, und CRLDistributionPoints MÜSSEN vorhanden sein.
• Wenn Sie feststellen, dass die ECA-Zertifizierung erst nach Produktionsbeginn erforderlich ist, müssen Sie den Produktionsablaufplan überarbeiten; dies muss also von Anfang an berücksichtigt werden.

Die PKI-Hierarchie für Hardware-Identität

Hier ist die vollständige CA-Hierarchie mit den Anforderungen auf jeder Ebene dargestellt. Dies gilt für Hardwarehersteller, die die PKI des Herstellers aufbauen.

CA-Niveau	Algorithmus / HSM	Gültigkeit	Schlüsselverwendung	Fragen
Hersteller Root CA	ECDSA P-384 / FIPS 140-3 L3+ HSM, offline luftgetrennt	99991231235959Z (keine Uhr) oder definiert	Nur für Kalifornien	Hersteller Zwischen-CAs
Hersteller Zwischen CA	ECDSA P-384 / FIPS 140-3 L3 HSM, online eingeschränkt	99991231235959Z (keine Uhr) oder definiert	CA + CRLSign	IDevID-Zertifikate oder ECA-Zertifikate
ECA (On-Device, DICE)	ECDSA P-256/384 / DICE CDI-abgeleitet	Übereinstimmungen mit der Lebensdauer der IDevID	keyCertSign only (DARF NICHT cRLSign)	Attestierungszertifikate für Firmware-Schichten
IDevID Blattzertifikat	ECDSA P-256/P-384 / siliziumgebunden	99991231235959Z (keine Uhr) oder definiert	DARF NICHT keyCertSign verwenden	Endentität für Geräteidentität

TCG-Richtlinie OIDs: Jedes Zertifikat muss die richtige OID enthalten.

Die TCG-DICE-Spezifikation definiert eine Reihe von Policy-OIDs im Namespace id-tcg-kp. Jede OID kodiert, wofür ein Zertifikat autorisiert ist und wie sein Schlüssel gebunden wurde. Eine falsche OID führt dazu, dass das Zertifikat bei jedem SPDM-Prüfer und jedem 802.1AR-fähigen System nicht validiert werden kann.

OID-Name	OID-Wert	Art des Zertifikats	Der Schlüssel muss gebunden sein
id-tcg-kp-identityInit	{id-tcg-kp 6}	IDevID	Zum Zeitpunkt der Herstellung. Vom Hersteller CA zertifiziert.
id-tcg-kp-identityLoc	{id-tcg-kp 7}	LDevID	Nach der Fertigung. Zertifiziert durch den lokalen Eigentümer in Kalifornien.
id-tcg-kp-attestInit	{id-tcg-kp 8}	Bestätigung (Initial)	Zum Zeitpunkt der Herstellung. Hinweise auf die Geräte-Firmware/Konfiguration.
id-tcg-kp-attestLoc	{id-tcg-kp 9}	Bescheinigung (lokal)	Nach der Fertigung. Zertifiziert durch eine lokale Zertifizierungsstelle.
id-tcg-kp-assertInit	{id-tcg-kp 10}	Behauptung (initial)	Zum Zeitpunkt der Fertigung. Schilder beziehen sich auf die Maße.
id-tcg-kp-assertLoc	{id-tcg-kp 11}	Behauptung (lokal)	Nach der Fertigung. Zertifiziert durch eine lokale Zertifizierungsstelle.
id-tcg-kp-eca	{id-tcg-kp 12}	ACE	Fertigung oder Weiterverarbeitung. Ermächtigt die Zertifikatsausstellung durch die integrierte Zertifizierungsstelle.

Praktische Regeln für Ihre CA-Konfiguration:

• IDevID MUSS id-tcg-kp-identityInit enthalten. Es KANN auch id-tcg-kp-eca (wenn das Gerät ein ECA ist) und id-tcg-kp-attestInit (wenn es auch Attestierungssignaturen durchführt) enthalten.
• LDevID MUSS id-tcg-kp-identityLoc enthalten. Es KANN auch id-tcg-kp-eca und id-tcg-kp-attestLoc enthalten.
• ECA-Zertifikate MÜSSEN id-tcg-kp-eca enthalten. Die Erweiterung CRLDistributionPoints MUSS vorhanden sein.
• Attestierungszertifikate MÜSSEN entweder id-tcg-kp-attestInit oder id-tcg-kp-attestLoc enthalten.

Die sechs häufigsten Fehler von PKI-Hardwareherstellern

Im Folgenden werden sechs häufige Fehler aufgeführt, die Hardwareanbieter bei der Entwicklung oder Implementierung hardwarebasierter Identitäts- und Sicherheitskontrollen begehen können. Diese Punkte treffen nicht zwangsläufig auf jeden Hardwareanbieter zu und können je nach Produktarchitektur, Bereitstellungsmodell, Bedrohungslandschaft, regulatorischen Anforderungen und spezifischem Anwendungsfall variieren. Sie sollten daher als allgemeine Überlegungen und nicht als allgemeingültige Annahmen verstanden werden.

Für Gerätezertifikate werden Serverzertifikatprofile verwendet. CA/Browser Forum-Profile sind für TLS ausgelegt. Sie legen Anforderungen an den Subjektnamen, SAN-Anforderungen und Gültigkeitsdauern fest, die für Hardware-Identitäten nicht gelten. Eine mit einem CABF-Profil ausgestellte IDevID enthält kein id-tcg-kp-identityInit, hat eine kurze Gültigkeitsdauer und wird von SPDM-Prüfern, die TCG-OIDs überprüfen, abgelehnt.

Die Zertifizierungsstelle (CA) ist nicht für die Gültigkeitsdauer 99991231235959Z konfiguriert. Unternehmenszertifizierungsstellen unterliegen einer maximalen Gültigkeitsdauer. Wenn Ihr Hardware-Team eine IDevID anfordert und die CA diese aufgrund der Überschreitung der Richtliniengrenzen ablehnt, erhalten Sie entweder ein falsch konfiguriertes Zertifikat oder ein Ersatzzertifikat mit einem beliebig langen Gültigkeitsdatum, jedoch nicht mit dem in der Spezifikation vorgeschriebenen Wert.

Die Zusammenführung der Zertifizierungsstellenhierarchien von Hersteller und Eigentümer sowie die Schaffung einer einzigen PKI, die sowohl IDevID als auch LDevID von derselben Wurzel ausgibt, verleihen dem Hardwareanbieter die Kontrolle über die operative Identität der einsetzenden Organisation. Dies unterbricht das in IEEE 802.1AR-2018 definierte zweiphasige Identitätsmodell und führt zu einem Single Point of Failure für beide Phasen.

Die ECA-Zertifizierung wird nicht zum Zeitpunkt der Fertigung eingeplant. Wenn Ihr Gerät DICE implementiert, muss die ECA vor Auslieferung zertifiziert sein. Dies bedeutet, dass die Zwischenzertifizierungsstelle des Herstellers verfügbar und in den Fertigungsablauf integriert sein muss. Teams, die diese Anforderung erst nach Produktionsbeginn entdecken, müssen kostspielige Prozessanpassungen vornehmen oder Geräte ohne ordnungsgemäß zertifizierte ECA ausliefern.

Das SPDM-Zertifikatskettenformat wird ignoriert. SPDM GET_CERTIFICATE gibt eine Kette in einem bestimmten Format zurück: 2 Byte Gesamtlänge → 2 Byte Root-Hash-Länge → Root-Zertifikat-Hash → verkettete DER-Zertifikate. Wenn Ihre PKI Standard-DER-Ketten ausgibt und Ihre SPDM-Implementierung diese nicht korrekt verarbeitet, schlägt die CHALLENGE_AUTH-Verifizierung fehl.

Für Hardware-Zertifizierungsstellen ist keine CRL/OCSP-Infrastruktur erforderlich. Das ECA-Zertifikatsprofil setzt CRLDistributionPoints voraus. Die CRL-Infrastruktur von Hardware-Zertifizierungsstellen muss für eine sehr niedrige Widerrufshäufigkeit, aber eine sehr hohe Validierungshäufigkeit ausgelegt sein. Jede SPDM-Attestierung validiert die Zertifikatskette, einschließlich CRL/OCSP-Prüfungen.

Wie kann Encryption Consulting helfen?

Encryption Consulting ist auf PKI-Architektur für hardwarebasierte Identitätsverwaltung spezialisiert. Unsere Arbeit mit Hardwareherstellern und implementierenden Unternehmen umfasst die Themen dieses Blogs: die Entwicklung von Hersteller-CA-Hierarchien, die Konfiguration von Hardware-Zertifikatprofilen, die Implementierung der ECA-Bereitstellung in Fertigungsabläufen und den Aufbau der Eigentümer-PKI, die die IDevID mit der operativen Identität des Agenten verbindet.

• PKI-Design für Hersteller: Wir entwerfen CA-Hierarchien, die auf TCG DICE, IEEE 802.1AR und DMTF SPDM abgestimmt sind. Dies umfasst die Planung der Offline-Root-CA-Zeremonie, die HSM-Auswahl und -Konfiguration sowie die Spezifikationen der Zertifikatsprofile, die Ihre CA für IDevID-, ECA- und Attestierungszertifikate benötigt.
• Integration in den Fertigungsworkflow: Die ECA-Schlüsselzertifizierung erfordert die Verfügbarkeit und Integration der Hersteller-CA während des Produktionsprozesses. Wir entwickeln und implementieren die PKI-zu-Fertigungs-Integration mit HSM-Konnektivität, Zertifikatserstellung und -verifizierung, um dies betrieblich praktikabel zu gestalten.
• SPDM- und DICE-Implementierung: Wir verbinden Hardware-PKI mit Laufzeitattestierung und stellen sicher, dass die von Ihrer PKI ausgestellte Zertifikatskette die SPDM-Validierung GET_CERTIFICATE und CHALLENGE_AUTH besteht. Fallstudie zu Fortune 100 SPDM ist eine Produktionsreferenz für dieses Werk.
• CertSecure Manager für Agent CLM: Für die PKI des Eigentümers, die die Lebenszyklen der operativen Agentenzertifikate in großem Umfang verwaltet, bietet CertSecure Manager die Möglichkeit zur Erkennung, automatisierten EST-Erneuerung, automatisierten Widerrufung und Audit-Trail-Infrastruktur.

Fazit

Die Hardwareidentität für KI-Agenten ist keine Zukunftsfrage. KI-Beschleuniger implementieren bereits DICE. Unternehmenshardware unterstützt bereits SPDM. Die Zertifikate, die diese Attestierungen in eine nutzbare PKI einbinden, entsprechen bereits den etablierten Standards X.509 und CMS. Was fehlt, ist die Betriebsarchitektur, die diese verbindet, und der organisatorische Wille, hardwarebasiertes Vertrauen als Grundlage für den Einsatz agentenbasierter KI zu fordern.

Die verbleibenden vier Blogbeiträge dieser Reihe bauen diese Architektur Stück für Stück auf. Am Ende verfügen Sie über einen vollständigen Entwurf für einen KI-Agenten-Identitätsstack, der auf Siliziumebene beginnt und mit einem signierten, nachvollziehbaren Protokoll jeder relevanten Aktion Ihrer Agenten endet.