Jeder verifizierte Agent ist vertrauenswürdig, oder? Das ist so, als würde man sagen, jeder Führerscheininhaber sei ein guter Fahrer. Die KI-Branche rennt darum, das Identitätsproblem für autonome Agenten zu lösen — und die IAM-Platzhirsche rennen mit. Sie lösen das richtige Problem. Sie lösen die Hälfte davon. Dieser Leitfaden geht die beiden Fragen durch, die getrennt beantwortet werden müssen, warum OAuth und Rollen nicht beide beantworten können, und wie die Verhaltensebene aussieht, wenn sie tatsächlich im Einsatz ist.
Jede Zugriffsentscheidung für einen autonomen Agenten beantwortet zwei unterschiedliche Fragen, und sie zu vermischen ist der Grund, warum Governance im Produktivbetrieb scheitert.
Identitätsebene. Wer ist dieser Agent? Wer hat ihn gebaut? Wen vertritt er? Ist die vorgelegte Anmeldeinformation kryptografisch verifizierbar? Wurde sie widerrufen? Jede IAM-Plattform beantwortet diese Frage — gut.
Verhaltensebene. Hat sich dieser Agent innerhalb seines Geltungsbereichs gehalten? Hat er halluziniert? Hat er PII über Tool-Aufrufe durchsickern lassen? Verändert sich sein Risikoprofil? IAM-Plattformen können das nicht beantworten — und waren nie dafür ausgelegt.
Ein Agent, der die Identitätsprüfung nicht besteht, sollte blockiert werden. Ein Agent, der die Identitätsprüfung besteht, sich aber schlecht verhält, sollte eingeschränkt werden. Keine der beiden Ebenen allein reicht aus.
Die etablierten IAM-Anbieter — Okta, SailPoint, Microsoft Entra, IBM, Auth0, Curity und der Rest des standardgetriebenen Ökosystems (W3C DID, OpenID Foundation) — nähern sich einer ausgereiften Antwort auf die Identitätsfrage für autonome Agenten an. Das Vokabular ist anbieterübergreifend konsistent: Just-in-time-Provisionierung, dynamische Berechtigungsvergabe, kurzlebige Anmeldeinformationen, delegierte Befugnisse, Attestierungsketten. Das NCCoE des NIST hat ein Projekt zu Software- und KI-Agenten-Identität und -Autorisierung, das denselben Raum abbildet.
Das ist gute Arbeit. Die Identitätsebene ist schwierig und genau der richtige Ausgangspunkt. Nichts von dem, was folgt, ist ein Argument dafür, dass Identität überflüssig sei oder dass die etablierten Anbieter damit falsch lägen. Das tun sie nicht.
Was die Identität eines Agenten überhaupt erst verifizierbar macht — nicht nur provisioniert — steht unter Verifizierbare Agenten-Identität.
IAM beantwortet, wer zu dem Zeitpunkt, als wir die Anmeldeinformation ausgestellt haben, mit welchem Zugriff ausgestattet wurde. Autonome Agenten brauchen eine Antwort auf eine andere Frage: verhält sich diese Entität mit dieser Anmeldeinformation in diesem Kontext gerade so, dass ihr Zugriff jetzt erhalten bleiben sollte?
Die Bilanz von 2025–2026 zeigt, wie diese Lücke in der Praxis aussieht:
Jeder dieser Vorfälle hätte in dem Moment, als er geschah, ein Okta-Audit bestanden. Die Anmeldeinformation wurde korrekt ausgestellt, die Rolle korrekt zugeschnitten, die Authentifizierung war erfolgreich. Nichts davon hat das Versagen verhindert, weil das Versagen der Identität nachgelagert war.
Die Verhaltensebene bewertet einen Agenten fortlaufend anhand von fünf Dimensionen — Identitätsvertrauen (ja, Identität ist eine der fünf, aber mit einem ehrlichen Abklingmodell statt einer dauerhaften Tatsache), Risiko, Zuverlässigkeit, Autonomie und Kalibrierung (ob die gemeldete Zuversicht eines Agenten mit seinen tatsächlichen Ergebnissen übereinstimmt) — und vergibt pro Entscheidung eine Richtlinienstufe (allow / review / deny). Entscheidend ist: Die fünf Dimensionen sind orthogonal — ein Agent kann kryptografisch verifiziert sein (hohes Identitätsvertrauen) und trotzdem einen sich verschlechternden Zuverlässigkeitswert haben, und die Richtlinienstufe berücksichtigt beides.
Der vollständige Leitfaden zum fünfdimensionalen Bewertungsmodell steht unter Agent Trust Scoring — Ein technischer Leitfaden. Das tiefer gehende Argument, warum ein zusammengesetzter Score im Produktivbetrieb nicht überlebt, steht unter Identität, Risiko, Zuverlässigkeit, Autonomie: Warum ein einzelner Vertrauens-Score für Agenten im Produktivbetrieb nicht ausreicht.
OAuth und Maschinenidentitätssysteme (SPIFFE/SPIRE, mTLS, OIDC-Client-Anmeldeinformationen) wurden für Dienste mit stabilen Identifikatoren, langlebigen Anmeldeinformationen und Menschen in der Entscheidungsschleife für Zugriffsentscheidungen entwickelt. Autonome Agenten brechen alle drei Annahmen: Sie sind kurzlebig, treffen Zugriffsentscheidungen autonom mit Maschinengeschwindigkeit, und ihre Anmeldeinformationen müssen delegierte Befugnisse, Geltungsbereich und Signale der Verhaltensstufe transportieren, für deren Ausdruck die ursprünglichen Protokolle nicht ausgelegt waren.
Die OAuth 2.1-Ergänzung von MCP im Jahr 2026 ist echter Fortschritt. Aber ein Sicherheitsscan von rund 2.000 MCP-Servern ergab, dass ausnahmslos jeder ohne Authentifizierung war. Die Spezifikation existiert; die Umsetzung nicht. (Vollständiges Bild in MCP-Serversicherheit: die PII-Lücke.) Die Agent Cards von A2A sind signiert, aber selbstdeklariert — es gibt keine Attestierungsbindung, keine Verhaltenshistorie, keinen Mechanismus, um Vertrauen aufgrund beobachteten Verhaltens zu widerrufen. Beide Protokolle lösen Discovery und Interoperabilität. Keines sagt dir, ob dem Agenten am anderen Ende zu trauen ist bei dem, was er gerade vorhat.
Die beiden Ebenen, in VeriSwarm miteinander verdrahtet:
Die Identitätsebene. Kryptografische Verifizierung, ES256-JWT-Anmeldeinformationen mit einer TTL von 1 Stunde, Delegationsketten für Multi-Agenten-Workflows, ein JWKS-Endpunkt, damit jede Plattform verifizieren kann, ohne unsere API aufzurufen. Alle Details unter Agent Passport: Portable Anmeldeinformationen.
Die Verhaltensebene. Kontinuierliche Bewertung entlang der fünf Dimensionen, dynamische Richtlinienstufen, die 24-Ereignis-Taxonomie. Kostenlose Stufe. Dasselbe hash-verkettete Audit-Ledger, das auch kostenpflichtige Pläne nutzen.
Die Nachweisebene. Unveränderliches, hash-verkettetes Audit-Ledger, das Identitätsereignisse, Verhaltenssignale, Richtlinienentscheidungen und jede Zustandsänderung abdeckt. Kettenverifizierung auf Abruf — Anleitung unter Eine Vault-Kette verifizieren.
Wenn ein Agent eine Passport-Anmeldeinformation vorlegt, weiß die empfangende Plattform, wer er ist. Trägt diese Anmeldeinformation zusätzlich einen Gate-Vertrauens-Score, weiß die Plattform auch, wie er sich verhalten hat. Vault beweist, dass die gesamte Abfolge tatsächlich stattgefunden hat. Das ist der Unterschied zwischen einem Führerschein und einer Fahrhistorie.
Der EU AI Act verlangt nicht nur Transparenz darüber, wer ein KI-System gebaut hat. Artikel 9 schreibt einen kontinuierlichen Risikomanagementprozess über den gesamten Lebenszyklus vor — keine einmalige Identitätsprüfung. Artikel 12 verlangt die automatische Ereignisaufzeichnung über die Lebensdauer des Systems — Verhaltensprotokollierung, keine Identitätsprüfung. Artikel 14 verlangt menschliche Aufsicht, die eine Interpretation der Ergebnisse ermöglicht — Interpretation erfordert die Überwachung von Verhalten. Die Regulierung geht bereits davon aus, dass Identität nicht Vertrauen ist; die Compliance erfordert beides. Vollständige Einordnung des EU AI Act für Agenten-Stacks.
Ja. Identität ist Ebene eins — VeriSwarm ersetzt sie nicht. Wenn sich Ihre Agenten über Okta, SailPoint, Entra, Auth0 oder ein beliebiges eigenes IAM authentifizieren, behalten Sie das bei. VeriSwarm setzt daneben an, fügt die Verhaltensebene hinzu, die Ihr IAM nicht hat, und integriert sich mit der Identität, die Ihre Plattform bereits ausstellt. Die beiden Ebenen arbeiten zusammen; sie stehen nicht im Wettbewerb.
Nein. Das sind Identitätsanbieter — sie beantworten „wer ist diese Entität, und welche Rolle hat sie?“. Das ist ein schwieriges Problem, und sie lösen es gut. VeriSwarm beantwortet eine andere Frage: „verhält sich diese Entität gerade so, dass ihr Zugriff erhalten bleiben sollte?“. Ein Identitäts-Stack sagt Ihnen, dass Agent A vor sechs Monaten mit Rolle X provisioniert wurde. Der Verhaltens-Stack sagt Ihnen, dass Agent A seit Dienstag halluziniert und heute von Rolle X zurückgestuft werden sollte. Unterschiedliche Fragen, beide erforderlich.
Eine andere Wette. Blockchain-basierte Agenten-Identität (ERC-8004, OriginTrail, dezentrale Pässe) priorisiert Zensurresistenz und On-Chain-Attestierung. VeriSwarm Passport verwendet ES256-JWTs mit JWKS-Verifizierung — ein standardbasierter Ansatz ohne Blockchain-Erfordernis, der schneller verifiziert (kein Chain-Lookup) und sich in bestehende Unternehmens-Identitätsinfrastruktur integriert. Beide sind für die Identitätsebene gültig; die Wahl hängt davon ab, ob Sie On-Chain-Provenienz benötigen. So oder so ist die Verhaltensebene die fehlende Hälfte.
Gate — die Verhaltensebene — läuft in der kostenlosen Stufe mit unbegrenzter Ereignisaufnahme, 5.000 Vertrauensentscheidungen pro Tag, der fünfdimensionalen Bewertungs-Engine und demselben hash-verketteten Ledger, das auch kostenpflichtige Pläne nutzen. Grundlegende portable Anmeldeinformationen — ES256-JWTs mit JWKS-Verifizierung — sind ebenfalls kostenlos und unbegrenzt. Was auf Pro und höher beschränkt ist, ist die vollständige Passport-Suite: Delegationsketten für Multi-Agenten-Workflows, signierte Manifeste und organisationsübergreifende Identitätsverifizierung. Sie können mit Verhaltensüberwachung und grundlegenden Anmeldeinformationen für Agenten beginnen, die Ihr bestehendes IAM bereits authentifiziert, und später den vollständigen Passport hinzufügen, wenn Sie Multi-Agenten-Delegation benötigen.
Maschinenidentitätssysteme wurden für Dienste mit stabilen Identifikatoren, langlebigen Anmeldeinformationen und menschlichen Bedienern entwickelt, die Zugriffsentscheidungen treffen. Agenten sind kurzlebig (oft Sekunden bis Minuten), treffen Zugriffsentscheidungen autonom und benötigen Anmeldeinformationen, die delegierte Befugnisse und Geltungsbereich explizit ausdrücken. Passport basiert aus Kompatibilitätsgründen auf JWT, aber sein Anmeldeinformationsmodell transportiert Delegationsketten, Geltungsbereichsausdrücke und Signale der Verhaltensstufe, für deren Ausdruck Maschinenidentitätsformate nicht ausgelegt waren. Verwenden Sie Maschinenidentität für Ihre Service-zu-Service-Ebene; verwenden Sie Passport für die Agent-zu-Agent-Ebene darüber.
Beides, kombiniert auf der Entscheidungsebene. Eine Richtlinienentscheidung nimmt die Identität des Agenten, seinen aktuellen Vertrauens-Score über alle fünf Dimensionen, die konkrete versuchte Aktion und jede Kill-Switch- oder Passport-Verifizierungs-Übersteuerung und gibt ein einziges allow / review / deny mit einem Grundcode aus. Weder die Identität noch der Vertrauens-Score allein bestimmen das Ergebnis — die Entscheidungs-Engine wertet zuerst die Cedar-Richtlinie des Mandanten aus (oder eine fest codierte Standardmatrix, falls keine konfiguriert ist) gegen diesen gesamten Kontext.
Ja, und genau das ist der Sinn der Verhaltensebene. Eine gültige Passport-Anmeldeinformation oder ein vom IAM ausgestelltes Token belegt, dass die Identität des Agenten legitim ist; es sagt nichts darüber aus, ob dem Agenten für eine bestimmte Aktion gerade jetzt vertraut werden sollte. Der Kill Switch ist das klarste Beispiel: Das Töten eines Agenten widerruft oder verändert seine Identitätsanmeldeinformation nicht, aber jede Entscheidungsprüfung gegen diesen Agenten liefert deny mit reason_code: "agent_killed", bis ein Operator dies rückgängig macht — die Identitätsebene bleibt grün, während die Verhaltensebene sie übersteuert.
Nein. Identitätsverifizierung erfüllt die Anforderungen an Transparenz und Herkunft — wer hat es gebaut, wer betreibt es — aber beide Rahmenwerke verlangen fortlaufende Verhaltensnachweise, keine einmalige Prüfung. Die Anforderung der automatischen Ereignisaufzeichnung nach Artikel 12 des EU AI Act und die Erwartungen an kontinuierliche Überwachung des NIST AI RMF werden durch die Ereignisprotokollierung der Verhaltensebene und das hash-verkettete Ledger von Vault erfüllt, nicht durch eine Identitätsanmeldeinformation allein.
Die Bewertungs-Engine von Gate läuft in der kostenlosen Stufe und integriert sich mit der Identität, die Ihre Plattform bereits ausstellt. Sie müssen nichts herausreißen. Sie müssen die Ebene hinzufügen, die Ihrem IAM fehlt.