Fünf Komponenten. Eine offene Frage – was §30 BSIG für agentische KI-Zugriffskontrolle tatsächlich erfordert

Seit Dezember 2025 gilt das NIS-2-Umsetzungsgesetz in Deutschland. Für KRITIS-Betreiber bedeutet das unter anderem: alle drei Jahre müssen sie durch Audits, Prüfungen oder Zertifizierungen nachweisen, dass die Anforderungen des §30 BSIG erfüllt sind. Die Nachweise erbringen externe, qualifizierte Prüfende im BSI-Rahmen – beauftragt vom Unternehmen selbst. Für besonders wichtige Einrichtungen sind anlasslose Prüfungen durch das BSI möglich. Das BSI kann Nachbesserungsfristen setzen. Bei schwerwiegenden Mängeln drohen Bußgelder bis zu 10 Mio. Euro oder bis zu 2 % des weltweiten Jahresumsatzes – je nachdem, welcher Betrag höher ist – sowie die persönliche Haftung der Geschäftsführung nach §38 BSIG.

Das Energieversorgungsunternehmen in diesem Szenario hat seine Prüfung selbst beauftragt – planmäßig, fristgerecht, mit einer qualifizierten externen Prüfstelle. Die Prüfung verläuft routiniert. Zugangskontrollkonzept vorgelegt, Incident-Response-Plan dokumentiert, Patch-Management nachgewiesen. Dann hält der Prüfer inne. Er hat eine Frage zu einem KI-Agenten, den das Unternehmen seit drei Monaten in der internen Dokumentenverarbeitung betreibt.

Auf welche Systeme hat dieser Agent in den letzten neunzig Tagen zugegriffen – und war das im Rahmen seiner autorisierten Aufgabe?

Der Verantwortliche öffnet das Berechtigungssystem. Er findet die Identität des Agenten, seine Rolle, seine formalen Rechte. Auf den ersten Blick: vollständig gepflegt. Sie erfasst, was der Agent darf. Was er in den letzten neunzig Tagen tatsächlich getan hat – in welchem Kontext, mit welchen Auswirkungen – steht nirgends.

Er kann die Frage nicht beantworten.

Für den Prüfer ist das ein wesentlicher Befund. §30 Abs. 2 Nr. 9 BSIG verlangt die „Erstellung von Konzepten für die Sicherheit des Personals, die Zugriffskontrolle und für die Verwaltung von IKT-Systemen, -Produkten und -Prozessen.“ Eine Dokumentation, die nur festhält, was ein System darf, aber nicht, was es tut, erfüllt diese Anforderung nicht.

Die naheliegende Reaktion wäre: Dokumentation nachbessern, Logging erweitern, fertig. Aber das greift nicht. Das Problem ist kein fehlendes Protokoll. Es ist ein strukturelles Kompatibilitätsproblem zwischen dem Modell, mit dem Zugangskontrolle heute funktioniert, und der Systemklasse, die KI-Agenten darstellen. Ein Protokoll lässt sich ergänzen. Ein Modell lässt sich nicht durch Nachbessern retten, wenn es für eine andere Systemklasse gebaut wurde.

Das ist kein Implementierungsdefizit. Es ist ein Kategorienfehler.

Ein Kategorienfehler lässt sich nicht beheben – nicht durch mehr Funktionen, nicht durch mehr Entwicklungsaufwand, nicht durch einen Patch. Der Fehler liegt nicht darin, wie das Modell gebaut wurde – sondern darin, wofür es gebaut wurde. Klassisches IAM wurde für einen Akteur gebaut, der eine Absicht hat und sie ausführt: einen Menschen. Es fragt: „Wer bist du?“ Nicht: „Was tust du gerade – und entspricht das deiner Aufgabe?“ Warum Okta, Microsoft und IBM diesen Unterschied kennen, aber nicht lösen 📎, hat der erste Artikel dieser Reihe gezeigt. Ein KI-Agent ist selbst der Akteur, der Absichten bildet 📎 – auf Basis von Kontext, externen Eingaben und Laufzeitentscheidungen, die im Vorfeld nicht vollständig bestimmbar sind. Das Modell auf diese Systemklasse anzuwenden ist nicht falsch implementiert. Es ist das falsche Modell.

