NIS2-Meldepflicht bei Sicherheitsvorfällen durch KI-Agenten
KI-Agenten können Code schreiben, Berechtigungen ändern und Deployments vorbereiten. Doch was passiert, wenn eine solche Änderung erst nach dem Produktivstart ein Sicherheitsrisiko sichtbar macht?
Die KI-Agenten-Sicherheit wird für Unternehmen deshalb immer wichtiger. Sie müssen technische Ursachen nachvollziehen, Risiken eingrenzen und gegebenenfalls enge Meldefristen nach NIS2 einhalten. Entscheidend ist, dass der Weg von der Agentenanweisung bis zum Verhalten der Anwendung dokumentiert bleibt.
Unternehmen müssen dann technische Ursachen nachvollziehen, Risiken eingrenzen und gegebenenfalls enge Meldefristen nach NIS2 einhalten. Entscheidend ist, dass der Weg von der Agentenanweisung bis zum Verhalten der Anwendung dokumentiert bleibt.
Kurz erklärt: Sicherheit bei KI-generierten Änderungen endet nicht mit einem erfolgreichen Test oder einem fehlerfreien Scan. Unternehmen müssen zusätzlich wissen, welche Rechte ein Agent genutzt hat, welche Änderungen tatsächlich ausgerollt wurden und wie sich diese im Betrieb auswirken.
Ein Coding-Agent repariert einen Fehler – und schafft ein neues Risiko
Ein Coding-Agent soll einen fehlgeschlagenen Integrationstest reparieren. Er findet einen schnellen Weg: Er erweitert die Datenbankberechtigungen eines Microservices und ergänzt einen Endpunkt zur Fehlersuche. Der Pull Request ist umfangreich, die menschliche Prüfung fällt knapp aus. Die CI-Pipeline läuft durch, der Sicherheitsscan meldet keine bekannten Schwachstellen. Am Montag geht die Änderung live.
Zwei Tage später fallen ungewöhnlich viele Abfragen auf die Kundendatenbank auf. Ist es ein Angriff, ein Konfigurationsfehler oder eine harmlose Lastspitze? Das Team muss die Antwort finden – und zwar schnell.
Das Szenario ist fiktiv und vereinfacht. Es illustriert aber eine reale Herausforderung: Eine formal geprüfte Änderung kann im Zusammenspiel mit bestehenden Systemen zusätzliche Angriffsflächen schaffen.
Der DORA-Report 2025 von Google Cloud liefert dazu einen wichtigen Kontext: Rund 90 Prozent der befragten Fachleute nutzen KI bei ihrer Arbeit. Die Studie beobachtet einen positiven Zusammenhang zwischen KI-Nutzung und Softwareauslieferungsdurchsatz, zugleich aber einen negativen Zusammenhang mit der Stabilität der Auslieferung. Diese Zusammenhänge beweisen nicht, dass KI einen bestimmten Vorfall verursacht. Sie unterstreichen jedoch, weshalb schnellere Entwicklungsprozesse robuste Kontrollmechanismen brauchen.
Warum KI-generierte Änderungen schwerer nachzuvollziehen sind
KI-gestützte Entwicklung verschärft drei bekannte Probleme der Softwaresicherheit:
Herausforderung | Was bei KI-Agenten hinzukommt | Was Unternehmen dokumentieren sollten |
|---|---|---|
Herkunft der Änderung | Ein Agent kann Code, Konfigurationen und Berechtigungen in einem Arbeitsablauf ändern. | Agent bzw. Werkzeug, Auftrag, Codeänderung, Freigabe, Deployment und Zeitpunkt |
Berechtigungen und Kontrolle | Der Agent kann die ihm eingeräumten Rechte für Aktionen nutzen, die über die eigentliche Aufgabe hinausgehen. | Effektive Rechte, erlaubte Aktionen, Freigaben und Änderungen an privilegierten Zugängen |
Geschwindigkeit und Umfang | Viele Änderungen in kurzer Zeit erschweren die manuelle Prüfung und spätere Zuordnung. | Änderungsprotokolle, automatisierte Kontrollen, Laufzeitereignisse und Verantwortlichkeiten |
Das Risiko übermässiger Handlungsfreiheit beschreibt OWASP als „Excessive Agency“ (LLM06:2025). Gemeint sind unter anderem unnötige Funktionen, zu weit reichende Berechtigungen oder zu viel Autonomie. Je mehr Systeme ein Agent verändern darf, desto grösser ist der mögliche Schaden durch fehlerhafte oder manipulierte Aktionen. Quelle: OWASP
NIS2: Welche Meldefristen gelten bei einem erheblichen Sicherheitsvorfall?
Für Unternehmen, die in Deutschland als besonders wichtige oder wichtige Einrichtungen unter das BSI-Gesetz fallen, gelten bei erheblichen Sicherheitsvorfällen Meldepflichten. Die einschlägigen Bestimmungen finden sich in § 32 BSIG.
Frist | Gesetzliche Anforderung | Welche Informationen dabei entscheidend sind |
|---|---|---|
Unverzüglich, spätestens nach 24 Stunden | Frühe Erstmeldung nach Kenntniserlangung eines erheblichen Sicherheitsvorfalls | Erste Einordnung, insbesondere Verdacht auf böswillige Handlungen und mögliche grenzüberschreitende Auswirkungen |
Unverzüglich, spätestens nach 72 Stunden | Meldung mit erster Bewertung | Schweregrad, Auswirkungen und gegebenenfalls Kompromittierungsindikatoren |
Grundsätzlich innerhalb eines Monats nach der 72-Stunden-Meldung | Abschlussmeldung | Ausführliche Beschreibung, vermutete Ursache, Auswirkungen und Abhilfemassnahmen |
Wichtig: Die Fristen beginnen nicht automatisch mit jeder verdächtigen Datenbankabfrage, sondern mit der Kenntniserlangung eines erheblichen Sicherheitsvorfalls. Ob die Voraussetzungen erfüllt sind, muss das Unternehmen anhand des Sachverhalts prüfen. Die gesetzlichen Pflichten gelten zudem nicht pauschal für jedes Unternehmen. Dauert der Vorfall zum vorgesehenen Zeitpunkt der Abschlussmeldung noch an, sieht § 32 BSIG zunächst eine Fortschrittsmeldung vor. Die Meldepflicht setzt ausserdem die Einrichtung des gesetzlichen Meldewegs voraus.
Die Angaben beziehen sich auf das deutsche BSI-Gesetz, nicht auf eine allgemeine Meldepflicht für alle Unternehmen in der Schweiz oder der Europäischen Union.
Was NIS2 für KI-generierten Code bedeutet
§ 30 BSIG verpflichtet betroffene Einrichtungen zu geeigneten, verhältnismässigen und wirksamen Risikomanagementmassnahmen. Dazu gehören unter anderem Sicherheit bei Entwicklung und Wartung von IT-Systemen, Schwachstellenmanagement, Incident Response sowie Verfahren zur Überprüfung der Wirksamkeit von Sicherheitsmassnahmen.
Für diese Pflichten ist nicht entscheidend, ob eine Änderung von einem Menschen oder einem KI-Agenten stammt. Unternehmen müssen ihre Entwicklungs- und Freigabeprozesse deshalb auch dann kontrollieren, wenn ein Agent grosse Teile der Arbeit übernimmt.
Hinzu kommt die Verantwortung der Geschäftsleitung: § 38 BSIG verpflichtet sie bei den erfassten Einrichtungen zur Umsetzung und Überwachung der Massnahmen nach § 30. Um diese Aufgabe erfüllen zu können, braucht sie nachvollziehbare Kennzahlen und klare Zuständigkeiten. Die genaue rechtliche Bewertung hängt vom Einzelfall ab.
Observability: Was ist nach einem Deployment tatsächlich passiert?
Ein erfolgreicher Sicherheitsscan zeigt nicht, wie sich eine Änderung später im Produktivbetrieb verhält. Hier setzt Observability an: Logs, Metriken und Traces helfen dabei, technische Ereignisse und ihre Zusammenhänge zu rekonstruieren.
Werden diese Daten mit Deployments, Infrastrukturänderungen, Agentenaktivitäten und Sicherheitsereignissen verknüpft, lässt sich eine belastbare Kette rekonstruieren:
Agentenanweisung → Code- oder Konfigurationsänderung → menschliche Freigabe → Deployment → Laufzeitverhalten → Sicherheitsereignis
Im eingangs beschriebenen Beispiel könnte das Team untersuchen, welcher Deployment-Vorgang den neuen Endpunkt eingeführt hat, seit wann er erreichbar war und ob darüber ungewöhnliche Datenbankzugriffe stattgefunden haben. Voraussetzung ist allerdings, dass die relevanten Ereignisse überhaupt erfasst und ausreichend lange aufbewahrt wurden.
Nicht jedes Monitoring-System liefert automatisch eine vollständige forensische Rekonstruktion.
Auch die Agentenaktivität selbst muss nachvollziehbar sein
Bei KI-Agenten können neben klassischen Applikationslogs auch folgende Informationen relevant sein: ursprüngliche Anweisungen, abgerufener Kontext, Tool-Aufrufe, Modellantworten, genehmigte Aktionen und tatsächlich ausgeführte Änderungen.
Diese Protokolle können allerdings personenbezogene Daten, Zugangsdaten, Geschäftsgeheimnisse oder Quellcode enthalten. Daher sind Datenminimierung, Maskierung, rollenbasierte Zugriffe, angemessene Aufbewahrungsfristen und eine geregelte Speicherung unverzichtbar. Produktivdaten und sensible Protokolle sollten KI-Werkzeugen nicht ungeprüft oder mit unnötigen Schreibrechten bereitgestellt werden.
Sieben Massnahmen für sichere KI-Agenten in der Softwareentwicklung
Massnahme | Konkrete Umsetzung | Ziel |
|---|---|---|
1. Agentenrechte begrenzen | Minimale Rechte vergeben; Änderungen an Datenbankrechten, Netzwerkregeln oder externen Schnittstellen ausdrücklich freigeben | Unbeabsichtigte und unautorisierte Aktionen begrenzen |
2. Gestaffelt ausrollen | Canary-Deployments, automatische Abbruchkriterien und getestete Rollbacks nutzen | Auswirkungen fehlerhafter Änderungen begrenzen |
3. Normalzustand überwachen | Neue Endpunkte, ausgehende Verbindungen und Rechteausweitungen nach Deployments erkennen | Abweichungen früh entdecken |
4. Herkunft dokumentieren | Agent, Auftrag, Pull Request, Freigabe, Build und Deployment miteinander verknüpfen | Verantwortlichkeiten und Ursachen rekonstruieren |
5. Laufzeitkontext kontrolliert bereitstellen | Logs, Traces und Änderungen zentral korrelieren; KI-Zugriff auf erforderliche, geschützte Informationen beschränken | Fehler schneller eingrenzen, ohne neue Datenrisiken zu schaffen |
6. Incident Response üben | Regelmässig testen, wie schnell das Team Auswirkungen, Ursache und Meldepflicht feststellen kann | Im Ernstfall handlungsfähig bleiben |
7. Kennzahlen definieren | Risikoreiche Änderungen, Herkunftsnachweise sowie Erkennungs- und Zuordnungszeiten auswerten | Wirksamkeit der Kontrollen für die Geschäftsleitung sichtbar machen |
Diese Massnahmen ergänzen klassische Sicherheitskontrollen, ersetzen sie jedoch nicht. Code Reviews, Zugriffskontrolle, Tests, Schwachstellenmanagement und Angriffserkennung bleiben notwendig.
Häufige Fragen zu KI-Agenten und NIS2
Sind KI-generierte Codeänderungen automatisch ein Verstoss gegen NIS2?
Nein. NIS2 verbietet den Einsatz von KI-Agenten in der Softwareentwicklung nicht. Betroffene Unternehmen müssen jedoch sicherstellen, dass ihre Risikomanagement-, Entwicklungs- und Sicherheitsprozesse auch KI-generierte Änderungen angemessen abdecken.
Muss jeder Sicherheitsalarm innerhalb von 24 Stunden gemeldet werden?
Nein. Die frühe Meldepflicht nach § 32 BSIG betrifft erhebliche Sicherheitsvorfälle bei den erfassten Einrichtungen. Ein einzelner Alarm oder eine Auffälligkeit ist nicht automatisch ein meldepflichtiger Vorfall. Die schnelle technische Einordnung ist deshalb entscheidend.
Warum reichen CI-Tests und Sicherheitsscans nicht aus?
Sie untersuchen bestimmte Eigenschaften einer Änderung vor der Auslieferung. Erst im Produktivbetrieb zeigt sich, welche Berechtigungen tatsächlich verwendet werden, welche Datenflüsse entstehen und ob neue Schnittstellen unerwartet erreichbar sind.
Welche Daten sollten Unternehmen bei KI-Agenten protokollieren?
Mindestens sollten Ursprung, Freigabe und tatsächliche Ausführung sicherheitsrelevanter Änderungen nachvollziehbar sein. Je nach Risiko gehören dazu Agenten- und Tool-Identitäten, Berechtigungen, Code- und Konfigurationsänderungen, Deployment-Ereignisse und relevante Laufzeitdaten. Die Protokollierung muss Datenschutz und Geheimnisschutz berücksichtigen.
Fazit: Nachvollziehbarkeit gehört zur Sicherheit von KI-Agenten
KI-Agenten können Entwicklungsabläufe erheblich beschleunigen. Damit daraus kein unkontrolliertes Betriebsrisiko wird, benötigen Unternehmen klare Berechtigungsgrenzen, verlässliche Freigaben und eine durchgehende Verbindung zwischen Änderung und Laufzeitverhalten.
Die entscheidende Frage lautet nicht nur: Hat der Agent den Code korrekt geschrieben? Sondern auch: Welche Änderung wurde tatsächlich ausgerollt, was hat sie bewirkt und können wir das im Sicherheitsvorfall belegen?
Für Unternehmen, die unter die deutschen NIS2-Meldepflichten fallen, kann genau diese Nachvollziehbarkeit wesentlich dafür sein, Vorfälle rechtzeitig und fundiert einzuordnen.
