Wenn der Angreifer kein Mensch mehr ist
· aktualisiert · 6 Min. Lesezeit · Daniel Ostner
Autonome KI-Agenten greifen vollautomatisch an — und brauchen dafür laut Computerwoche keine zwei Stunden, um eine Domäne zu kompromittieren. Das klingt nach Science-Fiction. Es ist Gegenwart.
Zwei Stunden. Dann ist die Domäne weg.
Ich lese nicht jeden Sicherheitsbericht bis zum Ende. Die meisten enden mit einer Empfehlung, die sich anfühlt wie 'mehr Awareness-Training' — und dann weiß ich, wie der Rest aussieht. Den Bericht der Computerwoche zu autonomen KI-Angriffen habe ich trotzdem fertig gelesen. [EIGENE ERFAHRUNG: z.B. ein konkreter Moment aus einem Kundenprojekt oder internen Workshop, in dem das Thema KI-Agenten und Zugriffskontrolle zum ersten Mal auf dem Tisch lag — wie lange hat es gedauert, bis alle verstanden haben, worum es wirklich geht?]
Die Kernaussage ist kurz: Autonome KI-Agenten können eine Domäne in unter zwei Stunden vollautomatisch kompromittieren. Kein Mensch tippt dabei eine Zeile. Der Agent entscheidet, welche Zugänge er angreift, welche er überspringt, und wo er sich festsetzt. Das ist kein gradueller Unterschied zu bisherigen Angriffen. Das ist ein struktureller.
Was sich verändert hat — und warum das die Architektur trifft
Klassische Sicherheitsarchitektur denkt in Perimetern. Firewall draußen, vertrauenswürdiges Netz drinnen, Angreifer muss irgendwo durch. Das Modell hat schon mit menschlichen Angreifern gestöhnt. Mit KI-Agenten bricht es vollständig zusammen.
Ein autonomer Agent braucht keinen Schlaf. Er braucht keine Pause zwischen zwei Versuchen. Er skaliert horizontal, testet parallel Dutzende Angriffsvektoren und lernt aus jedem fehlgeschlagenen Versuch — innerhalb desselben Angriffs. Die Angriffsoberfläche ist dieselbe wie vorher. Die Angriffsgeschwindigkeit ist eine andere Kategorie.
Was das für die Architektur bedeutet: Jede Annahme, die auf 'ein Mensch braucht dafür Stunden oder Tage' basiert, ist hinfällig. Dazu gehören Eskalationsprozesse, die manuelle Genehmigungsschritte vorsehen. Dazu gehören Monitoring-Intervalle von 15 Minuten. Und dazu gehört die Vorstellung, dass ein SOC-Team einen laufenden Angriff noch 'aufhalten' kann, bevor er sich ausgebreitet hat.
Jede Sicherheitsarchitektur, die auf menschlicher Angriffsgeschwindigkeit basiert, ist gegen KI-Agenten strukturell unterlegen.
Zero Trust ist kein Buzzword mehr — es ist die Minimalanforderung
Die Computerwoche nennt als Gegenmittel Echtzeit-Kontrolle jedes Authentifizierungs- und Zugriffsmoments. Das ist im Kern die Zero-Trust-Architektur, die seit Jahren diskutiert wird — und in vielen DACH-Unternehmen noch immer als 'Projekt für nächstes Jahr' in der Roadmap steht.
Zero Trust bedeutet: kein implizites Vertrauen, auch nicht innerhalb des eigenen Netzes. Jeder Zugriff wird geprüft, jede Session, jede API-Anfrage. Nicht beim Login. Kontinuierlich. Das klingt aufwendig, weil es aufwendig ist. Aber die Alternative ist, einem KI-Agenten zwei Stunden ungestörte Arbeit zu lassen.
Für die Architektur heißt das konkret: Identity und Access Management muss von einem Randthema zur zentralen Plattformkomponente werden. Privileged Access Management (PAM) muss in Echtzeit arbeiten, nicht in Batches. Und Logging muss so granular sein, dass anomales Verhalten innerhalb von Minuten sichtbar wird — nicht nach dem nächsten Audit.
Kontinuierliche Authentifizierung statt einmaligem Login
Least-Privilege-Prinzip auf jeder Ebene, auch für Servicekonten
Echtzeit-Anomalieerkennung mit definierten Eskalationspfaden
Segmentierung, die laterale Bewegung im Netz aktiv verhindert
Zero Trust ist kein Sicherheitsprodukt. Es ist ein Architekturprinzip — und es muss in jede neue Komponente eingebaut werden, nicht nachgerüstet.
Governance-Frage: Wer ist zuständig, wenn der Angreifer schneller ist als der Prozess?
Das eigentliche Governance-Problem ist nicht technisch. Es ist organisatorisch. Viele Unternehmen haben Incident-Response-Prozesse, die für menschliche Angreifergeschwindigkeit gebaut sind. Eskalation an den CISO, Abstimmung mit dem Rechtsbereich, Kommunikation an den Vorstand — das dauert Stunden. Ein KI-Agent ist in dieser Zeit längst fertig.
Was fehlt, sind vorab autorisierte Gegenmaßnahmen. Also: klare Entscheidungen, die nicht erst im Ernstfall getroffen werden müssen. Welche Systeme werden bei einem bestimmten Anomaliemuster automatisch isoliert? Welche Dienste dürfen ohne manuelle Freigabe abgeschaltet werden? Wer hat die Vollmacht, das anzuordnen — und ist diese Person auch um drei Uhr morgens erreichbar?
Das sind keine angenehmen Fragen. Sie berühren Verantwortlichkeiten, die im Unternehmen oft unklar sind. Aber sie müssen vor einem Angriff beantwortet sein, nicht währenddessen. Die NIS2-Richtlinie, die seit Oktober 2024 in deutsches Recht umgesetzt sein muss, schreibt genau das vor: dokumentierte Incident-Response-Pläne mit klaren Zuständigkeiten. Wer das noch nicht hat, hat ein Compliance-Problem — und ein Sicherheitsproblem.
Incident Response muss für KI-Angriffsgeschwindigkeit ausgelegt sein. Das bedeutet: vorab autorisierte Maßnahmen, nicht Prozesse, die erst anlaufen, wenn der Schaden schon da ist.
Was das für KI-Projekte im eigenen Haus bedeutet
Es gibt noch eine zweite Seite dieser Entwicklung, die in der Debatte oft untergeht. Wer selbst KI-Agenten einsetzt — für Prozessautomatisierung, für Datenanalyse, für interne Assistenten — schafft damit neue Angriffsflächen. Ein kompromittierter KI-Agent mit weitreichenden Zugriffsrechten ist ein Angreifer mit Insider-Wissen.
Das bedeutet: Dieselben Prinzipien, die gegen externe KI-Agenten schützen, gelten auch für die eigenen. Least Privilege für jeden Agenten. Klare Grenzen, welche Systeme ein Agent erreichen darf. Logging aller Aktionen. Und eine Antwort auf die Frage, was passiert, wenn ein eigener Agent kompromittiert oder manipuliert wird.
Governance für KI-Agenten ist kein Zukunftsthema. Es ist ein Thema für jedes Unternehmen, das heute schon Automatisierungsprojekte mit KI-Komponenten betreibt.
Jeder KI-Agent im eigenen Haus braucht dieselbe Zugriffskontrolle wie ein externer Nutzer. Vertrauen wird nicht vererbt — auch nicht an eigene Systeme.
Was ich mitnehme — und was noch offen ist
Ich bin kein Sicherheitsarchitekt. Aber ich arbeite mit Unternehmen, die KI-Systeme einführen — und die Sicherheitsfrage kommt in diesen Gesprächen meistens zu spät. Nicht weil die Leute es nicht besser wüssten. Sondern weil der Druck, schnell zu liefern, die Frage 'Was kann schiefgehen?' verdrängt.
Was ich aus der Computerwoche-Meldung mitnehme: Die Lücke zwischen Angriffsgeschwindigkeit und Reaktionsfähigkeit ist real und wächst. Zero Trust und Echtzeit-Monitoring sind keine optionalen Ergänzungen mehr. Und die Governance-Frage — wer darf was, wann, ohne Rückfrage — muss vor dem nächsten KI-Projekt beantwortet sein, nicht danach.
Was noch offen ist: Wie viele Unternehmen im DACH-Raum haben ihre Incident-Response-Prozesse tatsächlich auf KI-Angriffsgeschwindigkeit ausgelegt? Ich habe keine belastbare Zahl dafür. Das ist vielleicht das unbehaglichste Detail an diesem Thema.
Quellen
Dieser Entwurf wurde KI-gestützt aus folgenden Meldungen erstellt und ist vor der Veröffentlichung redaktionell zu prüfen.
Cyber-Sicherheit: Wenn KI zum Angreifer wird – Computerwoche (https://www.computerwoche.de/article/4204996/cyber-sicherheit-wenn-ki-zum-angreifer-wird.html)
In die Praxis bringen
Readiness, Use Cases, Governance und Roadmap in einem strukturierten Pfad durcharbeiten.
Kostenlos starten
Daniel Ostner
Autor des Enterprise-AI-Leitfadens
KI-unterstützt entworfen, redaktionell geprüft am 11. September 2026.
Daniel Ostner bringt 20+ Jahre Erfahrung aus SAP-Landschaften und Enterprise-IT mit — als Chief Architect einer S/4-Greenfield-Transformation im globalen Chemiehandel und rund 7 Jahre als IT-Leiter eines SAP-Beratungshauses. Zertifiziert u.a. im IESE Executive Program Data & AI.