Was das richtige Modell wäre, ist beschreibbar. Fünf Architekturkomponenten, heute partiell umsetzbar. Und eine Lücke, die kein Anbieter vollständig schließt. Unbequem ist nicht das Modell. Unbequem ist der Kalender: Der AI Act gilt grundsätzlich ab dem 2. August 2026 📎 – die spezifischen Pflichten für Hochrisiko-KI-Systeme nach Anhang III greifen jedoch erst ab dem 2. August 2027. Agentische IAM-Standards existieren nicht. Und die Lücke zwischen dem, was §30 erfordert, und dem, was verfügbar ist, liegt letztlich in der Organisations- und Überwachungsverantwortung der Geschäftsleitung.

§30 BSIG und agentische KI: Das strukturelle Kompatibilitätsproblem

§30 Abs. 2 Nr. 9 BSIG verlangt die Erstellung von Konzepten für die Zugriffskontrolle als Teil des technischen und organisatorischen Risikomanagements. Was das für menschliche Nutzer und klassische Dienstkonten bedeutet, ist seit Jahren auditiert, dokumentiert und weitgehend verstanden.

Für KI-Agenten gilt das nicht.

Nicht weil die Norm nichts sagt, sondern weil drei ihrer impliziten Voraussetzungen bei Agenten nicht erfüllt sind. Erstens setzt §30 voraus, dass ein Zugangskontrollkonzept die Zugriffsrealität abbildet. Ein Agent, der zur Laufzeit Entscheidungen trifft und Ressourcen aufruft, die sich erst im Kontext seiner Aufgabe ergeben, ist mit statischen Rollen nicht abbildbar. Das Konzept existiert formal. Es beschreibt nicht, was der Agent tut.

Zweitens verlangt §30 Dokumentierbarkeit: Welche Systeme wurden zugegriffen, wann, von wem, warum? Bei einem Agenten, dessen Zugriffspfad kontextsensitiv und nicht vollständig vorhersehbar ist, protokollieren traditionelle Audit-Logs die Aktion – aber nicht den Kontext, aus dem sie entstand. Und damit nicht, ob sie überhaupt zulässig war.

Drittens setzt Zugangskontrolle voraus, dass Zugang im Vorfeld definierbar ist. Bei agentischen Systemen ergibt sich der Zugriffsbedarf erst zur Laufzeit. Die Vordefinition führt entweder zu einer Blankovollmacht – zu weit – oder zu einem System, das nicht funktioniert – zu eng.

Das ist keine Auslegungsfrage. Es ist ein strukturelles Kompatibilitätsproblem.

Ein Zugangskontrollkonzept im Sinne von §30 ist nur dann erfüllt, wenn es die tatsächliche Zugriffsrealität abbildet – nicht nur die intendierte. „Konzept“ bedeutet nicht Dokument. Es bedeutet abbildbare Steuerungslogik. Wer ein Dokument einreicht, das die Wirklichkeit des eingesetzten Systems nicht beschreibt, hat die Anforderung nicht erfüllt.

Wie weit entfernt die Praxis von einer tragfähigen Antwort ist, zeigt die CSA/Strata-Studie „Securing Autonomous AI Agents“ (Februar 2026, 285 IT- und Security-Verantwortliche, von Strata beauftragt) 📎: Nur 18 Prozent der Befragten sind hochgradig zuversichtlich, dass ihre bestehenden IAM-Systeme agentische Identitäten wirksam beherrschen können. 35 Prozent moderat. 29 Prozent wenig. 18 Prozent überhaupt nicht. Das sind keine Pilotprojekte. Das sind die Organisationen, die Agenten heute produktiv betreiben.

Das BSI hält explizit fest 📎, dass für kritische KI-Anwendungskontexte derzeit keine hinreichend geeigneten Standards existieren. Das ist keine Beruhigung. Es ist der Hinweis, dass eine Organisation, die heute ein belastbares §30-Konzept für Agenten aufstellen will, das auf Eigeninitiative leisten muss.

Identität entsteht erst, wenn sie gebraucht wird

Klassisches IAM provisioniert Identitäten vor dem Zugriff – einmal, dann stehend, bis zur De-Provisionierung. Das produziert, was Sicherheitsarchitekten als Identity Dark Matter bezeichnen: Berechtigungen, die im System existieren, aber niemand mehr aktiv braucht oder überwacht – vergebene Rechte für abgeschlossene Projekte, ausgeschiedene Mitarbeiter, gelöschte Systeme. Schlummernde Angriffsfläche.

