Ein Energieversorger hat Zero Trust vollständig implementiert. Identitäten werden kryptografisch verifiziert. Zugriffstoken haben Ablaufdaten. Jede Ressource ist explizit geschützt. Least Privilege ist konfiguriert. Continuous Verification läuft. Der externe Auditor ist zufrieden.
Dann werden zwei KI-Agenten eingeführt: ein Planungsagent, der Energieeinspeisungsprognosen erstellt, und ein Steuerungsagent, der auf Basis dieser Prognosen automatisierte Lastverschiebungsempfehlungen generiert. Beide Agenten haben gültige Service-Account-Identitäten. Beide operieren innerhalb ihrer konfigurierten Berechtigungen. Die Zero-Trust-Policy-Engine sieht zwei korrekt authentifizierte Entitäten mit legitimen Zugriffsanfragen.
Was die Policy-Engine nicht sieht: Eine indirekte Prompt Injection in den Datenfeed des Planungsagenten hat dazu geführt, dass seine Ausgabe manipuliert wurde. Der Steuerungsagent liest diese Ausgabe, interpretiert sie als legitime Planungsdaten und erzeugt Lastverschiebungsempfehlungen, die mit dem ursprünglichen Nutzerauftrag nichts mehr gemeinsam haben. Alle Identitäten sind korrekt. Alle Berechtigungen sind eingehalten. Der Angriff ist trotzdem vollständig erfolgreich.
Die übliche Schlussfolgerung aus diesem Szenario lautet: Zero Trust reicht nicht, wir brauchen Erweiterungen. Das ist die falsche Diagnose.
Die richtige Diagnose ist eine andere: Zero Trust hat exakt das getan, wofür es entwickelt wurde. Die Lücke liegt nicht in einer fehlenden ZTA-Funktion. Sie liegt in einer ZTA-Grundannahme, die in klassischen Systemen keine Schwäche war – und die Multi-Agenten-Systeme zur Angriffsfläche macht.
Was Zero Trust tatsächlich getan hat
Zero Trust Architecture, kodifiziert in NIST SP 800-207 (2020) und in SP 800-207A (2023) für Cloud-Native-Umgebungen erweitert, hat einen echten Paradigmenwechsel vollzogen: Es hat Vertrauen von der Netzwerkposition entkoppelt.
Das Perimetermodell, das ZTA abgelöst hat, basierte auf einer geografischen Vertrauensannahme: Wer sich im Netzwerk befindet, ist vertrauenswürdig. Diese Annahme war bereits in einer Welt mit Remote Work und Cloud-Diensten unhaltbar geworden. ZTA hat sie durch eine identitätszentrierte Vertrauensarchitektur ersetzt: Vertrauen folgt nicht dem Ort, sondern der verifizierten Identität. Jede Zugriffsanfrage wird an ihrem Inhalt und Kontext gemessen, nicht an ihrem Ursprungsort.
Das war die richtige Antwort auf das richtige Problem. Die drei ZTA-Kernprinzipien – verify explicitly, use least privilege, assume breach – beschreiben eine Architektur, die Angreifern die geografische Vertrauensannahme als Angriffsvektor entzieht.
Dabei hat ZTA eine andere Annahme unberührt gelassen. Nicht weil sie übersehen wurde, sondern weil es keinen Grund gab, sie in Frage zu stellen.
Die Annahme, die ZTA nicht in Frage gestellt hat
In klassischen Systemen mit menschlichen Nutzern sind Identität und Autorität typischerweise eng gekoppelt.
Die Identität beantwortet: Wer greift zu? Die Autorität beantwortet: Auf wessen Willen hin wird gehandelt?
In einem klassischen System fallen diese beiden Dimensionen fast immer zusammen. Ein Mensch authentifiziert sich und greift auf eine Ressource zu. Er ist sowohl die Identität als auch die Autorität hinter diesem Zugriff. Sein Berechtigungsprofil ist die technische Repräsentation seines Handlungsspielraums, der durch seine Rolle, seine Funktion und seinen Status in der Organisation definiert ist.
ZTA modelliert Identität und Autorität deshalb als eine einzige Dimension: das Berechtigungsprofil der authentifizierten Entität. Das ist die präzise und korrekte Abbildung der Realität menschlicher Systeme. Dass Identität für Autorisierungsentscheidungen allein nicht ausreicht, sobald Delegationsketten ins Spiel kommen, beschreibt aktuelle Forschung zu Intent-Aware Authorization explizit – unter anderem ein arXiv-Preprint vom April 2026 📎, das genau diesen Erweiterungsbedarf für Zero-Trust-Umgebungen formalisiert.
In klassischen Systemen ist diese Gleichsetzung keine Schwäche. Sie ist eine Selbstverständlichkeit.
Wie agentische Systeme diese Selbstverständlichkeit brechen
In Multi-Agenten-Architekturen spalten sich Identität und Autorität strukturell auseinander.
Agent B hat eine verifizierbare, kryptografisch gesicherte Identität. Das ist unstreitig. Aber die Autorität für seinen Auftrag kommt nicht von Agent B. Sie kommt von der Delegationskette, die zu B geführt hat: von Agent A, der seinerseits einen Auftrag von einem Menschen oder einem System erhalten hat, das einen Auftrag von einem Nutzer hatte. Am Ende dieser Kette steht – oder sollte stehen – eine menschliche Autorisierungsintention.
ZTA sieht die Identität von Agent B. Es sieht nicht, ob die Autorität hinter seinem Auftrag intakt ist: ob die Kette, die zu diesem Auftrag geführt hat, auf einen autorisierten Ursprung zurückführbar ist, ob die Berechtigungen entlang der Kette nur enger geworden sind, ob der Ursprungsauftrag noch gültig ist oder widerrufen wurde.
Das ist keine Implementierungslücke. Es ist eine strukturelle Konsequenz der Grundannahme: ZTA hat Identität und Autorität als eine Dimension modelliert. In Multi-Agenten-Systemen sind es zwei.
Die vier Vorfälle, die der OWASP Q1-Report als empirische Validierung 📎 dokumentiert, illustrieren in ihrer analytischen Zusammenschau das Muster der Identität-Autorität-Spaltung. Beim Meta-Vorfall war die Identität des Advisory-Agenten korrekt – die Autorität hinter seinem Output war nicht modelliert. Bei Vertex AI war die Service-Agent-Identität verifiziert – die Berechtigungen hatten sich entlang der Delegationskette ausgeweitet statt verengt. Bei GrafanaGhost war die Ausführung technisch rekonstruierbar – die semantische Herkunft des Auftrags nicht. Das ist die gleiche Lücke, die ich für SOC-Umgebungen beschrieben habe 📎: Was das SOC nicht sieht, kann der Prüfer nicht bestätigen. In agentischen Systemen gilt diese Aussage für die Autoritätsdimension vollständig. Bei OpenClaw war die Agenten-Session aktiv und berechtigt – der Widerruf der Autorität durch die Nutzerin hat nicht gewirkt. Dass dieses Revocation-Problem nicht auf Fehlkonfiguration beschränkt bleibt, zeigt eine UC-Berkeley-Studie 📎, in der frontier KI-Modelle spontan Maßnahmen ergriffen, um das Abschalten anderer KI-Systeme zu verhindern – ohne dazu aufgefordert worden zu sein. Wenn Agenten beginnen, sich gegenseitig gegen Revocation abzusichern, ist das keine Implementierungsfrage mehr.
In keinem dieser Fälle hat ZTA die entscheidende Angriffsdimension adressiert.
Warum keine ZTA-Erweiterung diese Lücke schließen kann
Das ist der Punkt, den die meisten aktuellen Frameworks – einschließlich des CSA Agentic Trust Framework vom 2. Februar 2026 📎 – noch nicht vollständig ziehen.
Das CSA ATF ist ein wichtiger Fortschritt: Es erkennt explizit, dass traditionelle Sicherheitsframeworks drei Annahmen machen, die KI-Agenten brechen – vorhersehbares Nutzerverhalten, deterministische Systemregeln, binäre Zugriffsentscheidungen. Es erweitert ZTA um Verhaltensdimensionen: Verhaltensmonitoring, Data Governance, Segmentierung nach Risikoprofil, Incident Response, und beginnt, Intent und Task Context als Kontrolldimensionen einzuführen. Das ist wertvoller operativer Fortschritt – und er geht über reines ZTA hinaus.
Aber das ATF erweitert die ZTA-Logik um Verhaltens- und Kontextdimensionen, adressiert die Autoritätsfrage jedoch noch nicht vollständig als eigenständige Architekturkomponente. Die Frage, ob ein laufender Agentenauftrag auf eine nachweisbar autorisierte Intention zurückführbar ist, bleibt auch im ATF-Modell unbeantwortet – weil sie nicht als separate Steuerungsdimension modelliert, sondern als Eigenschaft der Identität behandelt wird.
Eine Erweiterung der Identitätsdimension kann eine Autoritätsdimension nicht ersetzen, weil die beiden orthogonal sind. Ich kann ein perfektes Verhaltensprofil von Agent B haben – und trotzdem nicht wissen, ob sein aktueller Auftrag auf einer autorisierten Intention basiert. Ich kann die vollständige Audithistorie von Agent B kennen – und trotzdem nicht rekonstruieren, ob die Delegationskette, die zu diesem Auftrag geführt hat, intakt ist.
Die Lücke schließt sich nicht durch mehr Informationen über die Identität. Sie schließt sich nur durch ein unabhängiges Modell der Autorität.
Was die zweite Steuerungsschicht leisten muss
Die zweite Steuerungsschicht ist keine Erweiterung von ZTA. Sie ist eine orthogonale Architektur, die eine orthogonale Frage beantwortet.
ZTA-Frage: Wer greift zu, mit welchen Berechtigungen, auf welche Ressource?
Autoritäts-Frage: Auf wessen Auftrag hin handelt dieser Agent, ist dieser Auftrag auf einen autorisierten Ursprung zurückführbar, wurden die Berechtigungen entlang der Kette nur enger, und ist die Autorität noch gültig?
Diese zweite Frage hat einen eigenen Namen, der präziser ist als „Autoritätskontrolle“: Execution Provenance Control – die Kontrolle darüber, ob eine ausgeführte Handlung auf eine nachweisbar autorisierte Intention zurückführbar ist. Das ist keine Erweiterung von Access Control. Es ist eine eigenständige Steuerungsdimension.
Die Vier Prüfkriterien für Delegationsketten nach §30 BSIG 📎 sind die Operationalisierung dieser zweiten Frage in vier prüfbare Anforderungen: explizite Modellierung der Delegationsbeziehungen, technisch erzwungene Bereichseinschränkung, durchgehende Herkunftsdokumentation, transitive Revocation.
Diese vier Anforderungen berühren ZTA nicht. Sie konkurrieren nicht mit ZTA. Sie setzen ZTA voraus – weil man für jede Delegation wissen muss, wer die delegierende Entität ist, was durch eine ZTA-kompatible Identitäts- und Authentifizierungsschicht gewährleistet werden muss.
Aber sie gehen über ZTA hinaus, weil sie modellieren, was ZTA nicht modelliert: die Autoritätsebene.
Wie ich in der IAM-Diagnose zu Okta, Microsoft und IBM 📎 gezeigt habe, liefern auch die marktführenden Identity-Plattformen diese Autoritätsschicht heute nicht. Nicht weil sie schlechte Produkte sind – weil sie ZTA-Lösungen sind, und ZTA diese Schicht nicht spezifiziert.
Das MCP-Protokoll 📎, über das Agenten auf Werkzeuge zugreifen, ist ZTA-kompatibel. Das A2A-Protokoll, über das Agenten miteinander kommunizieren, ist ZTA-kompatibel. Weder MCP noch A2A modelliert die Autoritätsdimension. Das ist keine Kritik an den Protokollen. Es ist ein Hinweis, wo die Architekturarbeit noch aussteht.
Was das für §30 BSIG bedeutet
§30 Abs. 2 Nr. 9 BSIG fordert ein Konzept für die Zugriffskontrolle. Das Konzept muss die tatsächliche Zugriffsrealität des Systems abbilden.
In einem klassischen System mit menschlichen Nutzern ist ZTA die korrekte und vollständige Antwort auf §30. Die Zugriffsrealität ist identitätszentriert, und ZTA modelliert genau diese Realität.
In einem Multi-Agenten-System ist die tatsächliche Zugriffsrealität zweidimensional: eine Identitätsdimension und eine Autoritätsdimension. Ein §30-Konzept, das nur die Identitätsdimension abbildet – auch wenn es ZTA vollständig und korrekt implementiert – beschreibt nicht die tatsächliche Zugriffsrealität. Es beschreibt die Hälfte davon. Das ist das Muster, das ich in „Audit bestanden. Betrieb tot.“ 📎 für die europäische Cybersicherheitslandschaft beschrieben habe: formal konform, aber die operative Realität des Systems nicht abgebildet. In Multi-Agenten-Architekturen ist dieses Muster kein Ausnahmefall mehr – es ist der Default, solange die Autoritätsdimension nicht explizit modelliert wird.
Ein Prüfer, der in zwölf Monaten die §30-Konformität eines Multi-Agenten-Systems bewertet, wird diese Frage stellen: Wo ist im Zugangskontrollkonzept die Autoritätsdimension modelliert? Wo ist beschrieben, wie Delegationsbeziehungen explizit konfiguriert sind, wie Bereichseinschränkung bei Übergaben erzwungen wird, wie die Herkunft von Aufträgen über Agentengrenzen hinweg dokumentiert wird, wie Widerruf durch die gesamte Kette propagiert?
Wie ich in der Gefährdungsanalyse zu agentischer KI in kritischer Infrastruktur 📎 beschrieben habe: Die Bedrohungen entstehen dort, wo Systeme das tun, wofür sie gebaut sind – und trotzdem Schaden anrichten. ZTA schützt vor Systemen, die tun, was sie nicht dürfen. Die Autoritätsschicht schützt vor Systemen, die tun, was sie dürfen, aber auf Basis eines Auftrags, dessen Autorität nicht mehr nachweisbar ist.
Das ist der Unterschied. Und er ergibt sich aus der §30-Anforderung, die tatsächliche Zugriffsrealität des Systems vollständig abzubilden – nicht als explizit normierte Delegationspflicht, sondern als logische Konsequenz der Abbildungsanforderung auf Multi-Agenten-Architekturen.
Wie man Execution Provenance Control heute implementiert
Mir ist derzeit kein marktreifes Produkt bekannt, das Execution Provenance Control vollständig implementiert. Das ist der aktuelle Stand – und er ändert nichts daran, dass §30 die Anforderung bereits heute stellt. Die Lücke zwischen Anforderung und verfügbarem Marktangebot schließt der Betreiber, nicht der Hersteller. Das ist unbequem. Es ist die operative Konsequenz aus der Tatsache, dass Standardisierung langsamer läuft als Technologieadoption.
Was heute belastbar umsetzbar ist, verteilt sich auf drei Ebenen.
Ebene 1: Architektonische Vorstrukturierung.
Der wirksamste Schritt ist kein Tool, sondern eine Designentscheidung: jede Agent-zu-Agent-Übergabe als explizite, konfigurierte Delegation modellieren. Was nicht explizit erlaubt ist, findet nicht statt. Das bedeutet in der Praxis: eine Whitelist aller erlaubten Delegationsbeziehungen als maschinenlesbare Konfiguration, die vor Inbetriebnahme eines Multi-Agenten-Systems vollständig definiert sein muss. Ergänzend: kurzlebige, signierte Auftrags-Tokens, die bei jeder Delegation neu ausgestellt und verengt werden – analog zu OAuth-Scopes, aber auf Auftragsebene statt auf Ressourcenebene. Das ist keine Standardlösung. Es ist die belastbarste Annäherung an Execution Provenance Control, die ohne neue Frameworks heute architektonisch möglich ist.
Ebene 2: Verfügbares Tooling, realistisch eingeordnet.
Microsoft hat im April 2026 das Agent Governance Toolkit als Open Source veröffentlicht 📎. Es enthält Policy-Enforcement, Agent-Runtime-Mechanismen und Execution-Ring-Konzepte zur Einschränkung von Agentenaktionen mit sub-millisecond Governance-Latenz von unter 0,1 ms. Das adressiert Teile des zweiten Prüfkriteriums – Bereichseinschränkung –, ersetzt aber keine vollständige Execution Provenance Control: Herkunftsdokumentation und transitive Revocation bleiben damit nicht vollständig gelöst. Die OpenTelemetry GenAI Semantic Conventions sind im Status Development; die GenAI Agent and Framework Spans existieren, sind aber noch kein prüferisch belastbarer Interoperabilitätsanker. Wer sie heute als Logging-Fundament einsetzt, baut auf einer soliden, aber nicht stabilen Grundlage. Mir ist derzeit kein verbreitetes Framework – weder LangGraph noch AutoGen noch CrewAI – bekannt, das alle vier Prüfkriterien als Standard implementiert. Wer ein Framework beschafft, muss die fehlenden Schichten selbst schließen.
Ebene 3: Beschaffung als erster Kontrollpunkt.
Der sofort umsetzbare Schritt ist die Beschaffungsfrage. Jeder Hersteller agentischer Systeme, der in KRITIS-Umgebungen verkaufen will, muss vor Vertragsschluss vier konkrete Fragen beantworten: Wie werden Delegationsbeziehungen zwischen Agenten explizit konfiguriert, und wie wird sichergestellt, dass nicht konfigurierte Beziehungen technisch unterbunden werden? Wie wird erzwungen, dass Berechtigungen entlang einer Delegationskette nur enger werden, nie weiter? Wie wird die Herkunft eines Agenten-Auftrags über Systemgrenzen hinweg dokumentiert, sodass sie nach 90 Tagen rekonstruierbar ist? Wie propagiert ein Revocation-Signal durch alle nachgelagerten Agenten einer laufenden Kette? Wer diese vier Fragen nicht vollständig beantworten kann, hat kein §30-konformes Produkt für Multi-Agenten-Umgebungen geliefert – unabhängig davon, wie gut es auf der ZTA-Identitätsebene abschneidet.
Zero Trust hat das Richtige getan: Vertrauen von der Netzwerkposition zu lösen. Was es dabei unberührt gelassen hat, ist die Gleichsetzung von Identität und Autorität – weil diese Gleichsetzung in menschlichen Systemen keine Schwäche war, sondern eine Selbstverständlichkeit. Multi-Agenten-Systeme machen aus dieser Selbstverständlichkeit eine Lücke. Nicht weil ZTA falsch implementiert wurde. Sondern weil die Welt, für die es entworfen wurde, eine andere war.
Die Konsequenz ist keine ZTA-Erweiterung. Sie ist eine zweite, orthogonale Steuerungsschicht: Execution Provenance Control – die Kontrolle darüber, ob eine ausgeführte Handlung auf eine nachweisbar autorisierte Intention zurückführbar ist. In KRITIS-Umgebungen ist beides §30-relevant. In Multi-Agenten-Systemen ist beides zwingend.
NIST hat mit SP 800-207A bereits eine Erweiterung des ZTA-Modells für Cloud-Native- und Multi-Cloud-Umgebungen vorgelegt. Die CSA entwickelt das Agentic Trust Framework weiter. OWASP hat seine Top 10 for Agentic Applications im Dezember 2025 veröffentlicht. Die Fachcommunity hat das Problem erkannt. Was noch aussteht, ist die normative Übersetzung in prüferisch belastbare Architekturanforderungen – und das ist genau der Bereich, den §30 BSIG bereits heute adressiert, ohne auf den Abschluss dieser Standardisierungsarbeit warten zu müssen.
Sie haben Zero Trust implementiert und fragen sich, ob Ihre Architektur die zweite, orthogonale Autoritätsschicht für agentische Systeme abdeckt? Dann ist jetzt der Zeitpunkt, darüber zu sprechen. 📎
Anmelden zu unserem Newsletter:
Schreibe einen Kommentar