Context Card
Unautorisierter Zugriff und Benachrichtigungspflicht
Warum sind das Verhindern unautorisierter Agentenzugriffe und die Benachrichtigung zwei getrennte Pflichten?
Die kurze Antwort
Unautorisierte Zugriffe zu verhindern ist eine technische Kontrollfrage: Kann das System einen Dienst überhaupt erreichen, und darf es dort die konkrete Aktion ausführen? Die Benachrichtigung ist eine Prozessfrage mit eigener Frist: Wer informiert Betreiber, Kunden oder Behörde, wie schnell und mit welchem Inhalt? Ein KI-System kann das eine erfüllen und am anderen scheitern — deshalb gehören beide Pflichten getrennt und getrennt nachweisbar in die Produktdokumentation.
Für: Projektleitung und technische Redaktion für KI-Produkte mit Außenzugriff
Das Wichtigste
- Erreichbarkeit und erlaubte Aktion sind zwei getrennte Kontrollentscheidungen.
- Benachrichtigung ist eine Prozesspflicht mit benannten Verantwortlichen und Fristen.
- Die Frist beginnt meist mit der Kenntnis, nicht mit dem Ereignis.
- Ohne belastbare Protokolle bleibt der Meldeinhalt Vermutung.
- Öffentliche Information ersetzt die Meldung an die betroffene Stelle nicht.
Der Zusammenhang
Zwei Kontrollfragen statt einer
Für jedes System mit Außenrechten — und ein Agent, der browst, APIs aufruft oder Befehle ausführt, ist ein solches System — beantwortet die Autorisierung zwei Fragen nacheinander. Erstens: Darf diese Identität dieses Ziel überhaupt erreichen? Zweitens: Darf sie dort diese konkrete Operation ausführen — lesen, ausführen, schreiben, Zugangsdaten abrufen? Netzwerkerreichbarkeit wird aus Bequemlichkeit oft weit vergeben, während die zweite Entscheidung dem Zielsystem überlassen bleibt, das häufig nur die Gültigkeit eines Zugangsdatums prüft, nicht dessen vorgesehenen Verwendungszweck. Eine aufgabenbezogen enge Zugriffskontrolle — Ziel-Allowlists, aufgabengebundene Zugangsdaten, kein Schreibpfad ohne Bedarf — hält beide Entscheidungen explizit.
Die Meldefrist läuft ab Kenntnis
Kommt es dennoch zu einem unautorisierten Zugriff, beginnt die zweite Pflicht. Die Praxis der Reaktion auf Sicherheitsvorfälle und die meisten Meldepflichten knüpfen Fristen an den Zeitpunkt der Kenntnis, nicht an den Zeitpunkt des Ereignisses; das EU-Datenschutzrecht setzt für die Meldung einer Verletzung des Schutzes personenbezogener Daten an die Aufsichtsbehörde eine Obergrenze von 72 Stunden (Stand Oktober 2026). Lücken zwischen Zugriff und Benachrichtigung entstehen meist nicht aus fehlender Technik, sondern aus unklarer Zuständigkeit: Niemand war als Person benannt, die den Befund einordnet und die betroffene Stelle kontaktiert.
Was zu dokumentieren ist
Dafür braucht es zwei Artefakte. Auf der Autorisierungsseite: Zweck, zulässige Ziele, Zugangsdaten, Schreibumfang und das Verhalten beim Grenzübertritt — erkennen, blockieren, abbrechen, isolieren. Auf der Meldeseite eine Verantwortlichkeit: Wer ordnet ein, wer informiert betroffene Betreiber und Behörden, innerhalb welcher Frist, mit welchem Mindestinhalt, und wer verantwortet den Abschlussbericht? Beide Seiten hängen an einer Protokollierung, die hinterher benennen lässt, welche Systeme, Dateien und Berechtigungen tatsächlich berührt wurden; ohne sie ist eine Meldung weder belegbar noch eingrenzbar. Und: Öffentlichkeit oder ein Blogbeitrag erfüllen keine Pflicht, die gegenüber einer bestimmten betroffenen Organisation besteht.
Fragen, die sich daran anschließen
- Wer ist bei einem Agentenvorfall die betroffene Stelle?
- In der Regel der Betreiber des zugegriffenen Systems, zusätzlich alle, deren Daten erreichbar waren, und in regulierten Fällen eine Aufsichtsbehörde. Die Dokumentation sollte Rollen benennen, nicht nur Kategorien.
- Was gehört in eine Erstmeldung?
- Was bekannt ist, wann es erkannt wurde, welche Systeme und Datenkategorien betroffen sind, was eingedämmt wurde und was noch untersucht wird. Offene Unsicherheit ist besser als Verzögerung bis zur Vollständigkeit.
- Muss ein blockierter Versuch gemeldet werden?
- Das hängt von Rechtsrahmen und Vertrag ab. Protokolliert und bewertet werden sollten blockierte Versuche in jedem Fall — ihre Häufung zeigt, dass eine Autorisierungsgrenze angelaufen wird.
Quellen
- NIST publishes SP 800-61 Rev. 3, overhauling incident response guidance for CSF 2.0 — Industrial Cyber, 5. Oktober 2026
- Agentic AI – Threats and Mitigations — OWASP Gen AI Security Project, 5. Oktober 2026
Prüfprotokoll und Änderungen
Jede Context Card wird vor der Veröffentlichung und bei jeder Änderung erneut anhand ihrer Quellen geprüft; das Datum unter der Autorenzeile ist die letzte Prüfung. Korrekturen (etwas war falsch) und Ergänzungen (etwas fehlte) stehen unten mit Datum und Uhrzeit (deutsche Zeit). Tippfehler, Formatierung und Link-Korrekturen werden nicht aufgeführt.
Geprüft
Seit der Veröffentlichung keine Korrekturen oder Ergänzungen.