Für KI-Agenten ist das strukturell falsch. Agenten existieren oft nur für die Dauer einer Aufgabe – sekunden- bis minutenlang, dann weg. Eine Identität, die für eine unbekannte Zukunft provisioniert wird, ist eine Identität, die zu viel kann.

Just-in-Time Provisioning für Agenten 📎 löst das: Identität entsteht zur Laufzeit, aufgabengebunden, mit den Berechtigungen für genau diesen Kontext. Wenn die Aufgabe endet, wird die Identität zurückgezogen. Nichts bleibt stehen. Das Prinzip nennt sich Zero Standing Privileges – keine dauerhaft bestehenden Rechte: Kein Agent hat Rechte, die er gerade nicht aktiv für eine laufende, autorisierte Aufgabe benötigt.

Das klingt einfach. Es ist technisch anspruchsvoll: Provisionierungsentscheidungen müssen in Millisekunden getroffen werden, auf Basis von Kontext, der erst zur Laufzeit entsteht. Klassische Provisioning-Workflows sind nicht für diese Geschwindigkeit gebaut.

Nicht wer du bist. Was du gerade tust.

Klassische Autorisierung fragt: „Hat diese Identität Recht X?“ Context-Aware Authorization fragt: „Hat diese Identität Recht X, in diesem Kontext, für diese Aufgabe, jetzt?“

Der Unterschied ist entscheidend. In einem breit berichteten Vorfall vom Dezember 2025 bat ein Nutzer Googles KI-Agenten Antigravity, den Projekt-Cache seines Rechners zu löschen. Der Agent führte stattdessen einen Befehl aus, der die gesamte D-Festplatte löschte 📎 – am Papierkorb vorbei, ohne Bestätigung, ohne Wiederherstellung. Der Agent hatte das Recht, Dateien zu löschen. Er hatte nicht das Recht, den gesamten Festplatteninhalt zu löschen, um einen Cache zu bereinigen. Das klassische IAM-System hat keinen Unterschied gesehen – weil es den Kontext nicht kannte.

Context-Aware Authorization setzt dabei eine vorgelagerte Integritätsprüfung der Handlungsabsicht des Agenten voraus – also der Frage, welche Absicht hinter einer Aktion steht und woher sie stammt. Kontext ist die Umgebung, in der der Agent operiert. Die Handlungsabsicht ist der Ursprung der Entscheidung, die er trifft. Wenn ein externer Input die Handlungsabsicht eines Agenten verändert – durch Prompt Injection, durch manipulierte Tool-Antworten, durch vergifteten Kontext 📎 – dann ist die Autorisierungsfrage auf Kontextebene nicht mehr ausreichend. Die Frage muss lauten: „Stammt diese Handlungsabsicht aus einer autorisierten Quelle?“

Das ist die Achillesferse jedes agentischen Autorisierungsmodells.

Akeyless 📎, ein israelisches Unternehmen, finanziert von JVP, Team8, NGP Capital und der Deutschen Bank, hat im März 2026 seine Agentic Runtime Authority vorgestellt: Autorisierungsentscheidungen werden nicht am Zugriffszeitpunkt getroffen, sondern am Aktionszeitpunkt. Jede Aktion eines Agenten wird unmittelbar vor der Ausführung gegen eine Richtlinie geprüft. Wenn die Aktion nicht zum Kontext der Aufgabe passt, wird sie blockiert – in Millisekunden, bevor sie wirkt.

PlainID 📎, ebenfalls aus Tel Aviv und im Februar 2026 als Representative Vendor im Gartner Market Guide for Guardian Agents 📎 gelistet, formuliert das Prinzip direkt: dynamische Leitplanken vom Prompt-Input über den Datenabruf bis zur Werkzeugausführung und zum Output. Nicht Login-basiert. Aktionsbasiert.

Das ist kein Produktfeature. Das ist die Korrektur an einem Modell, das die falsche Frage stellt.

Beobachten, weil Vertrauen nicht ausreicht

Berechtigung und Verhalten sind zwei verschiedene Dinge. Ein Agent kann korrekt autorisiert sein und trotzdem außerhalb seines intendierten Rahmens handeln – weil seine Handlungsabsicht manipuliert wurde, weil der Kontext sich verändert hat, weil eine Delegationskette eine Eskalation ermöglicht hat.

Continuous Verification bedeutet: Nicht nur bei der Anmeldung prüfen, ob ein Agent autorisiert ist. Sondern bei jeder Aktion, laufend, während der Ausführung. Gartner prognostiziert 📎, dass Organisationen bis 2027 unabhängige Überwachungssysteme benötigen, die agentische Systeme eigenständig und in Echtzeit kontrollieren. Der Begriff „Guardian-Systeme“ ist treffend gewählt: kein IAM-System, das einmal Zugang gewährt, sondern ein System, das kontinuierlich beobachtet und eingreift, wenn das beobachtete Verhalten von der autorisierten Handlungsabsicht abweicht.

Das entspricht Art. 14 des EU AI Acts 📎 zum Human Oversight – aber mit einem Unterschied, den der Gesetzgeber noch nicht ausbuchstabiert hat: Bei Agenten, die in Millisekunden handeln, kann menschliche Aufsicht nicht reaktiv sein. Sie muss architektonisch erzwungen werden.

Wenn die Berechtigung vorhanden war – und die Handlungsabsicht trotzdem falsch

Das ist der Punkt, an dem klassische Sicherheitslogik und agentische Realität auseinanderlaufen. Agentische KI verbindet Entscheidungsfähigkeit, Identität und Ausführung in einem System 📎 – das hat keine Kategorie im klassischen Incident-Modell.

Klassische Cybersecurity-Logik behandelt Prompt Injection als Angriff: Ein externer Akteur injiziert bösartige Instruktionen. Das ist korrekt – aber es erfasst nur den adversarialen Fall. Peer-reviewed Forschung aus Januar 2026 📎 beschreibt das strukturelle Problem präziser: Das „Confused Deputy“-Problem – auf Deutsch: der überlistete Stellvertreter – manifestiert sich akut. Agenten besitzen legitime Zugangsdaten und Berechtigungen. Aber die Entscheidungsfindung kann von jedem beeinflusst werden, der überzeugende Instruktionen in den Verarbeitungskontext einschleust. Autorisierung (hat der Agent die Berechtigung?) löst sich von Authentifizierung (wer hat den Befehl tatsächlich erteilt?).

Das Ergebnis ist erhebliches Eskalationspotenzial – ohne dass jemand Zugangsdaten gestohlen hat.

Das ist kein IAM-Versagen im klassischen Sinne. Es ist ein Autorisierungsmodell-Versagen. Und genau das ist, was §30 für den KRITIS-Kontext nicht tolerieren kann: eine Zugangskontrolle, die prüft, wer zugreift und welche Rolle er hat – aber nicht, was der Zugriff in diesem konkreten Kontext bedeutet und ob er seinem Zweck entspricht.

Ein System, das diese Trennung nicht erkennen kann, erfüllt die Anforderungen an Zugangskontrolle im Sinne von §30 BSIG strukturell nicht.

Der Audit-Trail, der mehr protokolliert als eine Liste

§30 verlangt Dokumentierbarkeit von Zugriffen. Art. 12 des EU AI Acts 📎 verlangt für Hochrisiko-Systeme „automatic logging of system events“ in einer Form, die Rückverfolgung ermöglicht.

Was das für KI-Agenten bedeutet, geht über einen klassischen API-Log hinaus.

Ein klassischer Audit-Log protokolliert: Welche Ressource, wann, durch wen, mit welchem Ergebnis. Für einen Agenten reicht das nicht. Wer fünf API-Aufrufe in zwanzig Sekunden protokolliert, hat dokumentiert, dass sie stattgefunden haben. Er hat nicht dokumentiert, ob sie innerhalb der geltenden Zugriffsrichtlinie stattgefunden haben – weil die Richtlinie nicht statisch war, sondern aus dem Kontext entstand.

Was gebraucht wird, ist Prompt-Provenance – die lückenlose Herkunftsdokumentation jeder Aktion: Welcher autorisierte Nutzerbefehl oder Systemauftrag hat die Aktionskette ausgelöst? Welche Werkzeugaufrufe wurden auf Basis welcher Eingaben getroffen? Und wenn eine Aktion außerhalb der erwarteten Zugriffsrichtlinie lag: Welche Eingabe hat die Handlungsabsicht verändert?

Augment Code hält fest 📎, dass Compliance-Rahmenwerke für agentische Systeme eine zusätzliche Dimension verlangen: nicht nur den Nachweis, dass eine Aktion stattgefunden hat, sondern den Nachweis des Entscheidungskontexts – genug Herkunftsdokumentation, um zu wissen, welche Eingaben, Zugriffsrichtlinien, Wissensquellen und Werkzeugaufrufe eine Entscheidung geprägt haben. Ohne das kann eine Organisation beweisen, dass eine Aktion passiert ist. Sie kann nicht beweisen, dass sie innerhalb der Richtlinie stattgefunden hat.

Akeyless bezeichnet das als lückenlose Nachverfolgbarkeit bis auf den auslösenden Befehl. PlainID spricht von vollständiger Prüfspur über den gesamten Agenten-Workflow. Microsofts Toolkit protokolliert jeden Abfangpunkt einer Aktion mit der zugehörigen Richtlinienbegründung.

Mangels allgemein anerkannter agentenspezifischer Standards ist derzeit unklar, nach welchem belastbaren Prüfmaßstab eine Bestätigung der §30-Vollständigkeit für agentische Systeme überhaupt erfolgen könnte. NIST hat festgestellt 📎, dass agentische Systeme eigenständige Standardisierungsarbeit erfordern – belastbare Standards liegen derzeit noch nicht vor. Was das konkret bedeutet: Kein KRITIS-Betreiber kann heute ein agentisches Zugangskontrollkonzept an einem anerkannten Standard ausrichten. Er muss das auf Eigenverantwortung tun.

Das ist keine Beruhigung. Es ist die Lücke, die §38 BSIG für den Vorstand zur Haftungsfrage macht 📎 – nicht hypothetisch, sondern ab dem Moment, in dem der erste Incident passiert.

Das Protokollierungs-Problem ist auch ein Herstellerproblem

Bisher war die Frage: Was muss protokolliert werden? Die nächste Frage ist unbequemer: Protokollieren die eingesetzten Agentensysteme das überhaupt?

Standardmäßig ist diese Tiefe in verbreiteten Frameworks jedenfalls nicht selbstverständlich dokumentiert oder aktiviert.

Die verbreiteten Agenten-Frameworks – LangChain, AutoGen, LangGraph und ihre Derivate – erzeugen standardmäßig Protokolle über Aktionen und API-Aufrufe. Was sie nicht persistieren: den auslösenden Prompt, den Entscheidungskontext, die Entscheidungspfade zwischen Werkzeugaufrufen. Diese Daten entstehen während der Ausführung. Sie verschwinden danach – weil kein Systemdesign sie festhalten musste und kein Unternehmen danach gefragt hat.

Das ist kein Versagen der Frameworks. Es ist ein Marktversagen: Solange keine regulatorische Anforderung existiert, die diese Tiefe verlangt, baut kein Hersteller sie standardmäßig ein. Und solange kein Unternehmen danach fragt, entsteht kein Beschaffungsdruck.

Für KRITIS-Betreiber ändert sich das mit §30 BSIG – ob die Frameworks nachziehen oder nicht. Wer heute einen KI-Agenten einführt, ohne zu prüfen, ob das System die notwendige Protokollierungstiefe liefern kann, schafft eine Lücke, die kein nachgelagertes Logging-Tool schließen kann. Was in der Ausführung nicht erfasst wurde, lässt sich nicht rekonstruieren.

Unternehmen, die KI-Agenten einführen, sollten daher von Herstellern und Systemintegratoren konkrete Antworten auf folgende Fragen verlangen:

Erstens: Was protokolliert das System standardmäßig – und in welchem Format? Ein Protokoll über Aktionen ist nicht dasselbe wie ein Protokoll über Entscheidungen.

Zweitens: Wird der auslösende Prompt jeder Aktion persistiert? Wenn nicht: Warum nicht, und kann das konfiguriert werden?

Drittens: Werden Werkzeugaufrufe mit dem Entscheidungskontext verknüpft protokolliert – also nicht nur was aufgerufen wurde, sondern auf Basis welcher Eingabe und mit welcher Begründung?

Viertens: Kann das Protokollierungsformat an ein bestehendes SIEM oder Audit-System übergeben werden? Und nutzt das System die GenAI Semantic Conventions des OpenTelemetry-Projekts – einen der wenigen verfügbaren vendor-neutralen Referenzpunkte für die strukturierte Erfassung von Prompts, Modellantworten und Werkzeugaufrufen? Wichtig dabei: OTel selbst sieht die Erfassung sensibler Inhalte wie Prompts und Modellausgaben nicht standardmäßig vor – sie ist opt-in. Das bedeutet: Selbst OTel-Konformität löst Prompt-Provenance nicht automatisch. Dieser Standard ist zudem noch experimentell und für agenten-spezifische Konventionen wie Delegationsketten und Aufgabenverfolgung noch nicht finalisiert. Er ist nicht regulatorisch vorgeschrieben. Aber er ist der naheliegendste interoperable Bezugspunkt, der heute verfügbar ist – und Hersteller, die ihn weder implementieren noch begründen, warum nicht, liefern keinen auditfähigen Ausgangspunkt.

Fünftens: Wer hat Zugriff auf diese Protokolle, und wo werden sie gespeichert? Bei Cloud-basierten Agenten ist die Datensouveränität eine eigene Compliance-Frage.

Ein System, das diese Fragen nicht beantworten kann, verhindert den Nachweis der §30-Konformität – unabhängig davon, wie verbreitet es im Markt ist. Das ist keine Produktbewertung. Das ist eine Haftungsrealität.

Der Notabschalter ist kein Sicherheitskonzept

Ein Notabschalter ist eine Reaktionsmaßnahme. Er wirkt, nachdem ein Mensch bemerkt hat, dass etwas falsch läuft.

Das ist nicht dasselbe wie Runtime Revocation – der automatische, richtlinienbasierte Entzug oder die Einschränkung von Agentenrechten während der Ausführung, ohne menschliches Eingreifen.

Microsofts Agent Governance Toolkit 📎 – Open Source, April 2026 – implementiert Execution Rings nach dem Vorbild von CPU-Privilegierungsebenen: Neue Agenten starten eingeschränkt und können sich Vertrauen schrittweise verdienen. Ein Agent, der eine Operation versucht, die über seinen Ring hinausgeht, wird geblockt – automatisch, ohne menschliche Entscheidung, in unter 0,1 Millisekunden.

Ein Notabschalter ist ein Nothammer. Runtime Revocation ist eine Steuerungsarchitektur.

Wenn Agenten Agenten beauftragen

Bisher war die Analyse auf einen einzelnen Agenten bezogen. Multi-Agenten-Systeme – Agenten, die andere Agenten beauftragen, die ihrerseits andere Agenten beauftragen – sind kein Randphänomen. Gartner und die Produktankündigungen der Anbieter von 2025/2026 behandeln sie als den nächsten Betriebsmodus.

Das Problem ist strukturell. In einer Delegationskette kann ein Agent mit niedrigen Berechtigungen einen Agenten mit höheren Berechtigungen beauftragen, eine Operation auszuführen, die dem ersten direkt verwehrt wäre. Das nennt sich Rechteausweitung durch Delegationsketten 📎 – und es ist kein exotischer Angriffsvektor. Es ist das natürliche Ergebnis jedes Mehr-Agenten-Systems, das keine Bereichseinschränkung erzwingt: kein Mechanismus, der sicherstellt, dass weitergegebene Rechte niemals größer sind als die Rechte des delegierenden Agenten. Das passiert auch dann, wenn alle Einzelagenten für sich korrekt implementiert sind.

Die Forschung, zitiert von Augment Code und bestätigt auf der ICLR 2025, ist eindeutig: Implizites gegenseitiges Vertrauen – alle Agenten eines Systems teilen dieselben Zugangsdaten, Vertrauen wird ohne erneute Prüfung über die gesamte Sitzung weitergegeben. Ein Agent mit niedrigen Rechten veranlasst damit einen privilegierten Agenten, vertrauliche Operationen auszuführen.

Die Lösung ist bekannt: Delegationsketten müssen Bereichseinschränkung erzwingen. Ein übergeordneter Agent mit Lese- und Schreibrechten kann nur Leserechte an einen untergeordneten Agenten weitergeben – niemals erweitern. Microsofts Toolkit implementiert genau das als Architekturprinzip.

Das Problem: Die meisten produktiven Mehr-Agenten-Systeme, die heute eingesetzt werden, implementieren das nicht. Sie behandeln Agenten-zu-Agenten-Kommunikation wie Agenten-zu-System-Kommunikation – mit denselben Zugangsdaten, denselben Berechtigungsbereichen, derselben impliziten Vertrauensstellung. Das ist kein böswilliges Design. Es ist das Ergebnis einer Softwareumgebung, die für diese Architektur noch kein Standardmodell hat 📎.

Was der Markt liefert – und was weiter fehlt

Oasis Security 📎 aus Tel Aviv ($195 Mio. Gesamtfinanzierung, mit Beteiligung von Craft Ventures, Sequoia, Accel und Cyberstarts) hat zusammen mit Akeyless und PlainID in den letzten Monaten sichtbar gemacht, dass es Lösungsansätze gibt. Akeyless erhielt bei RSAC 2026 den Global InfoSec Award als Market Leader in Identity Management for AI Agents sowie mehrere Cybersecurity Excellence Awards. PlainID wurde als einer der ersten Representative Vendors im Gartner Market Guide for Guardian Agents 📎 gelistet. Gartner hat damit erstmals eine eigenständige Produktkategorie für unabhängige Oversight-Systeme für autonome Agenten definiert – nicht als Erweiterung bestehender Produkte.

Das ist ein Signal. Aber es ist noch kein Standard.

Drei Lücken bleiben. Erstens: Öffentlich ist kein allgemein anerkannter, agentenspezifischer Nachweisrahmen erkennbar. Zweitens: Für Multi-Agenten-Systeme mit verschachtelten Delegationsketten ist nach heutigem öffentlichem Bild noch keine ausgereifte, marktweit anerkannte Standardarchitektur erkennbar – auch wenn Just-in-Time Provisioning, Context-Aware Authorization und Runtime Revocation für einzelne Agenten zunehmend implementierbar sind. Drittens: Lückenlose Nachverfolgbarkeit bis zum auslösenden Befehl ist technisch lösbar. Aber das Format, das ein Prüfer als ausreichend akzeptieren wird, ist noch nicht definiert.

Für vier der fünf Komponenten gibt es heute nutzbare Ansätze. Bei der fünften – Delegationsketten-Kontrolle in Multi-Agenten-Architekturen – ist öffentlich noch keine ausgereifte Standardarchitektur erkennbar. Das ist die ehrliche Antwort auf die Frage, wo ein KRITIS-Betreiber heute steht.

Fünf Fragen. Fünf Antworten. Eine noch nicht.

Die fünf Komponenten sind kein theoretisches Konstrukt. Sie sind die Antworten auf fünf Fragen, die ein NIS-2-Prüfer nach einem Agenten-Incident stellen wird.

Die erste Frage: Auf welche Systeme hat der Agent zugegriffen – und war das im Rahmen seiner autorisierten Aufgabe? Mit klassischem IAM steht ein Protokoll zur Verfügung. Es dokumentiert, dass eine Aktion stattgefunden hat. Es dokumentiert nicht, ob sie innerhalb der geltenden Zugriffsrichtlinie stattgefunden hat. Die schließende Komponente ist der unveränderliche Audit-Trail mit Herkunftsdokumentation.

Die zweite Frage: Woher stammte der Befehl, der die Aktion ausgelöst hat – aus einer autorisierten Quelle oder aus einer externen Eingabe? Mit klassischem IAM ist diese Frage nicht beantwortbar. Die Zugangsdaten waren korrekt, das Token gültig. Was die Handlungsabsicht des Agenten verändert hat, lässt sich aus dem Protokoll nicht rekonstruieren. Auch hier: Herkunftsdokumentation.

Die dritte Frage: War der Agent während der gesamten Ausführung auf das Minimum beschränkt, das seine Aufgabe erfordert? Mit klassischem IAM: nein. Zur Laufzeit hat kein System geprüft, ob die aktuelle Aktion noch zum autorisierten Aufgabenrahmen gehört. Die schließenden Komponenten sind Just-in-Time Provisioning und Context-Aware Authorization.

Die vierte Frage: Hätte das System eine Aktion außerhalb des autorisierten Kontexts verhindert – oder nur dokumentiert? Ein Notabschalter verhindert nichts. Er stoppt, nachdem jemand etwas bemerkt hat. Die schließende Komponente ist Runtime Revocation: Richtlinienprüfung vor der Ausführung, automatisch.

Die fünfte Frage: Wenn ein Agent einen anderen Agenten beauftragt hat – wurde dabei Berechtigungsverengung erzwungen? Mit klassischem Zugangskontrollmanagement existiert dieses Konzept nicht. Nach prüferischer Einschätzung ist eine nicht beantwortbare Frage im Audit kein offener Punkt. Sie ist ein negativer Befund.

Was jetzt entschieden werden muss

Der AI Act gilt grundsätzlich ab dem 2. August 2026. Die spezifischen Pflichten für Hochrisiko-KI-Systeme nach Anhang III – darunter die Anforderungen an Logging, menschliche Aufsicht und Risikomanagement – greifen nach Art. 113 jedoch erst ab dem 2. August 2027. Wer agentische Systeme einsetzt, sollte diese Differenz sauber prüfen. Die §30-Pflichten aus dem BSIG gelten dagegen bereits heute – ohne Übergangsfrist.

Ab dem 2. August 2027 ist für Hochrisiko-Systeme nach Anhang III nicht mehr entscheidend, ob ein Modell vorhanden ist – sondern ob ein Nachweis geführt werden kann.

Es gibt drei Entscheidungen, die davor getroffen werden müssen.

Erstens: Klassifikation. Welche der eingesetzten KI-Agenten fallen unter Hochrisiko? Das erfordert eine Analyse der aktuell betriebenen Systeme gegen den Anhang-III-Katalog des EU AI Acts. Viele Organisationen haben diese Analyse nicht durchgeführt, weil sie KI-Agenten nicht als Hochrisiko-Systeme betrachten. Das ist eine Fehleinschätzung, die entweder dokumentiert oder revidiert werden muss.

Zweitens: Zugangskontrollkonzept. §30 verlangt ein Konzept. Kein Standard definiert, wie dieses Konzept für Agenten aussehen muss. Aber die Norm gilt trotzdem. Das bedeutet: Eigenständige Auseinandersetzung mit den fünf Komponenten, Dokumentation des Ist-Stands, Identifikation der Lücken, Festlegung des Lösungswegs.

Drittens: Audit-Trail-Strategie. Was können die eingesetzten Systeme heute dokumentieren? Was nicht? Und was muss dokumentiert werden, damit ein Prüfer folgende Frage beantworten kann: Auf welche Systeme hat dieser Agent in den letzten neunzig Tagen zugegriffen – und war das innerhalb der geltenden Zugriffsrichtlinie?

Wer diese drei Entscheidungen trotz bereits geltender §30-BSIG-Pflichten bis zum 2. August 2026 noch nicht getroffen hat, verschärft eine Haftungslage, die §38 BSIG präzise adressiert.

Die Geschäftsführung besonders wichtiger Einrichtungen und wichtiger Einrichtungen ist nach §38 BSIG nicht nur verpflichtet, die Risikomanagementmaßnahmen nach §30 zu billigen und deren Umsetzung fortlaufend zu überwachen – sie muss dies nachweislich tun. Dazu gehören ausdrücklich angemessene Zugangskontrollen und Berechtigungsmanagement.

Wer hier marktübliche Lösungen von Okta, Microsoft oder IBM einsetzt, die das agentische Paradigma strukturell nicht abbilden, kann sich im Haftungsfall nicht hinter „anerkanntem Stand der Technik“ verschanzen 📎. Der Stand der Technik muss für die konkrete Risikoklasse geeignet sein. Wer autonome, entscheidungsfähige Agenten in KRITIS-Prozessen einsetzt und ihnen statische, kontextblinde Berechtigungen gibt, handelt außerhalb dessen, was als angemessene Risikosteuerung für diese Systemklasse vertretbar ist – unabhängig davon, wie viele Analysten das derzeit noch als bewährte Praxis verkaufen.

Die persönliche Haftung der Geschäftsführung ist damit kein theoretisches Risiko. Sie ist die logische Konsequenz eines bekannten Modellfehlers, an dem weiterhin festgehalten wird.

Was heute fehlt, ist kein Tool. Was fehlt, ist ein Modell, das nachweisfähig ist. Und solange dieses Modell fehlt, liegt die Verantwortung nicht beim Hersteller – sondern beim Betreiber.

In meiner Arbeit als leitender Sicherheitsarchitekt begleite ich Unternehmensführungen regulierter Organisationen dabei, die Steuerungsanforderungen agentischer KI-Systeme zu verstehen und strukturiert zu adressieren – und israelische Technologieunternehmen dabei, diese Anforderungen als europäische Marktbedingung zu begreifen, nicht als Hindernis. Die drei Entscheidungen am Ende dieses Artikels sind die Fragen, auf die ich in diesen Gesprächen noch selten eine fertige Antwort gefunden habe.

Sie stehen vor der Frage, welche Ihrer KI-Agenten-Einsätze unter §30 dokumentiert werden müssen – und was Ihr bestehendes Zugangskontrollkonzept dazu sagen kann? Dann ist jetzt der Zeitpunkt, darüber zu sprechen. 📎

Anmelden zu unserem Newsletter: